I have spent considerable time researching this and hopefully I have just missed something so I thought I would bounce it off the StackExchange community as well.
Background:
On latest Chrome > 65, all of the notifications are stores on a per-site basis, so if one were to grant or deny notification popup for a SITE and want to reverse that decision (accidentally clicked the "block" for example) they can simply go into Chrome notification settings, find that specific site, and remove the block. This works as designed today and is well documented.
So here is the issue detail in a scenario:
Now, that exact same mechanism is used for extensions. An extension is initially granted all it's required permissions and works properly. Then, the user accidentally clicks "block" one time on a single desktop notification from the extension using the "gears" cog-wheel icon on the notification which then changes the notify balloon to this prompt:
Now, any time that extension attempts to send a notify message, instead of the normal desktop notify, an ugly javascript notify pops up in the middle of the screen (with the exact same notify text), and two buttons - "OK" and "Cancel". All extension functionality is unchanged if "OK" is clicked for example, the very same functions fire as if the user had clicked the prior desktop notify balloon popup.
Here are two screenshots of this exact scenario using the popular Tampermonkey Chrome extension (using a randomly selected script with a known update) that uses desktop notification API to communicate script updates:
"Normal" desktop notify message with default grant permission:
The exact same message (appears in center of the screen) once that permission is revoked by user clicking "block". **Note the actual message itself is not blocked which I find odd, just the desktop notify GUI bubble:
So, the question is really 2-fold:
Where does Chrome store that boolean value of PermissionLevel FOR EXTENSIONS - as they do NOT appear in the normal list of granted/blocked SITES. If not in the UI, is this setting exposed in a configuration file or is there even currently any way in Chrome>65 for the user to ever reverse this decision?
Is there either a programmatic method that can be implemented by an extension developer on the back-end to ever check if this has occurred and re-prompt the user to change their mind and re-grant that permission? I have found a couple unofficial posts here saying common sense says no to avoid malicious harassing of users etc. but I cannot find anything official.
Well, I can confirm after opening this as an official Chromium bug, that it's sitting waiting for triage and clearly has no current workaround here:
https://bugs.chromium.org/p/chromium/issues/detail?id=825497
I also did further testing to determine you can use the ID from the extension and add it into "sites" settings which also based on that behavior, appears to be yet another bug due to some settings not saving, none having desired effect, etc.
I will post this as the current answer as of 04-09-2018:
"it is impossible to re-enable Chrome desktop notifications FOR A SPECIFIC EXTENSION once blocked".
If anyone can post here a successful workaround to in any way re-enable the normal desktop notifications for an extension (tested with Tampermonkey) after the user clicks the "block all notifications from this app" to simply reverse the decision that would be great but I think as long as this has remained unanswered makes me lean towards believing there simply is no current method and it is just a (glaring) UI bug.
Sadly the only method for reversing this is to remove the extension and re-install it.
This issue has been open for nearly half a year. Not expecting a fix any time soon at this point. https://bugs.chromium.org/p/chromium/issues/detail?id=825497
Please star this issue at the link above if you're affected by it.
Related
Chrome implement new feature which is called auto tab discarding through this feature enable user when user not on the tab that tab will discard and when user re click on that tab chrome auto refresh that tab. here is the link of Article. this is is very good feature But my problem is I'm showing notification when our tab is active in chrome but because of this feature our Tab is discard and not able to show notifications anymore.
My Question is :- How to Disable this feature or there is any way to keep my tab active or any way to prevent that from discarding?
Users can switch off automatic tab discarding by setting the respective flag in Chrome using this link: chrome://flags/#automatic-tab-discarding
But every page with states depending on user input do have the same problem like yours. Usually, you can prevent unloading a page with handling the onbeforeunload event in JavaScript. Unfortunately, Google does not prevent a solution for this on all systems, despite many users had problems with this feature already in the experimental phase, as you can read in the user comments:
https://developers.google.com/web/updates/2015/09/tab-discarding
For ChomeOS, the problem seams to be fixed:
https://bugs.chromium.org/p/chromium/issues/detail?id=123049
On Android, automatic tab discarding is quite aggressive and prevents using Chrome for applications with significant user input, imho.
On Windows, automatic tab discarding only starts if the available memory is low.
Sorry for not coming up with a proper solution here (I'd be really happy to have one) - I did extensive research and this is all I could find.
Is there a way to listen for keyboard events on a webpage even if the tab and or window is not active (running but not the foreground application). I would assume no due to security concerns but maybe there is some way to archive it with explicit permissions? A service worker?
Basically what I'm trying to do is as following:
window.addEventListener('keydown', event => {
console.log(event.code);
});
As long as the tab is active it works as expected but if the user switches to another application it stops receiving input (also expected), but I am hoping for a way to add a "global" listener.
I know that I'm basically asking for a keylogger but the use-case is a webbased audio player which supports media keys (play/pause, next track, etc) present on some keyboards.
Fairly certain that even here in 2017, the answer to this is "no" for the reason you gave: It's just a huge security concern. Reviewing the list of permissions for pages in both Chrome1 and Firefox2 doesn't suggest any explicit permission for this. (Server workers would be irrelevant to it.)
1 If you click the lock/info/dangerous icon next to the page's URL, you can see all available permissions in Chrome (source).
2 It's similar in Firefox: Click the icon, click the > arrow, then "More Information".
I want to give a reward to the users of my chrome extension when they rate the extension on the Chrome Store. Do you know how I can monitor this event (user rating the extension)?
I am thinking of 2 ways to do so:
If I can monitor the event directly from the chrome extension, I would just put a button which will redirect to the Chrome Store, and will monitor when the user rates the extension.
If I cannot monitor the event, I can also put a button, which will redirect to a page, from where a popup will be opened with the chrome store (and maybe I can track the rating in the popup from the main page?)
The first approach is obviously the one which is the most interesting to me, and the second would only be an alternative if there is no way to use the first one.
Thank you!
There are no events associated with Webstore ratings/reviews that are part of Extension (or Webstore) APIs.
In fact, you can't track what the user does in Web Store at all, since you cannot inject a content script there - it's a special case in Chrome code. Reasons for that are pretty obvious - a content script in the Store could do automated ratings/reviews.
So the most you can do is rewarding a user clicking a link to Webstore somewhere in the extension (say, "Please rate the extension [here]"). You'll have to believe that the click is done at least with the intent to rate.
Extra consideration: some unscrupulous app developers would show the following UI to the user:
How would you rate our McGuffin?
[I would rate it 5 stars!] (link goes to Store rating page)
[I would rate it 1..4 stars] (link goes to developer's feedback form)
This obviously screws up the rating and should be considered unethical. Please avoid that - any honest rating should be equally precious.
When I access getUserMedia, a permission dialog pops up and my website waits until the user either accepts or blocks the request. That part works in Chrome 47.
However, in FireFox 43, (at least), when the dialog is visible, the user can click anywhere else and it will disappear and getUserMedia's callback will never be invoked. Then the user can't give permission and my site is stuck waiting. And it is pretty easy to click somewhere else, too, so I'm anticipating lots of "the microphone doesn't work" support calls.
(That seems like a bug in FireFox to me, since Chrome keeps the dialog visible until the user clicks it.) But anyway, is there a work around?
For instance, is there a way to detect whether the permission dialog is currently visible?
Or is there a way to re-summon that dialog in javascript by using a setTimeout?
Does anyone have another suggestion about how to make this user experience better?
The only thing I can think of is to put up a message something to the effect of, "Waiting for permission to use the microphone. If you don't see a permission dialog please refresh this page." There must be something better than that.
Thanks!
The permission dialog is merely minimized. Click on the gray microphone (or camera) icon that the dialog hung off, which is still there in the URL bar, and the dialog grows back and can be answered.
It is not a bug, as it was designed to be less intrusive than Chrome, to not let sites keep users hostage, so to speak, until they give up permissions, but the behavior does seem to confuse a lot of people. See https://bugzil.la/1004055.
There is no surefire way to detect whether the permission dialog is currently visible, though if you detect a mouseclick anywhere on the page, and you have not gotten a response, then chances are it is not.
One workaround is to issue another getUserMedia call (through setTimeout or otherwise). It should not crash. If it does then please file a bug.
Another workaround is to programmatically refresh the page, using location.refresh().
If your site is not designed to work without a microphone, or you detect a user-action that suggests the user is stuck, then maybe something like "Waiting for permission to use the microphone. Please click the microphone icon in the URL bar to summon the permission dialog if it is not visible."
I am building an application which has requirements stating that all browser features must be disabled. (It's a test taking application and they are worried about security/cheating.)
I popup a new window so that I can make it fullscreen, disable the menu bar, tool bar etc. However Firefox still has two icons remaining that I can't figure out how to disable. The 'Page' icon and the 'Bookmark' star icon are still on even when I call window.open with location=no. Here is the window.open command:
window.open("filename", "test", "fullscreen=yes,status=no,toolbar=no,location=no,menu=no,directories=no,scrollbars=yes");
Is there anything I can do about this?
From the MDC documentation for window.open():
Mozilla and Firefox users can force new windows to always render the location bar by setting dom.disable_window_open_feature.location to true in about:config or in their user.js file
In Firefox 3, dom.disable_window_open_feature.location now defaults to true, forcing the presence of the Location Bar much like in IE7.
This was done to help thwart phishing exploits. You're better off (your users are better off) leaving it enabled, even if you have control over the machines on which the browser is running.
You should really be designing your application such that knowing or bookmarking the URL won't help would-be cheaters. For instance: don't accept an answer to a question when an answer has been previously submitted.
If you don't have control of the computer the user is taking the test on, there's nothing you can do (and opening a full screen window won't prevent cheating for savvy users, either).
If you do have control over the computer or can instruct the user to install an application, you'd be best suited by building an actual application with embedded WebKit or Gecko.