Skip to content
This repository has been archived by the owner on Sep 11, 2024. It is now read-only.

notification issue fixed #240

Merged
merged 9 commits into from
Mar 29, 2016
Merged

notification issue fixed #240

merged 9 commits into from
Mar 29, 2016

Conversation

mebjas
Copy link
Contributor

@mebjas mebjas commented Mar 21, 2016

Signed-off-by: Minhaz A V minhazav@gmail.com

Changes

  • isPermissionDefault(): added a method to check id the current notification preference is default.
  • showToolbar(): added a method that returns bool value corresponding to whether or not we should show the toolbar. It first checks localStorage if the user has clicked on close button of the toolbar, then checks if the status of notification permission isn't default.
  • setEnabled (): now uses the then() method of Notification class to deal with user response to activate notification dialog. Performs necessary actions as per user's response. No changes if the user simply dismisses the dialog.
  • setToolbarHidden (): added an extra parameter that defines whether to store the setting persistently or not.
  • setToolbarPersistantHidden (): added to store the setting to localStorage

Signed-off-by: Minhaz A V <minhazav@gmail.com>
return global.Notification.permission == 'default';
},

showToolbar: function() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem to be used anywhere. Is there another PR to come?

showToolbar sounds like it will show the toolbar. This should be shouldShowToolbar or similar (and it needs a comment saying what it does)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's used by client to know weather or not to show the toolbar, I'll change it to shouldShowToolbar() though
element-hq/element-web#1237

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Sorry I missed the other PR. It's useful to say something about the other PR in the PR comments!

@richvdh
Copy link
Member

richvdh commented Mar 22, 2016

For the record: this relates to element-hq/element-web#1095 and element-hq/element-web#951

@richvdh
Copy link
Member

richvdh commented Mar 22, 2016

@mebjas: Thanks very much for the PR. Generally it looks good, though maybe a bit more complicated than I expected. I've made a few comments which might also help simplify things a bit.

Signed-off-by: Minhaz A V <minhazav@gmail.com>
if (this.isPermissionDefault()) {
// Attempt to get permission from user
var self = this;
global.Notification.requestPermission().then(function(result) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I shall shift this to callback one? I think that MDN doc is little updated, as this is supported in chrome now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think you might as well use the callback flow.

Obviously the MDN doc is outdated, but we don't know which version of Chrome introduced the promise; we don't know if it works in Safari; and using the promise doesn't buy us anything.

Signed-off-by: Minhaz A V <minhazav@gmail.com>

// means the permission is blocked
if (!this.isPermissionDefault()) return false;
return true;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@richvdh Tell me what do you think about showing a message if the user has blocked notif request & not yet attempted to close the toolbar - if yes, I'll change this method to return enums - 'show', 'hide', 'blocked' and the vector will take decision accordingly.

mebjas added 2 commits March 23, 2016 15:11
Signed-off-by: Minhaz A V <minhazav@gmail.com>
Signed-off-by: Minhaz A V <minhazav@gmail.com>
}
},

setToolbarPersistantHidden: function() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

still needs inlining

Signed-off-by: Minhaz A V <minhazav@gmail.com>
@@ -1046,7 +1046,7 @@ module.exports = React.createClass({
if (MatrixClientPeg.get().isGuest()) {
topBar = <GuestWarningBar />;
}
else if (Notifier.supportsDesktopNotifications() && !Notifier.isEnabled() && !Notifier.isToolbarHidden()) {
else if (Notifier.supportsDesktopNotifications() && Notifier.shouldShowToolbar()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this change is necessary. It's clearer to keep isEnabled and isToolbarHidden separate imho

@richvdh
Copy link
Member

richvdh commented Mar 23, 2016

@mebjas: better, but still quite a lot of the issues we discussed remain!

@mebjas
Copy link
Contributor Author

mebjas commented Mar 23, 2016

@richvdh why are we keeping notifications_enabled in localStorage at all?
And not rely on Notification.permission ?

@richvdh
Copy link
Member

richvdh commented Mar 23, 2016

We might have permission from the browser to show notifications, but the user has disabled the setting in Vector. That is what notifications_enabled is about.

global.localStorage.setItem('notifications_enabled', 'true');

if (this.havePermission) {
// Case when we do not have the permission as 'granted'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is no longer helpful

return;
}

if (callback) callback();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you need to update the localStorage setting before you run the callback and dispatch the notifier_enabled setting, otherwise things will get confused.

@richvdh
Copy link
Member

richvdh commented Mar 23, 2016

Much better :). Nearly there :)

Signed-off-by: Minhaz A V <minhazav@gmail.com>
@richvdh
Copy link
Member

richvdh commented Mar 23, 2016

This is looking really good now. I think there is one remaining problem though: Once you dismiss the banner, it will never, ever come back again. Suppose:

  • I don't want to enable notifications so I dismiss the banner
  • Later I decide I do want notifications after all so I enable them via the settings dialog
  • Later still I turn them off again.
    At this point I think it makes sense if we show the banner again.

My suggestion would be that you call setToolbarHidden(false) from setEnabled if enabled is true.

Signed-off-by: Minhaz A V <minhazav@gmail.com>
@mebjas
Copy link
Contributor Author

mebjas commented Mar 25, 2016

@richvdh ?

@richvdh
Copy link
Member

richvdh commented Mar 29, 2016

looks good, thank you!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants