Extensions can manipulate key bindings in Incognito mode when "Allow in Incognito" is not ticked
Reported by
mtgcs2...@gmail.com,
Jan 13 2017
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Steps to reproduce the problem: 1. Install Tampermonkey Extension (https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?utm_source=chrome-app-launcher-info-dialog) 2. Ensure "Allow in Incognito" is not ticked 3. Open new Incognito window 4. Navigate to https://w3c.github.io/uievents/tools/key-event-viewer.html 5. Press and hold Ctrl + Shift + E and release What is the expected behavior? Chrome fires a keypress and keydown event for E key What went wrong? Chrome does not fire these events because the Tampermonkey extension is controlling this keybinding Did this work before? N/A Chrome version: 55.0.2883.87 Channel: stable OS Version: Linux u705a0fcae861583c82b1 4.4.0-57-generic #78-Ubuntu SMP Fri Dec 9 23:50:32 UTC 2016 x86_64 x86_64 x86_64 Flash Version: Shockwave Flash 24.0 r0 This was originally reported in https://bugs.chromium.org/p/chromium/issues/detail?id=679461 but shuchen@chromium.org asked me to open a new issue in comment #11
,
Jan 13 2017
Confirmed repro in 57.0.2980.0 on Windows. I think this is a functionality issue rather than a security issue. The problem doesn't exist for extensions disabled entirely. extensions/api/commands/command_service.cc doesn't mention incognito at all. // ExtensionRegistry holds sets of the installed extensions for a given // BrowserContext. An incognito browser context and its master browser context share a single registry.
,
Jan 13 2017
Agreed that this probably isn't a security issue - elawrence@, feel free to drop the restriction. Additionally, it's a little weird since have command scopes for "Chrome" and "Global", but not anything as specific as, e.g., "Window" or "Tab". So for many extensions, it might be weird if it stopped working just because you had an incognito mode window selected - and then it raises an interesting question as well of what to do if the shortcut is set to "Global" (since we should then be theoretically sending events to the extension no matter what). It's not clear to me that there's a good answer here, or that either of these options would result in less confusion. +more folks to see if they have thoughts.
,
Jan 17 2017
Flipping this to a non-security bug.
,
Feb 8 2018
,
Apr 18 2018
,
Apr 20 2018
Hi, Is this fixed? It seems that Tampermonkey is changed, so the repro steps don't apply anymore.
,
Apr 20 2018
In Incognito v68.3401, this doesn't seem to repro for keystrokes that were manually chosen by the user on chrome://extensions/shortcuts-- the shortcuts only take effect in non-Incognito mode where the extension is enabled. I don't have any extensions with default/built-in hotkeys to try.
,
Jun 13 2018
mtgcs2000@, Can you still reproduce this?
,
Jun 17 2018
I'm not sure how to reproduce this after Tampermonkey has removed the key binding sorry, as I don't have any other extensions that have an always-on keybinding.
,
Jul 18
This bug is already fixed. All events are checked in 'EventRouter::CanDispatchEventToBrowserContext' to ensure that the extension is allowed in incognito or not, and it covers this case. I will try to add a test for it. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by elawrence@chromium.org
, Jan 13 2017