System / Browser Keyboard Lock |
|||||||||||||||
Issue descriptionThis bug is to track System / Browser Keyboard Lock implementation. W3C Working Draft https://rawgit.com/garykac/system-keyboard-lock/master/index.html Chromium discussion https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/9pauQUAvrcw/lfbG7eunCAAJ
,
Jan 14 2017
,
Jan 14 2017
,
Jan 16 2017
For Browser keyboard reservation, the feature proposal is at https://docs.google.com/document/d/1hUu3tq0zJxtXHIcYb0lCzCG7cwYNTi2ye-bb9kGdWgo/edit.
,
Feb 12 2017
Intent to implement and Ship of Browser keyboard lock is @ https://goo.gl/4tJ32G
,
Feb 12 2017
Issue 119881 has been merged into this issue.
,
Feb 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3c7af99a93f4b4837b2fbee5cb66697f66ccf241 commit 3c7af99a93f4b4837b2fbee5cb66697f66ccf241 Author: zijiehe <zijiehe@chromium.org> Date: Sun Feb 12 20:59:40 2017 Disable browser key reservation in fullscreen mode In intent to implement https://goo.gl/4tJ32G, we decided to deliver browser shortcuts to the websites, so a web page can provide almost consistent user experience as a native application. To ensure there is no security risk, a simple and safe approach is to allow websites to capture browser reserved keyboard combinations in full screen mode only. This does not apply to the keys to exit fullscreen (F11) or exit the application (ESC). BUG= 680809 Review-Url: https://codereview.chromium.org/2636013002 Cr-Commit-Position: refs/heads/master@{#449896} [modify] https://crrev.com/3c7af99a93f4b4837b2fbee5cb66697f66ccf241/chrome/browser/ui/browser_command_controller.cc [modify] https://crrev.com/3c7af99a93f4b4837b2fbee5cb66697f66ccf241/chrome/browser/ui/browser_command_controller_unittest.cc
,
Feb 12 2017
Hi, I think that using web apps or games in a fullscreen mode is quite rare. Also, different behavior inside and outside fulscreen mode is quite confusing. Users usually expect the page / app to behave the same, no matter if they are in a fullscreen or not. Can you always deliver these shortcuts to a webapp (even outside the fullscreen) and accept them by the browser, olny if they were not prevented (using e.preventDefault()) by a webapp? Just like it is done with a right mouse click.
,
Feb 12 2017
Thank you Ivan for the suggestion. We definitely want to deliver the shortcuts to all pages even out of full screen mode. But to avoid this feature to be misused, we start from fullscreen only. Say, a user is using ctrl + tab to switch between tabs, but one page registered the shortcut, and blocks the following switching attempts.
,
Feb 12 2017
Do you have any statistics, how many users actually use such shortcuts to control the browser? There are lots of ways, how webpages can "misuse" the user's computer. E.g. they can constantly run some heavy javascript, slow down all the other apps and drain the battery. Or they can play a loud sound since the first moment. In the world of software, there is a rule, that you either use the software and accept all "requirements", or you refuse it and use an alternative. It is similar to requirements when installing Android apps. If some webpage starts blocking ctrl+tab for no reason, some users would stop visiting it and use an alternative. So I think there is zero chance of webapps misusing it, because it will hurt their reputation. I am certain, that in practice, in 99% of cases, when a shortcut is "stolen" by a webapp, the user will expect such behavior. I am totally sure that at some point, Chrome developers will see, that it makes no sense to undermine the capabilities of webapps in this way. But it would be wonderful, if you could understand it now and don't wait five more years and 500 more complains from developers.
,
Feb 12 2017
#10: Unfortunately, this is the web, meaning that we are not only concerned with webapps that are good actors and want to be revisited by users. We are also very much concerned with malicious sites, which would override all keyboard shortcuts to prevent users from navigating away. This would help perpetuate attacks on Chrome users. Additionally, many users care *a lot* about their keyboard shortcuts, and having them not work is anathema. Simply put, our job is to balance the desires of web developers with our responsibility to users to protect them on the web. The web is not analogous to native apps because it is a "drive-by" experience: there is no installation step to guard users from malicious software. Viral links, shorteners, search, spam/phishing emails, spoof URLs - there are a multitude of ways to trick users into visiting a malicious site that are far easier to execute than getting a user to install a bad program. We don't just get requests from developers to get access to these shortcuts. We also get many requests from users to not touch their keyboard shortcuts. Our proposal for allowing shortcuts to be mapped in fullscreen is a compromise, and based on it, we will see what further action we can take.
,
Feb 12 2017
Personally I disagree your opinion. Chrome is a web browser for all users, not only developers. We do not expect most of our users to understand what a web browser is or how a webpage may impact the behavior of a web browser. I do not think most users can differentiate the requirements from the web pages or browsers. But it's our responsibility to provide a secure and ease-to-use environment to all of our customers. Using Microsoft Windows as an example. Microsoft Windows was widely considered to be impacted by numerous malware. Instead of system vulnerabilities, most of them attack users by misusing system APIs. But end users simply consider Windows as a unsafe and easy-to-be-attacked platform.
,
Feb 12 2017
,
Feb 12 2017
There are.already prompts.for webcam and location access, why not a new one for setting reserved shortcuts? Restricting to full screen doesn't help my use case much IDE/terminal client.
,
Feb 12 2017
#14: Location and camera access are obvious, easy to explain features that expose private user information. The ability to map shortcuts that are otherwise reserved by the browser is not intuitive, difficult to explain in a prompt, and does not expose private information. More prompts add decision fatigue for users and more interruptions for them while they're browsing the web. This logic also applies to adding a preference switch, etc. We understand that developers really want the ability to map all of these shortcuts all of the time, and we know it's a very useful capability. However, we have to balance this against security and usability concerns. https://bugzilla.mozilla.org/show_bug.cgi?id=380637 has a long discourse illustrating just how tricky it is to find a compromise and make everyone happy.
,
Feb 12 2017
And the push notifications prompt..? That doesn't expose private info and is perhaps harder to explain.
,
Feb 13 2017
Or if you don't want to display a prompt, you could use a similar approach to what happens when a non-https file is blocked, i.e display a notification icon in the address bar which can be used to enable the behaviour. It can be an icon of a keyboard, when clicked it would say the website tried to set a reserved shortcut allow/ deny.
,
Feb 14 2017
#16: Push notifications are another obvious, easy to understand feature which can be used to transmit private information from a site to a device (and e.g. shown on a lock screen for anyone to see). #17: I believe showing an icon in the address bar like you suggest is technically infeasible without incurring a significant performance penalty. Javascript runs in sandboxed renderer processes, and capturing keystrokes involves hooking up an event listener. That's a synchronous action and shouldn't block the script execution. But to show an icon in the address bar requires pausing the script execution and making an IPC call from the renderer to the browser process to tell it that the reserved shortcut is being listened for. More generally, any sort of permission based proposal for allowing reserved keyboard shortcuts to be mapped needs to work asynchronously, and ideally integrate into how those keystrokes are captured in the first place. Most users ignore or dismiss permission prompts, and they also don't see small icons in the address bar, so those solutions are not really that satisfying either (we are introducing more confusing words and icons in Chrome's UI for the vast majority of users who wouldn't want or use keyboard shortcuts ever).
,
Feb 16 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/13207802645e9185311993151707c56d28787ff7 commit 13207802645e9185311993151707c56d28787ff7 Author: zijiehe <zijiehe@chromium.org> Date: Thu Feb 16 08:06:10 2017 Revert 3c7af99, but keep only IsReservedCommandOrKey change Change https://chromium.googlesource.com/chromium/src/+/3c7af99a93f4b4837b2fbee5cb66697f66ccf241/ impacts both keyboard shortcut reservation and enable / disable of the commands, while the later one is not expected. So this change partially reverts the original change. The intent to implement is https://goo.gl/4tJ32G, which expects to deliver browser keyboard shortcuts to the web pages. BUG= 680809 Review-Url: https://codereview.chromium.org/2698013004 Cr-Commit-Position: refs/heads/master@{#450894} [modify] https://crrev.com/13207802645e9185311993151707c56d28787ff7/chrome/browser/ui/browser_command_controller.cc [modify] https://crrev.com/13207802645e9185311993151707c56d28787ff7/chrome/browser/ui/browser_command_controller_unittest.cc
,
Mar 7 2017
re #18 Add the icon but don't block the script execution. When approved the page will reload with reserved keybindings enabled. This is similar to how non-secure script access works.
,
Mar 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e84b99c44420c5214aaf0d6b095130f5f6535a4e commit e84b99c44420c5214aaf0d6b095130f5f6535a4e Author: zijiehe <zijiehe@chromium.org> Date: Sat Mar 25 04:46:35 2017 Revert change http://crrev.com/3c7af99a93f4b4837b2fbee5cb66697f66ccf241/ According to the discussion in http://crbug.com/702251 , we decide to revert this change on all platforms, and propose a more comprehensive change on Mac OS during M59. BUG= 702251 , 680809 Review-Url: https://codereview.chromium.org/2778523002 Cr-Commit-Position: refs/heads/master@{#459639} [modify] https://crrev.com/e84b99c44420c5214aaf0d6b095130f5f6535a4e/chrome/browser/ui/browser_command_controller.cc [modify] https://crrev.com/e84b99c44420c5214aaf0d6b095130f5f6535a4e/chrome/browser/ui/browser_command_controller_unittest.cc
,
Mar 28 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/32d6e978b9cba1260ceace176d3f6e9eae199ef7 commit 32d6e978b9cba1260ceace176d3f6e9eae199ef7 Author: Jamie Walch <jamiewalch@chromium.org> Date: Tue Mar 28 19:15:00 2017 Revert change http://crrev.com/3c7af99a93f4b4837b2fbee5cb66697f66ccf241/ According to the discussion in http://crbug.com/702251 , we decide to revert this change on all platforms, and propose a more comprehensive change on Mac OS during M59. BUG= 702251 , 680809 Review-Url: https://codereview.chromium.org/2778523002 Cr-Commit-Position: refs/heads/master@{#459639} (cherry picked from commit e84b99c44420c5214aaf0d6b095130f5f6535a4e) Review-Url: https://codereview.chromium.org/2778063004 . Cr-Commit-Position: refs/branch-heads/3029@{#457} Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471} [modify] https://crrev.com/32d6e978b9cba1260ceace176d3f6e9eae199ef7/chrome/browser/ui/browser_command_controller.cc [modify] https://crrev.com/32d6e978b9cba1260ceace176d3f6e9eae199ef7/chrome/browser/ui/browser_command_controller_unittest.cc
,
Apr 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/68cd3dc22ddbfddfdcf252f42b129a12e2d39a8b commit 68cd3dc22ddbfddfdcf252f42b129a12e2d39a8b Author: zijiehe <zijiehe@chromium.org> Date: Fri Apr 07 18:50:29 2017 Allow keyboard shortcuts can be captured by webpage when toolbar is not visible After discussing in http://crbug.com/702251 , we decide to enable browser shortcuts when the tab-strip / toolbar is visible on Mac OS. There is no comparable behavior on other platforms. This change adds a BrowserWindow::IsToolbarShowing() function to indicate whether the toolbar is showing up on the screen. BrowserWindowCocoa needs to override this function, which has not been done yet in this change. BUG= 680809 , 702251 Review-Url: https://codereview.chromium.org/2781633003 Cr-Commit-Position: refs/heads/master@{#462942} [modify] https://crrev.com/68cd3dc22ddbfddfdcf252f42b129a12e2d39a8b/chrome/browser/ui/browser_command_controller.cc [modify] https://crrev.com/68cd3dc22ddbfddfdcf252f42b129a12e2d39a8b/chrome/browser/ui/browser_command_controller_unittest.cc [modify] https://crrev.com/68cd3dc22ddbfddfdcf252f42b129a12e2d39a8b/chrome/browser/ui/browser_window.h [modify] https://crrev.com/68cd3dc22ddbfddfdcf252f42b129a12e2d39a8b/chrome/browser/ui/cocoa/browser_window_cocoa.h [modify] https://crrev.com/68cd3dc22ddbfddfdcf252f42b129a12e2d39a8b/chrome/browser/ui/cocoa/browser_window_cocoa.mm [modify] https://crrev.com/68cd3dc22ddbfddfdcf252f42b129a12e2d39a8b/chrome/browser/ui/views/frame/browser_view.cc [modify] https://crrev.com/68cd3dc22ddbfddfdcf252f42b129a12e2d39a8b/chrome/browser/ui/views/frame/browser_view.h [modify] https://crrev.com/68cd3dc22ddbfddfdcf252f42b129a12e2d39a8b/chrome/test/base/test_browser_window.cc [modify] https://crrev.com/68cd3dc22ddbfddfdcf252f42b129a12e2d39a8b/chrome/test/base/test_browser_window.h
,
Apr 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/901f389a22a01c1c2bbee6b665685a8db123e70e commit 901f389a22a01c1c2bbee6b665685a8db123e70e Author: zijiehe <zijiehe@chromium.org> Date: Tue Apr 25 22:33:57 2017 Implement BrowserWindowCocoa::IsToolbarShowing According to the discussion in http://crbug.com/702251 , we would prefer to only disable browser keyboard shortcuts once the toolbar is hidden in fullscreen mode on Mac. So a new function IsToolbarShowing() is added to BrowserWindow interface. This change implements this function in BrowserWindowCocoa by retrieving information from BrowserWindowController. R=shrike@chromium.org CC=msw@chromium.org BUG= 680809 Review-Url: https://codereview.chromium.org/2824803004 Cr-Commit-Position: refs/heads/master@{#467141} [modify] https://crrev.com/901f389a22a01c1c2bbee6b665685a8db123e70e/chrome/browser/ui/cocoa/browser_window_cocoa.h [modify] https://crrev.com/901f389a22a01c1c2bbee6b665685a8db123e70e/chrome/browser/ui/cocoa/browser_window_cocoa.mm [modify] https://crrev.com/901f389a22a01c1c2bbee6b665685a8db123e70e/chrome/browser/ui/cocoa/browser_window_controller.h [modify] https://crrev.com/901f389a22a01c1c2bbee6b665685a8db123e70e/chrome/browser/ui/cocoa/browser_window_controller.mm
,
Apr 28 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6016778c99f93e8f91eec1d1f20fc44642d3bfde commit 6016778c99f93e8f91eec1d1f20fc44642d3bfde Author: zijiehe <zijiehe@chromium.org> Date: Fri Apr 28 22:31:02 2017 [System-Keyboard-Lock] Forward navigator functions to RenderFrameHost This change forwards navigator.requestKeyLock() and navigator.cancelKeyLock() functions to the RenderFrameHostImpl. System-Keyboard-Lock is a feature to detect the key presses which usually cannot be received by the browser, and send them to the web page. It contains various components to achieve the goal. This change is one of them, which receives JavaScript (or Web Platform API in the design doc) function calls and forwards them into RenderFrameHost. For detail, please refer to the design doc at, https://docs.google.com/document/d/1T9gJHYdA1VGZ6QHQeOu0hOacWWWJ7yNEt1VDbLju4bs/edit#heading=h.cgwemqs2j4ta W3C Working Draft: https://garykac.github.io/system-keyboard-lock/ Intent to implement: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/9pauQUAvrcw/lfbG7eunCAAJ BUG= 680809 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation Review-Url: https://codereview.chromium.org/2805763004 Cr-Commit-Position: refs/heads/master@{#468158} [modify] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/content/browser/BUILD.gn [modify] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/content/browser/DEPS [modify] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/content/browser/frame_host/render_frame_host_impl.cc [add] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/content/browser/keyboard_lock/keyboard_lock_service_impl.cc [add] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/content/browser/keyboard_lock/keyboard_lock_service_impl.h [modify] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/content/public/app/mojo/content_browser_manifest.json [modify] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/LayoutTests/W3CImportExpectations [add] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/idlharness.https-expected.txt [add] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/idlharness.https.html [add] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-cancelKeyLock.https.html [add] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-requestKeyLock-two-parallel-requests.https.html [add] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-requestKeyLock-two-sequential-requests.https.html [add] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-requestKeyLock.https.html [modify] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/LayoutTests/virtual/service-worker-navigation-preload-disabled/webexposed/global-interface-listing-expected.txt [modify] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-expected.txt [modify] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/Source/modules/BUILD.gn [add] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/Source/modules/keyboard_lock/BUILD.gn [add] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/Source/modules/keyboard_lock/NavigatorKeyboardLock.cpp [add] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/Source/modules/keyboard_lock/NavigatorKeyboardLock.h [add] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/Source/modules/keyboard_lock/NavigatorKeyboardLock.idl [modify] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/Source/modules/modules_idl_files.gni [modify] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5 [modify] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/public/BUILD.gn [add] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/public/platform/modules/keyboard_lock/OWNERS [add] https://crrev.com/6016778c99f93e8f91eec1d1f20fc44642d3bfde/third_party/WebKit/public/platform/modules/keyboard_lock/keyboard_lock.mojom
,
May 2 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b67deca63eb94ec8e8fef981b0581d35ed7341fe commit b67deca63eb94ec8e8fef981b0581d35ed7341fe Author: zijiehe <zijiehe@chromium.org> Date: Tue May 02 22:18:38 2017 Rename KeyLock to KeyboardLock and return enum from IPC This change addresses one remaining work in change https://codereview.chromium.org/2805763004/ to modify the return value of RequestKeyLock() mojom interface from (bool, string) to an enumeration. Meanwhile, after discussing with Gary (GaryKac@), we would prefer to keep "Keyboard" as part of the function name. So all "KeyLock"s are changed to "KeyboardLock". BUG= 680809 Review-Url: https://codereview.chromium.org/2852823002 Cr-Commit-Position: refs/heads/master@{#468791} [modify] https://crrev.com/b67deca63eb94ec8e8fef981b0581d35ed7341fe/content/browser/keyboard_lock/keyboard_lock_service_impl.cc [modify] https://crrev.com/b67deca63eb94ec8e8fef981b0581d35ed7341fe/content/browser/keyboard_lock/keyboard_lock_service_impl.h [modify] https://crrev.com/b67deca63eb94ec8e8fef981b0581d35ed7341fe/third_party/WebKit/LayoutTests/W3CImportExpectations [modify] https://crrev.com/b67deca63eb94ec8e8fef981b0581d35ed7341fe/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/idlharness.https-expected.txt [modify] https://crrev.com/b67deca63eb94ec8e8fef981b0581d35ed7341fe/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/idlharness.https.html [rename] https://crrev.com/b67deca63eb94ec8e8fef981b0581d35ed7341fe/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-cancelKeyboardLock.https.html [delete] https://crrev.com/c3efb07dd4212081ae8ad66551feba3ae21ba417/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-requestKeyLock-two-parallel-requests.https.html [delete] https://crrev.com/c3efb07dd4212081ae8ad66551feba3ae21ba417/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-requestKeyLock-two-sequential-requests.https.html [add] https://crrev.com/b67deca63eb94ec8e8fef981b0581d35ed7341fe/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-requestKeyboardLock-two-parallel-requests.https.html [add] https://crrev.com/b67deca63eb94ec8e8fef981b0581d35ed7341fe/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-requestKeyboardLock-two-sequential-requests.https.html [rename] https://crrev.com/b67deca63eb94ec8e8fef981b0581d35ed7341fe/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-requestKeyboardLock.https.html [modify] https://crrev.com/b67deca63eb94ec8e8fef981b0581d35ed7341fe/third_party/WebKit/LayoutTests/virtual/service-worker-navigation-preload-disabled/webexposed/global-interface-listing-expected.txt [modify] https://crrev.com/b67deca63eb94ec8e8fef981b0581d35ed7341fe/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-expected.txt [modify] https://crrev.com/b67deca63eb94ec8e8fef981b0581d35ed7341fe/third_party/WebKit/Source/modules/keyboard_lock/NavigatorKeyboardLock.cpp [modify] https://crrev.com/b67deca63eb94ec8e8fef981b0581d35ed7341fe/third_party/WebKit/Source/modules/keyboard_lock/NavigatorKeyboardLock.h [modify] https://crrev.com/b67deca63eb94ec8e8fef981b0581d35ed7341fe/third_party/WebKit/Source/modules/keyboard_lock/NavigatorKeyboardLock.idl [modify] https://crrev.com/b67deca63eb94ec8e8fef981b0581d35ed7341fe/third_party/WebKit/public/platform/modules/keyboard_lock/keyboard_lock.mojom
,
May 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3bee08e25f92a3ecaeac0be34dd23fed3596e128 commit 3bee08e25f92a3ecaeac0be34dd23fed3596e128 Author: zijiehe <zijiehe@chromium.org> Date: Wed May 17 04:14:46 2017 Add WebContentObserver::OnWebContentsLostFocus() In Keyboard Lock feature, we need to disable low level keyboard lock once the page lost focus. So this change adds a OnWebContentsLostFocus() callback in WebContentObserver to export the bluring action. For detail, please refer to the design doc at, https://docs.google.com/document/d/1T9gJHYdA1VGZ6QHQeOu0hOacWWWJ7yNEt1VDbLju4bs/edit#heading=h.cgwemqs2j4ta W3C Working Draft: https://garykac.github.io/system-keyboard-lock/ Intent to implement: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/9pauQUAvrcw/lfbG7eunCAAJ BUG= 680809 Review-Url: https://codereview.chromium.org/2877323002 Cr-Commit-Position: refs/heads/master@{#472319} [modify] https://crrev.com/3bee08e25f92a3ecaeac0be34dd23fed3596e128/content/browser/renderer_host/render_view_host_delegate_view.h [modify] https://crrev.com/3bee08e25f92a3ecaeac0be34dd23fed3596e128/content/browser/renderer_host/render_view_host_impl.cc [modify] https://crrev.com/3bee08e25f92a3ecaeac0be34dd23fed3596e128/content/browser/renderer_host/render_view_host_impl.h [modify] https://crrev.com/3bee08e25f92a3ecaeac0be34dd23fed3596e128/content/browser/renderer_host/render_widget_host_delegate.h [modify] https://crrev.com/3bee08e25f92a3ecaeac0be34dd23fed3596e128/content/browser/renderer_host/render_widget_host_impl.cc [modify] https://crrev.com/3bee08e25f92a3ecaeac0be34dd23fed3596e128/content/browser/renderer_host/render_widget_host_owner_delegate.h [modify] https://crrev.com/3bee08e25f92a3ecaeac0be34dd23fed3596e128/content/browser/web_contents/web_contents_impl.cc [modify] https://crrev.com/3bee08e25f92a3ecaeac0be34dd23fed3596e128/content/browser/web_contents/web_contents_impl.h [modify] https://crrev.com/3bee08e25f92a3ecaeac0be34dd23fed3596e128/content/browser/web_contents/web_contents_view_aura.cc [modify] https://crrev.com/3bee08e25f92a3ecaeac0be34dd23fed3596e128/content/browser/web_contents/web_contents_view_aura.h [modify] https://crrev.com/3bee08e25f92a3ecaeac0be34dd23fed3596e128/content/public/browser/web_contents_observer.h
,
Jun 2 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3118ff1d918e589cf32d4def65d3d40411b44428 commit 3118ff1d918e589cf32d4def65d3d40411b44428 Author: zijiehe <zijiehe@chromium.org> Date: Fri Jun 02 03:14:47 2017 [System-Keyboard-Lock] Add KeycodeConverter::CodeStringToNativeKeycode() function Native keycode is used in system keyboard lock feature to understand the input requested keys from Javascript API. Also for consistency, CodeToUsbKeycode() has been renamed to CodeStringToUsbKeycode(). You will find the usage of the newly added function in, https://codereview.chromium.org/2879033002/diff/510001/components/keyboard_lock/keyboard_lock_host.cc function KeyboardLockHost::SetReservedKeyCodes(). For detail, please refer to the design doc at, https://docs.google.com/document/d/1T9gJHYdA1VGZ6QHQeOu0hOacWWWJ7yNEt1VDbLju4bs/edit#heading=h.cgwemqs2j4ta W3C Working Draft: https://garykac.github.io/system-keyboard-lock/ Intent to implement: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/9pauQUAvrcw/lfbG7eunCAAJ A prototype can be found at, https://codereview.chromium.org/2879033002 BUG= 680809 Review-Url: https://codereview.chromium.org/2910873002 Cr-Commit-Position: refs/heads/master@{#476544} [modify] https://crrev.com/3118ff1d918e589cf32d4def65d3d40411b44428/remoting/client/plugin/pepper_input_handler.cc [modify] https://crrev.com/3118ff1d918e589cf32d4def65d3d40411b44428/ui/events/keycodes/dom/keycode_converter.cc [modify] https://crrev.com/3118ff1d918e589cf32d4def65d3d40411b44428/ui/events/keycodes/dom/keycode_converter.h
,
Jun 2 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/031af3b98c849f80b3a8bb04f1727eb988070582 commit 031af3b98c849f80b3a8bb04f1727eb988070582 Author: zijiehe <zijiehe@chromium.org> Date: Fri Jun 02 18:02:10 2017 [System-Keyboard-Lock] Recover keyboard lock related tests The tests for keyboard lock have been wrongly annotated in W3CImportExpectations. So they have been removed by change https://chromium-review.googlesource.com/c/499507/. So this change annotates these tests as Pass; so they will be correctly imported next time. BUG= 680809 Review-Url: https://codereview.chromium.org/2916803004 Cr-Commit-Position: refs/heads/master@{#476718} [modify] https://crrev.com/031af3b98c849f80b3a8bb04f1727eb988070582/third_party/WebKit/LayoutTests/W3CImportExpectations
,
Jun 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cc0c8cf835d5656666dbc7266d6f542d6607bc1f commit cc0c8cf835d5656666dbc7266d6f542d6607bc1f Author: zijiehe <zijiehe@chromium.org> Date: Sat Jun 03 00:28:10 2017 [System-Keyboard-Lock] Restore keyboard-lock tests The related test cases are removed by change https://chromium-review.googlesource.com/c/499507/ because of a wrong annotation in W3CImportExpectations file. The change to correct W3CImprotExpectations will be submitted by change https://codereview.chromium.org/2916803004/. So this change restores the original test files. NOEXPORT=true BUG= 680809 Review-Url: https://codereview.chromium.org/2915203003 Cr-Commit-Position: refs/heads/master@{#476843} [add] https://crrev.com/cc0c8cf835d5656666dbc7266d6f542d6607bc1f/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/idlharness.https-expected.txt [add] https://crrev.com/cc0c8cf835d5656666dbc7266d6f542d6607bc1f/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/idlharness.https.html [add] https://crrev.com/cc0c8cf835d5656666dbc7266d6f542d6607bc1f/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-cancelKeyboardLock.https.html [add] https://crrev.com/cc0c8cf835d5656666dbc7266d6f542d6607bc1f/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-requestKeyboardLock-two-parallel-requests.https-expected.txt [add] https://crrev.com/cc0c8cf835d5656666dbc7266d6f542d6607bc1f/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-requestKeyboardLock-two-parallel-requests.https.html [add] https://crrev.com/cc0c8cf835d5656666dbc7266d6f542d6607bc1f/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-requestKeyboardLock-two-sequential-requests.https.html [add] https://crrev.com/cc0c8cf835d5656666dbc7266d6f542d6607bc1f/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-requestKeyboardLock.https.html
,
Jun 22 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2ee5f007316b4a7ecf451fce973f581c59de066e commit 2ee5f007316b4a7ecf451fce973f581c59de066e Author: zijiehe <zijiehe@chromium.org> Date: Thu Jun 22 21:40:51 2017 Use wScan instead of wVk to ensure webpage can get correct DOM CodeString DOM CodeString comes from scancode, so SendInput should use scancode instead of virtual-key if the key is associated with a DOM CodeString. With this change, test cases in https://codereview.chromium.org/2922773002/ should pass. A KeyboardEventCodeInteractiveTest is also added to ensure KeyboardEvent.code can be correctly set by using ui_test_utils::SendKeyPressSync(). KeyboardEventCodeInteractiveTest starts a web page to record all the KeyboardEvent.code it received, sends several key presses through ui_test_utils::SendKeyPressSync() and verifies whether the record is expected. BUG= 680809 Review-Url: https://codereview.chromium.org/2939283002 Cr-Commit-Position: refs/heads/master@{#481671} [modify] https://crrev.com/2ee5f007316b4a7ecf451fce973f581c59de066e/ui/base/test/ui_controls_internal_win.cc
,
Jul 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bb317b9cc0055f7abebcd014dfb6c193548b4d88 commit bb317b9cc0055f7abebcd014dfb6c193548b4d88 Author: zijiehe <zijiehe@chromium.org> Date: Sat Jul 15 00:01:40 2017 Add BrowserCommandController Interactive Test BrowserCommandController interactive test ensures the recent changes of browser shortcuts in fullscreen won't be broken by unexpected changes. It starts a full screen browser window, sends several key events normally consumed by browser, and checks whether these events are caught by the web page. BUG= 680809 Review-Url: https://codereview.chromium.org/2922773002 Cr-Commit-Position: refs/heads/master@{#486949} [add] https://crrev.com/bb317b9cc0055f7abebcd014dfb6c193548b4d88/chrome/browser/ui/browser_command_controller_interactive_browsertest.cc [modify] https://crrev.com/bb317b9cc0055f7abebcd014dfb6c193548b4d88/chrome/test/BUILD.gn [add] https://crrev.com/bb317b9cc0055f7abebcd014dfb6c193548b4d88/chrome/test/data/fullscreen_keyboardlock.html
,
Jul 24 2017
Hi guys, I have prepared a demo, which tries to catch keyboard events and prevent their default behavior. In an ideal world, this demo should catch all combinations of keys pressed: http://jsfiddle.net/p45f44zb/4/ In the latest Chrome 59, we can press F1, F5, Ctrl+S, Ctrl+O, Ctrl+F, Ctrl+J, Ctrl+H and nothing happens (default behavior is prevented). But pressing Ctrl+N, Ctrl+T, Ctrl+W still executes the default Chrome action. What is the point in preventing almost all Chrome shortcuts, but not preventing these three? Regular webpages would never try to prevent such shortcuts (because their visitors may complain). But in rare cases, where Ctrl+N or Ctrl+T is really needed, why don't you give it to the webpage?
,
Jul 24 2017
Hi, Ivan, This feature has several restrictions, 1. The web page needs to be fullscreen state. For most of the shortcuts, html fullscreen (Element.requestFullscreen()) or browser fullscreen (F11) do not make any differences. Except for Escape key, it cannot be captured by web page if html fullscreen is used. 2. You need to preventDefault() the keydown events. Chrome consumes some accelerators, for example, Ctrl + N, Ctrl + T, Ctrl + W, during keydown event. You may refer to a test html page at https://cs.chromium.org/chromium/src/chrome/test/data/fullscreen_keyboardlock.html?q=fullscreen_key&sq=package:chromium&l=1.
,
Jul 25 2017
Please remember that non-fullscreen availability of this feature is a must-have *before* Chrome packaged app support is dropped on non-CrOS platforms. So please plan for such an implementation now rather than waiting for something to happen. This is because right now, packaged apps are used to implement many remote access applications such as WebEx, Zoom, TeamViewer, and even simple things like ssh and mosh -- and these are often, and in the latter cases almost always, run in non-fullscreen mode. Once packaged app support disappears from most platforms, all of these apps will become vulnerable to accelerator key interception by Chrome.
,
Jul 26 2017
I don't think we will solve this for non-fullscreen browser tabs, but if the user installs the app to run in a window, it makes sense that we do not capture those shortcuts. So at least there would be that solution for users (and that's still the same or less work for users than installing a Chrome app). Issue 748946 .
,
Aug 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a4795877b3e11ab9a1193397b13c18e402f8e7f4 commit a4795877b3e11ab9a1193397b13c18e402f8e7f4 Author: Hzj_jie <zijiehe@chromium.org> Date: Thu Aug 10 19:35:24 2017 Add tests to ensure browser shortcuts should be handled in fullscreen This change adds several tests to ensure in both browser fullscreen and HTML fullscreen, if preventDefault() is not performed, browser shortcuts should still take effect. ShortcutsShouldTakeEffectInJsFullscreen test let the about:blank page enter HTML fullscreen by using document.body.webkitRequestFullscreen(). ShortcutsShouldTakeEffectInBrowserFullscreen test uses default page and "F11" shortcut to test the behavior in browser fullscreen. After change https://codereview.chromium.org/2781633003, in fullscreen, most of the shortcuts will be sent to renderer first. So various observing-patterns are included in this change to detect the asynchronized actions. Bug: chromium:680809 , chromium:737307 Change-Id: I0e326d234bed1400882bf011331ab9b62f3adbc9 Reviewed-on: https://chromium-review.googlesource.com/592313 Commit-Queue: Zijie He <zijiehe@chromium.org> Reviewed-by: Michael Wasserman <msw@chromium.org> Cr-Commit-Position: refs/heads/master@{#493500} [modify] https://crrev.com/a4795877b3e11ab9a1193397b13c18e402f8e7f4/chrome/browser/ui/browser_command_controller_interactive_browsertest.cc
,
Aug 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/744be8fe99a4817127e5f1ff8715556fde6ecd1a commit 744be8fe99a4817127e5f1ff8715556fde6ecd1a Author: Walter Korman <wkorman@chromium.org> Date: Thu Aug 10 21:37:49 2017 Revert "Add tests to ensure browser shortcuts should be handled in fullscreen" This reverts commit a4795877b3e11ab9a1193397b13c18e402f8e7f4. Reason for revert: <INSERT REASONING HERE> Original change's description: > Add tests to ensure browser shortcuts should be handled in fullscreen > > This change adds several tests to ensure in both browser fullscreen and HTML > fullscreen, if preventDefault() is not performed, browser shortcuts should still > take effect. > > ShortcutsShouldTakeEffectInJsFullscreen test let the about:blank page enter HTML > fullscreen by using document.body.webkitRequestFullscreen(). > ShortcutsShouldTakeEffectInBrowserFullscreen test uses default page and "F11" > shortcut to test the behavior in browser fullscreen. > > After change https://codereview.chromium.org/2781633003, in fullscreen, most of > the shortcuts will be sent to renderer first. So various observing-patterns are > included in this change to detect the asynchronized actions. > > Bug: chromium:680809 , chromium:737307 > Change-Id: I0e326d234bed1400882bf011331ab9b62f3adbc9 > Reviewed-on: https://chromium-review.googlesource.com/592313 > Commit-Queue: Zijie He <zijiehe@chromium.org> > Reviewed-by: Michael Wasserman <msw@chromium.org> > Cr-Commit-Position: refs/heads/master@{#493500} TBR=msw@chromium.org,zijiehe@chromium.org Change-Id: I7ea477c7ab0cc2b5b8e575f4490366f6c66accc5 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:680809 , chromium:737307 , chromium:754447 Reviewed-on: https://chromium-review.googlesource.com/610943 Reviewed-by: Walter Korman <wkorman@chromium.org> Commit-Queue: Walter Korman <wkorman@chromium.org> Cr-Commit-Position: refs/heads/master@{#493553} [modify] https://crrev.com/744be8fe99a4817127e5f1ff8715556fde6ecd1a/chrome/browser/ui/browser_command_controller_interactive_browsertest.cc
,
Aug 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/09b4239b6843cd936f03c4a1ffe1041194a8fdac commit 09b4239b6843cd936f03c4a1ffe1041194a8fdac Author: Hzj_jie <zijiehe@chromium.org> Date: Thu Aug 10 23:14:05 2017 Reland "Add tests to ensure browser shortcuts should be handled in fullscreen" This is a reland of a4795877b3e11ab9a1193397b13c18e402f8e7f4 Original change's description: > Add tests to ensure browser shortcuts should be handled in fullscreen > > This change adds several tests to ensure in both browser fullscreen and HTML > fullscreen, if preventDefault() is not performed, browser shortcuts should still > take effect. > > ShortcutsShouldTakeEffectInJsFullscreen test let the about:blank page enter HTML > fullscreen by using document.body.webkitRequestFullscreen(). > ShortcutsShouldTakeEffectInBrowserFullscreen test uses default page and "F11" > shortcut to test the behavior in browser fullscreen. > > After change https://codereview.chromium.org/2781633003, in fullscreen, most of > the shortcuts will be sent to renderer first. So various observing-patterns are > included in this change to detect the asynchronized actions. > > Bug: chromium:680809 , chromium:737307 > Change-Id: I0e326d234bed1400882bf011331ab9b62f3adbc9 > Reviewed-on: https://chromium-review.googlesource.com/592313 > Commit-Queue: Zijie He <zijiehe@chromium.org> > Reviewed-by: Michael Wasserman <msw@chromium.org> > Cr-Commit-Position: refs/heads/master@{#493500} Bug: chromium:680809 , chromium:737307 Change-Id: If9977bd167e9c382eeed377c01906706e895d7f3 TBR: msw@chromium.org Change-Id: If9977bd167e9c382eeed377c01906706e895d7f3 Reviewed-on: https://chromium-review.googlesource.com/611220 Commit-Queue: Zijie He <zijiehe@chromium.org> Reviewed-by: Zijie He <zijiehe@chromium.org> Cr-Commit-Position: refs/heads/master@{#493590} [modify] https://crrev.com/09b4239b6843cd936f03c4a1ffe1041194a8fdac/chrome/browser/ui/browser_command_controller_interactive_browsertest.cc
,
Aug 11 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4c5310e47304005d5dee153c483b2a1c22fa728d commit 4c5310e47304005d5dee153c483b2a1c22fa728d Author: Zijie He <zijiehe@chromium.org> Date: Fri Aug 11 00:48:09 2017 Revert "Reland "Add tests to ensure browser shortcuts should be handled in fullscreen"" This reverts commit 09b4239b6843cd936f03c4a1ffe1041194a8fdac. Reason for revert: <INSERT REASONING HERE> Original change's description: > Reland "Add tests to ensure browser shortcuts should be handled in fullscreen" > > This is a reland of a4795877b3e11ab9a1193397b13c18e402f8e7f4 > Original change's description: > > Add tests to ensure browser shortcuts should be handled in fullscreen > > > > This change adds several tests to ensure in both browser fullscreen and HTML > > fullscreen, if preventDefault() is not performed, browser shortcuts should still > > take effect. > > > > ShortcutsShouldTakeEffectInJsFullscreen test let the about:blank page enter HTML > > fullscreen by using document.body.webkitRequestFullscreen(). > > ShortcutsShouldTakeEffectInBrowserFullscreen test uses default page and "F11" > > shortcut to test the behavior in browser fullscreen. > > > > After change https://codereview.chromium.org/2781633003, in fullscreen, most of > > the shortcuts will be sent to renderer first. So various observing-patterns are > > included in this change to detect the asynchronized actions. > > > > Bug: chromium:680809 , chromium:737307 > > Change-Id: I0e326d234bed1400882bf011331ab9b62f3adbc9 > > Reviewed-on: https://chromium-review.googlesource.com/592313 > > Commit-Queue: Zijie He <zijiehe@chromium.org> > > Reviewed-by: Michael Wasserman <msw@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#493500} > > Bug: chromium:680809 , chromium:737307 > Change-Id: If9977bd167e9c382eeed377c01906706e895d7f3 > > TBR: msw@chromium.org > Change-Id: If9977bd167e9c382eeed377c01906706e895d7f3 > Reviewed-on: https://chromium-review.googlesource.com/611220 > Commit-Queue: Zijie He <zijiehe@chromium.org> > Reviewed-by: Zijie He <zijiehe@chromium.org> > Cr-Commit-Position: refs/heads/master@{#493590} TBR=msw@chromium.org,zijiehe@chromium.org Change-Id: Ie17ceef57a3f809f114ea73835ada7e91232ea89 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:680809 , chromium:737307 Reviewed-on: https://chromium-review.googlesource.com/610631 Reviewed-by: Zijie He <zijiehe@chromium.org> Commit-Queue: Zijie He <zijiehe@chromium.org> Cr-Commit-Position: refs/heads/master@{#493625} [modify] https://crrev.com/4c5310e47304005d5dee153c483b2a1c22fa728d/chrome/browser/ui/browser_command_controller_interactive_browsertest.cc
,
Aug 11 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/24cdbc10fbc7474216e7648a0bcb6fa300e0e578 commit 24cdbc10fbc7474216e7648a0bcb6fa300e0e578 Author: Hzj_jie <zijiehe@chromium.org> Date: Fri Aug 11 20:02:24 2017 Reland "Reland "Add tests to ensure browser shortcuts should be handled in fullscreen"" This is a reland of 09b4239b6843cd936f03c4a1ffe1041194a8fdac Executing document.body.webkitRequestFullscreen() directly in content::ExecuteScript() seems not reliable. Indeed we do not have an active example in our code base (https://cs.chromium.org/search/?q=webkitrequestfullscreen%5C(%5C)+lang:c%2B%2B&sq=package:chromium&type=cs). So I revert back to use page + keydown event. The page is too small, I directly embedded it into the source code. I executed the test case 10 times on both ChromeOS and Ubuntu. No flakiness was caught. Original change's description: > Reland "Add tests to ensure browser shortcuts should be handled in fullscreen" > > This is a reland of a4795877b3e11ab9a1193397b13c18e402f8e7f4 > Original change's description: > > Add tests to ensure browser shortcuts should be handled in fullscreen > > > > This change adds several tests to ensure in both browser fullscreen and HTML > > fullscreen, if preventDefault() is not performed, browser shortcuts should still > > take effect. > > > > ShortcutsShouldTakeEffectInJsFullscreen test let the about:blank page enter HTML > > fullscreen by using document.body.webkitRequestFullscreen(). > > ShortcutsShouldTakeEffectInBrowserFullscreen test uses default page and "F11" > > shortcut to test the behavior in browser fullscreen. > > > > After change https://codereview.chromium.org/2781633003, in fullscreen, most of > > the shortcuts will be sent to renderer first. So various observing-patterns are > > included in this change to detect the asynchronized actions. > > > > Bug: chromium:680809 , chromium:737307 > > Change-Id: I0e326d234bed1400882bf011331ab9b62f3adbc9 > > Reviewed-on: https://chromium-review.googlesource.com/592313 > > Commit-Queue: Zijie He <zijiehe@chromium.org> > > Reviewed-by: Michael Wasserman <msw@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#493500} > > Bug: chromium:680809 , chromium:737307 > Change-Id: If9977bd167e9c382eeed377c01906706e895d7f3 > > TBR: msw@chromium.org > Change-Id: If9977bd167e9c382eeed377c01906706e895d7f3 > Reviewed-on: https://chromium-review.googlesource.com/611220 > Commit-Queue: Zijie He <zijiehe@chromium.org> > Reviewed-by: Zijie He <zijiehe@chromium.org> > Cr-Commit-Position: refs/heads/master@{#493590} Bug: chromium:680809 , chromium:737307 Change-Id: Id788db366d93d45e4ab093cff6adbae2d8f6969f Reviewed-on: https://chromium-review.googlesource.com/611221 Commit-Queue: Zijie He <zijiehe@chromium.org> Reviewed-by: Michael Wasserman <msw@chromium.org> Cr-Commit-Position: refs/heads/master@{#493838} [modify] https://crrev.com/24cdbc10fbc7474216e7648a0bcb6fa300e0e578/chrome/browser/ui/browser_command_controller_interactive_browsertest.cc
,
Sep 22 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ee197db7902475e784960c8bd65f001982871a21 commit ee197db7902475e784960c8bd65f001982871a21 Author: Zijie He <zijiehe@chromium.org> Date: Fri Sep 22 17:45:26 2017 [System-Keyboard-Lock] Add RenderFrameHost and WebContents into KeyboardLockServiceImpl According to the prototype, we need to access WebContents in KeyboardLockServiceImpl. So this change forwards RenderFrameHost to the constructor of KeyboardLockServiceImpl to initialize WebContents pointer. Bug: 680809 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation Change-Id: Ic36fb7fe4dcd90aaa838eacc549100c71b08200c Reviewed-on: https://chromium-review.googlesource.com/677638 Reviewed-by: Avi Drissman <avi@chromium.org> Commit-Queue: Zijie He <zijiehe@chromium.org> Cr-Commit-Position: refs/heads/master@{#503787} [modify] https://crrev.com/ee197db7902475e784960c8bd65f001982871a21/content/browser/frame_host/render_frame_host_impl.cc [modify] https://crrev.com/ee197db7902475e784960c8bd65f001982871a21/content/browser/keyboard_lock/keyboard_lock_service_impl.cc [modify] https://crrev.com/ee197db7902475e784960c8bd65f001982871a21/content/browser/keyboard_lock/keyboard_lock_service_impl.h
,
Dec 11 2017
,
Dec 12 2017
,
Jan 12 2018
,
Feb 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/095fd6db7c9288031a060e480e2b27c9b887dfbe commit 095fd6db7c9288031a060e480e2b27c9b887dfbe Author: Joe Downing <joedow@chromium.org> Date: Thu Feb 01 18:40:36 2018 Adding a Feature flag for the KeyboardLock API This flag will be used for development / testing of the KeyboardLock feature. My plan is to have something available for testing (but behind the flag) in M66. We also plan to use this flag for rolling out the change when it is ready for launch. BUG= 680809 Change-Id: I2e4f7ea16c458cab053a998ae1de4d9d7ab7fbec Reviewed-on: https://chromium-review.googlesource.com/896022 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Gary Kacmarcik <garykac@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#533750} [modify] https://crrev.com/095fd6db7c9288031a060e480e2b27c9b887dfbe/chrome/browser/about_flags.cc [modify] https://crrev.com/095fd6db7c9288031a060e480e2b27c9b887dfbe/chrome/browser/flag_descriptions.cc [modify] https://crrev.com/095fd6db7c9288031a060e480e2b27c9b887dfbe/chrome/browser/flag_descriptions.h [modify] https://crrev.com/095fd6db7c9288031a060e480e2b27c9b887dfbe/chrome/browser/ui/exclusive_access/exclusive_access_manager.cc [modify] https://crrev.com/095fd6db7c9288031a060e480e2b27c9b887dfbe/content/child/runtime_features.cc [modify] https://crrev.com/095fd6db7c9288031a060e480e2b27c9b887dfbe/content/public/common/content_features.cc [modify] https://crrev.com/095fd6db7c9288031a060e480e2b27c9b887dfbe/content/public/common/content_features.h [modify] https://crrev.com/095fd6db7c9288031a060e480e2b27c9b887dfbe/tools/metrics/histograms/enums.xml
,
Feb 6 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2de3417745c6b2464af599957013ddfbcbd95b2c commit 2de3417745c6b2464af599957013ddfbcbd95b2c Author: Joe Downing <joedow@chromium.org> Date: Tue Feb 06 05:42:59 2018 Adding UMA entries for KeyboardLock APIs This change adds UMA entries so we can determine how often the new API is called and in the case of the Lock method, whether the caller supplied a set of keys or if they requested all keys. BUG= 680809 Change-Id: I5c6f1a29e5aa2cb51cb44d80f71f4201e8381219 Reviewed-on: https://chromium-review.googlesource.com/898436 Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: Ilya Sherman <isherman@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#534638} [modify] https://crrev.com/2de3417745c6b2464af599957013ddfbcbd95b2c/content/browser/keyboard_lock/keyboard_lock_service_impl.cc [modify] https://crrev.com/2de3417745c6b2464af599957013ddfbcbd95b2c/tools/metrics/histograms/enums.xml [modify] https://crrev.com/2de3417745c6b2464af599957013ddfbcbd95b2c/tools/metrics/histograms/histograms.xml
,
Feb 12 2018
Link to the spec in the description 404-ed. Is there a better link?
,
Feb 25 2018
If and when this needs actual testing, we are happy to pilot it on https://rainway.io. I know when MSE was first implemented it was limited to a handful of sites so I'm sure we can help with the gathering of telemetry.
,
Feb 26 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac commit a8e74acf4b75675331de05c1ddbd5b996ca7f4ac Author: Joe Downing <joedow@chromium.org> Date: Mon Feb 26 17:10:24 2018 [KeyboardLock] KeyboardHook impl and WindowTreeHost integration This CL introduces a Windows implementation of the KeyboardHook class as well as a simple integration with the low-level window classes used in Aura for Windows. Changes to WindowTreeHostPlatform / PlatformWindow will be made in a separate CL. I will send out that change once the method names and platform hook scope questions have been answered. The next CL will build on this work in the content layer: https://chromium-review.googlesource.com/c/chromium/src/+/905507 BUG= 680809 Change-Id: I8d35c895d80a58c64ff5b2bc119d5ee340790050 Reviewed-on: https://chromium-review.googlesource.com/900344 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: Shu Chen <shuchen@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Cr-Commit-Position: refs/heads/master@{#539170} [modify] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/headless/lib/browser/headless_window_tree_host.cc [modify] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/headless/lib/browser/headless_window_tree_host.h [modify] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/aura/BUILD.gn [modify] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/aura/mus/window_tree_client_unittest.cc [add] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/aura/scoped_keyboard_hook.cc [add] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/aura/scoped_keyboard_hook.h [modify] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/aura/window.cc [modify] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/aura/window.h [modify] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/aura/window_tree_host.cc [modify] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/aura/window_tree_host.h [modify] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/aura/window_tree_host_platform.cc [modify] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/aura/window_tree_host_platform.h [modify] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/events/BUILD.gn [modify] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/events/event_constants.h [add] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/events/keyboard_hook.h [add] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/events/keyboard_hook_base.cc [add] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/events/keyboard_hook_base.h [add] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/events/win/keyboard_hook_win.cc [add] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/events/x/keyboard_hook_posix.cc [modify] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/views/widget/desktop_aura/desktop_window_tree_host_win.cc [modify] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/views/widget/desktop_aura/desktop_window_tree_host_win.h [modify] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc [modify] https://crrev.com/a8e74acf4b75675331de05c1ddbd5b996ca7f4ac/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h
,
Mar 8 2018
,
Mar 22 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c790e5d1f9a37cdd519b17c39b46313c8162ecdf commit c790e5d1f9a37cdd519b17c39b46313c8162ecdf Author: Joe Downing <joedow@chromium.org> Date: Thu Mar 22 07:16:29 2018 Move KeyboardLock API methods to a 'keyboard' object This change moves the KeyboardLock API methods to a 'keyboard' namespace on the Navigator object. We are doing this work now as there has been a request for additional keyboard functionality that would also be placed on the new keyboard object and we wanted to move the KeyboardLock methods there for consistency before we launch. KeyboardLock API Spec is here: https://w3c.github.io/keyboard-lock/#API Old calling pattern: Navigator.keyboardLock(); Navigator.keyboardUnlock(); New calling pattern: Navigator.keyboard.lock(); Navigator.keyboard.unlock(); Note: The main logic in the KeyboardLock.cpp class and tests is the same as it was, however the file changed enough that git does not recognize it as a file move. BUG= 680809 Change-Id: I234b2ab12d5ecd44c894ed5103863fd96fd548d4 Reviewed-on: https://chromium-review.googlesource.com/969656 Reviewed-by: Philip Jägenstedt <foolip@chromium.org> Reviewed-by: Gary Kacmarcik <garykac@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Commit-Queue: Daniel Cheng <dcheng@chromium.org> Cr-Commit-Position: refs/heads/master@{#544996} [add] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/LayoutTests/external/wpt/interfaces/keyboard-lock.idl [delete] https://crrev.com/6eaf64fc5dfff9b820ed79cfb664487aff9cf7b1/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/idlharness.https-expected.txt [modify] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/idlharness.https.html [add] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-keyboard-lock-two-parallel-requests.https-expected.txt [add] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-keyboard-lock-two-parallel-requests.https.html [add] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-keyboard-lock-two-sequential-requests.https.html [rename] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-keyboard-lock.https.html [rename] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-keyboard-unlock.https.html [delete] https://crrev.com/6eaf64fc5dfff9b820ed79cfb664487aff9cf7b1/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-keyboardLock-two-parallel-requests.https-expected.txt [delete] https://crrev.com/6eaf64fc5dfff9b820ed79cfb664487aff9cf7b1/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-keyboardLock-two-parallel-requests.https.html [delete] https://crrev.com/6eaf64fc5dfff9b820ed79cfb664487aff9cf7b1/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-keyboardLock-two-sequential-requests.https.html [modify] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-expected.txt [modify] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/Source/modules/BUILD.gn [add] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/Source/modules/keyboard/BUILD.gn [add] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/Source/modules/keyboard/Keyboard.cpp [add] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/Source/modules/keyboard/Keyboard.h [add] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/Source/modules/keyboard/Keyboard.idl [add] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/Source/modules/keyboard/KeyboardLock.cpp [add] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/Source/modules/keyboard/KeyboardLock.h [add] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/Source/modules/keyboard/NavigatorKeyboard.cpp [add] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/Source/modules/keyboard/NavigatorKeyboard.h [add] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/Source/modules/keyboard/NavigatorKeyboard.idl [add] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/Source/modules/keyboard/OWNERS [delete] https://crrev.com/6eaf64fc5dfff9b820ed79cfb664487aff9cf7b1/third_party/WebKit/Source/modules/keyboard_lock/BUILD.gn [delete] https://crrev.com/6eaf64fc5dfff9b820ed79cfb664487aff9cf7b1/third_party/WebKit/Source/modules/keyboard_lock/NavigatorKeyboardLock.cpp [delete] https://crrev.com/6eaf64fc5dfff9b820ed79cfb664487aff9cf7b1/third_party/WebKit/Source/modules/keyboard_lock/NavigatorKeyboardLock.h [delete] https://crrev.com/6eaf64fc5dfff9b820ed79cfb664487aff9cf7b1/third_party/WebKit/Source/modules/keyboard_lock/NavigatorKeyboardLock.idl [modify] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/Source/modules/modules_idl_files.gni [modify] https://crrev.com/c790e5d1f9a37cdd519b17c39b46313c8162ecdf/third_party/WebKit/public/platform/modules/keyboard_lock/keyboard_lock.mojom
,
Mar 22 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/192998b23314472418e1a2a9eb5b88dc319e342c commit 192998b23314472418e1a2a9eb5b88dc319e342c Author: Joe Downing <joedow@chromium.org> Date: Thu Mar 22 15:51:36 2018 [KeyboardLock] Content layer integration This change completes the KeybaoardLockServiceImpl class and hooks it into the RenderWidgetHostImpl class. RenderWidgetHostImpl is responsible for tracking the keys requested to be locked, forwarding the request to WebContentsImpl, handling the response from WebContentsImpl once the UX is fullscreen, and then calling into the RenderWidgetHostView impl to actually request KeyboardLock. WebContentsImpl tracks the RenderWidgetHostImpl instance which has an active KeyboardLock request. It also calls back into that instance once tab-initiated fullscreen is entered/exited. Note that there are two other approaches I could have taken here: I could have used a WebContentsObserver class or I could have pushed this logic up into the chrome layer (ExclusiveAccessManager related class). I chose the current approach as the logic needed for calling down to the RenderWidgetHostImpl class is simple and only needed in a few places. RenderWidgetHostView is the class which will handle platform specialization for the KeyboardLock request. I've implemented this logic for Aura in this CL, macOS will be completed in a follow-up. My next CL will integrate KeyboardLock into the chrome layer and implement ESC key handling and UX string display. Also to be added are some browser tests for this functionality. These will be required before we enable this functionality by default. BUG= 680809 Change-Id: I703d1ba27592943fff80432303583499d789a2ec Reviewed-on: https://chromium-review.googlesource.com/939535 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Nick Carter <nick@chromium.org> Cr-Commit-Position: refs/heads/master@{#545096} [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/browser/frame_host/render_frame_host_impl.cc [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/browser/keyboard_lock/keyboard_lock_service_impl.cc [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/browser/keyboard_lock/keyboard_lock_service_impl.h [add] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/browser/keyboard_lock_browsertest.cc [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/browser/renderer_host/render_widget_host_delegate.cc [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/browser/renderer_host/render_widget_host_delegate.h [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/browser/renderer_host/render_widget_host_impl.cc [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/browser/renderer_host/render_widget_host_impl.h [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/browser/renderer_host/render_widget_host_view_aura.cc [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/browser/renderer_host/render_widget_host_view_aura.h [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/browser/renderer_host/render_widget_host_view_base.cc [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/browser/renderer_host/render_widget_host_view_base.h [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/browser/renderer_host/render_widget_host_view_event_handler.cc [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/browser/renderer_host/render_widget_host_view_event_handler.h [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/browser/web_contents/web_contents_impl.cc [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/browser/web_contents/web_contents_impl.h [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/public/browser/render_widget_host_view.h [modify] https://crrev.com/192998b23314472418e1a2a9eb5b88dc319e342c/content/test/BUILD.gn
,
Mar 22 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a350ec6cfb3c838f24228f8e216efa340927a904 commit a350ec6cfb3c838f24228f8e216efa340927a904 Author: Joe Downing <joedow@chromium.org> Date: Thu Mar 22 21:21:05 2018 [KeyboardLock] Adding Blink API tracking for KeyboardLock feature This change adds simple counters for the 2 KeyboardLock methods. We have some UMA metrics for this API, however we have additional functionality planned for the navigator keyboard node and would like to use the same type of counter for all of the exposed methods. The existing UMA is still useful as we have plans for additional data that we can't get from the blink metrics. BUG= 680809 Change-Id: I73aca4d5de67cdad73a1b90de56f607f07ea836a Reviewed-on: https://chromium-review.googlesource.com/975822 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Gary Kacmarcik <garykac@chromium.org> Cr-Commit-Position: refs/heads/master@{#545253} [modify] https://crrev.com/a350ec6cfb3c838f24228f8e216efa340927a904/third_party/WebKit/Source/modules/keyboard/Keyboard.idl [modify] https://crrev.com/a350ec6cfb3c838f24228f8e216efa340927a904/third_party/WebKit/public/platform/web_feature.mojom [modify] https://crrev.com/a350ec6cfb3c838f24228f8e216efa340927a904/tools/metrics/histograms/enums.xml
,
Mar 26 2018
,
Mar 28 2018
How close is this to being ready to test on Canary? We have some partners interested in testing this.
,
Mar 28 2018
My goal is to have Windows working end to end by the M67 release branch date and available for limited testing by manually enabling the feature flag. Linux will *probably* work as well at that point given that it also uses Aura. The caveat to this date is that I have ~4 medium sized patches to land to get there. I will update the bug once it is ready for limited testing on Canary. Limited testing above means it should work for some core scenarios but there will likely be bugs : )
,
Apr 9 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/87cdad6f9ffab348754c08e08fa8a17acfffe47f commit 87cdad6f9ffab348754c08e08fa8a17acfffe47f Author: Joe Downing <joedow@chromium.org> Date: Mon Apr 09 06:27:14 2018 [KeyboardLock] Adding key event handling logic for Aura This CL adds a helper method to the event handling class used by Aura to mark events which originated from a KeyboardHook such that they are not handled by the browser. The idea here is that if KeyboardLock is enabled, we check to see if the key_code is in the list of keys to filter. If so, then we mark the event 'skip_in_browser' so it isn't handled by the browser. The exception is ESC which we want to give the fullscreen exit handler a chance to handle so that they user can exit fullscreen mode via the keyboard. This CL also makes one fix to the Windows KeyboardHook class where I was intercepting keys based on the key_code instead of the scan_code which is a problem because the keys_to_lock set that is passed down to it represents the 'native key codes' aka scan codes of the keys to intercept. BUG= 680809 Change-Id: I795dd57bf68ebea777fecf8cd579f8776fb99ee2 Reviewed-on: https://chromium-review.googlesource.com/940531 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#549113} [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/content/browser/renderer_host/render_widget_host_view_event_handler.cc [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/content/browser/renderer_host/render_widget_host_view_event_handler.h [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/headless/lib/browser/headless_window_tree_host.cc [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/headless/lib/browser/headless_window_tree_host.h [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/ui/aura/scoped_keyboard_hook.cc [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/ui/aura/scoped_keyboard_hook.h [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/ui/aura/window_tree_host.h [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/ui/aura/window_tree_host_platform.cc [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/ui/aura/window_tree_host_platform.h [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/ui/events/keyboard_hook.h [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/ui/events/keyboard_hook_base.cc [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/ui/events/keyboard_hook_base.h [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/ui/events/win/keyboard_hook_win.cc [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/ui/views/widget/desktop_aura/desktop_window_tree_host_win.cc [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/ui/views/widget/desktop_aura/desktop_window_tree_host_win.h [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc [modify] https://crrev.com/87cdad6f9ffab348754c08e08fa8a17acfffe47f/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h
,
Apr 9 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/13dd76bc86e2d4512337a9fe84e07019b7a2b703 commit 13dd76bc86e2d4512337a9fe84e07019b7a2b703 Author: Joe Downing <joedow@chromium.org> Date: Mon Apr 09 18:32:15 2018 [KeyboardLock] Chrome UX layer integration for fullscreen management This CL integrates the KeyboardLock feature into the Chrome UX layer. Integrating in the ExclusiveAccessManager allows fine grained control over when KeyboardLock is activated (for instance we want keyboard lock activated in tab-initiated fullscreen, but not in browser or content fullscreen. The FullscreenController provides that nuanced level of control for us. Also, Keyboardlock should only be available to one tab at a time which is conceptually the same as Fullscreen and PointerLock. Lastly, we need to integrate KeyboardLock logic into the mechanism used for exiting fullscreen and displaying the exit fullscreen instructions/bubble. Future CLs will add an animated exit UX which is tied to the press and hold gesture, and a rapid tap 'panic' timer which will reshow the exit instructions (these two behaviors were suggested as part of the UX design process). I have some initial browsertests for this feature however I have not added interactive browsertests yet as I would like to get feedback on the implementation before adding additional tests. I will add those in a follow-up CL if this impl looks good. BUG= 680809 Change-Id: I6588367875934b59ba979cef65a73707c3d85320 Reviewed-on: https://chromium-review.googlesource.com/989021 Reviewed-by: Dominick Ng <dominickn@chromium.org> Reviewed-by: Yuri Wiitala <miu@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: Ilya Sherman <isherman@chromium.org> Reviewed-by: Nick Carter <nick@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#549230} [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/browser/about_flags.cc [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/browser/ui/BUILD.gn [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/browser/ui/browser.cc [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/browser/ui/browser.h [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/browser/ui/browser_command_controller_interactive_browsertest.cc [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/browser/ui/exclusive_access/exclusive_access_bubble.h [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/browser/ui/exclusive_access/exclusive_access_bubble_hide_callback.h [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/browser/ui/exclusive_access/exclusive_access_controller_base.h [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/browser/ui/exclusive_access/exclusive_access_manager.cc [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/browser/ui/exclusive_access/exclusive_access_manager.h [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/browser/ui/exclusive_access/fullscreen_controller_browsertest.cc [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/browser/ui/exclusive_access/fullscreen_controller_test.cc [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/browser/ui/exclusive_access/fullscreen_controller_test.h [add] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/browser/ui/exclusive_access/keyboard_lock_controller.cc [add] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/browser/ui/exclusive_access/keyboard_lock_controller.h [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/browser/ui/exclusive_access/mouse_lock_controller.h [rename] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/chrome/test/data/fullscreen_keyboardlock/fullscreen_keyboardlock.html [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/content/browser/keyboard_lock_browsertest.cc [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/content/browser/renderer_host/render_widget_host_delegate.cc [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/content/browser/renderer_host/render_widget_host_delegate.h [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/content/browser/renderer_host/render_widget_host_impl.cc [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/content/browser/web_contents/web_contents_impl.cc [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/content/browser/web_contents/web_contents_impl.h [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/content/public/browser/web_contents.h [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/content/public/browser/web_contents_delegate.h [modify] https://crrev.com/13dd76bc86e2d4512337a9fe84e07019b7a2b703/tools/metrics/histograms/histograms.xml
,
Apr 11 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f95205324e4a3b757b858b7088adb9b298e3ae17 commit f95205324e4a3b757b858b7088adb9b298e3ae17 Author: Joe Downing <joedow@chromium.org> Date: Wed Apr 11 01:28:52 2018 [KeyboardLock] Updating Mojo service impl to return error codes The previous KeyboardLockService implementation always returned success even when no KeyboardLock request was registered due to an error. This CL adds errors for two known error conditions which are now communicated back to javascript by rejecting the promise. The messages passed are meant to help developers as they are building their website, they are not something that can/should be used post-development (i.e. they represent unrecoverable errors). BUG= 680809 Change-Id: I7748d0f0c7b8688b4e945e6aa349d75b2a9757ca Reviewed-on: https://chromium-review.googlesource.com/1003216 Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: Gary Kacmarcik <garykac@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#549716} [modify] https://crrev.com/f95205324e4a3b757b858b7088adb9b298e3ae17/content/browser/keyboard_lock/keyboard_lock_service_impl.cc [modify] https://crrev.com/f95205324e4a3b757b858b7088adb9b298e3ae17/content/browser/keyboard_lock_browsertest.cc [modify] https://crrev.com/f95205324e4a3b757b858b7088adb9b298e3ae17/third_party/blink/public/platform/modules/keyboard_lock/keyboard_lock.mojom [modify] https://crrev.com/f95205324e4a3b757b858b7088adb9b298e3ae17/third_party/blink/renderer/modules/keyboard/keyboard_lock.cc
,
Apr 11 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1a958084bf28aa49666a2c7f7f596d3a216ec3bd commit 1a958084bf28aa49666a2c7f7f596d3a216ec3bd Author: Joe Downing <joedow@chromium.org> Date: Wed Apr 11 01:38:14 2018 [KeyboardLock] Updating API to reject the first promise if lock is called twice Per the W3C spec, when navigator.keyboard.lock() is called a second time (or more), any previous, pending promises should be rejected. The old behavior of the API was to reject the newest promise which is not correct. As part of this cleanup, I am also using DomExceptions instead of raw strings for the rejection. This allows us to clean up the test code (which fails if a raw string is returned in the reject call). BUG= 680809 Change-Id: Ic4f2563a6ccc22a434f8e6079f1995d9e584f9aa Reviewed-on: https://chromium-review.googlesource.com/1003472 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Gary Kacmarcik <garykac@chromium.org> Cr-Commit-Position: refs/heads/master@{#549719} [delete] https://crrev.com/5d7e145fe43b61f5ace1dd657ba02a743adaf9cb/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-keyboard-lock-two-parallel-requests.https-expected.txt [modify] https://crrev.com/1a958084bf28aa49666a2c7f7f596d3a216ec3bd/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-keyboard-lock-two-parallel-requests.https.html [modify] https://crrev.com/1a958084bf28aa49666a2c7f7f596d3a216ec3bd/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-keyboard-lock-two-sequential-requests.https.html [modify] https://crrev.com/1a958084bf28aa49666a2c7f7f596d3a216ec3bd/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-keyboard-lock.https.html [modify] https://crrev.com/1a958084bf28aa49666a2c7f7f596d3a216ec3bd/third_party/blink/renderer/modules/keyboard/keyboard_lock.cc [modify] https://crrev.com/1a958084bf28aa49666a2c7f7f596d3a216ec3bd/third_party/blink/renderer/modules/keyboard/keyboard_lock.h
,
Apr 12 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a18f3c9f38af724842502d5a49ac5c112f9bd2e0 commit a18f3c9f38af724842502d5a49ac5c112f9bd2e0 Author: Joe Downing <joedow@chromium.org> Date: Thu Apr 12 18:18:04 2018 [KeyboardLock] Simplifying press and hold ESC logic for fullscreen This CL simplifies the logic used for determing whether Chrome should use the press and hold ESC logic to exit fullscreen. The previous mechanism used a combination of three values (experiment flag, lock active, esc required). This can be simplified and bit and moved into a single method to determine which message to show the UI and whether to use the press and hold logic in the KeyboardLockController for exiting fullscreen. BUG= 680809 Change-Id: I25c80e5cfd6c3e318c815d233a51c447f7d2d8d4 Reviewed-on: https://chromium-review.googlesource.com/1007497 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Yuri Wiitala <miu@chromium.org> Cr-Commit-Position: refs/heads/master@{#550275} [modify] https://crrev.com/a18f3c9f38af724842502d5a49ac5c112f9bd2e0/chrome/browser/ui/exclusive_access/exclusive_access_manager.cc [modify] https://crrev.com/a18f3c9f38af724842502d5a49ac5c112f9bd2e0/chrome/browser/ui/exclusive_access/keyboard_lock_controller.cc
,
Apr 17 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a18f3c9f38af724842502d5a49ac5c112f9bd2e0 commit a18f3c9f38af724842502d5a49ac5c112f9bd2e0 Author: Joe Downing <joedow@chromium.org> Date: Thu Apr 12 18:18:04 2018 [KeyboardLock] Simplifying press and hold ESC logic for fullscreen This CL simplifies the logic used for determing whether Chrome should use the press and hold ESC logic to exit fullscreen. The previous mechanism used a combination of three values (experiment flag, lock active, esc required). This can be simplified and bit and moved into a single method to determine which message to show the UI and whether to use the press and hold logic in the KeyboardLockController for exiting fullscreen. BUG= 680809 Change-Id: I25c80e5cfd6c3e318c815d233a51c447f7d2d8d4 Reviewed-on: https://chromium-review.googlesource.com/1007497 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Yuri Wiitala <miu@chromium.org> Cr-Commit-Position: refs/heads/master@{#550275} [modify] https://crrev.com/a18f3c9f38af724842502d5a49ac5c112f9bd2e0/chrome/browser/ui/exclusive_access/exclusive_access_manager.cc [modify] https://crrev.com/a18f3c9f38af724842502d5a49ac5c112f9bd2e0/chrome/browser/ui/exclusive_access/keyboard_lock_controller.cc
,
Apr 17 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/190f4ac2295c7f9d1044ea55e82b234790880aa5 commit 190f4ac2295c7f9d1044ea55e82b234790880aa5 Author: Joe Downing <joedow@chromium.org> Date: Tue Apr 17 22:00:27 2018 [KeyboardLock] MacOS RWHV integration This change includes the integration of the MacOS KeyboardHook impl in the RenderWidgetHostViewMac and RenderWidgetHostViewCocoa classes. RWHVMac handles the lock/unlock calls from RenderWidgetHostImpl and forwards them to RWHVCocoa which handles the events and input routing. The RenderWidgetHostViewMac and RenderWidgetHostViewCocoa integration follows the same pattern I used for RenderWidgetHostViewAura and RenderWidgetHostViewEventHandler. The main difference between this impl and the Aura impl is that there is a bridge class between RWHVMac and RWHVCocoa (RenderWidgetHostViewNsBridgeView). BUG= 680809 Change-Id: I524c98c059ae4883bf597704c326b5a0055f1212 Reviewed-on: https://chromium-review.googlesource.com/989618 Reviewed-by: ccameron <ccameron@chromium.org> Reviewed-by: Nick Carter <nick@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#551491} [modify] https://crrev.com/190f4ac2295c7f9d1044ea55e82b234790880aa5/content/browser/keyboard_lock_browsertest.cc [add] https://crrev.com/190f4ac2295c7f9d1044ea55e82b234790880aa5/content/browser/keyboard_lock_browsertest.h [add] https://crrev.com/190f4ac2295c7f9d1044ea55e82b234790880aa5/content/browser/keyboard_lock_browsertest_mac.mm [modify] https://crrev.com/190f4ac2295c7f9d1044ea55e82b234790880aa5/content/browser/renderer_host/render_widget_host_ns_view_bridge.h [modify] https://crrev.com/190f4ac2295c7f9d1044ea55e82b234790880aa5/content/browser/renderer_host/render_widget_host_ns_view_bridge.mm [modify] https://crrev.com/190f4ac2295c7f9d1044ea55e82b234790880aa5/content/browser/renderer_host/render_widget_host_view_cocoa.h [modify] https://crrev.com/190f4ac2295c7f9d1044ea55e82b234790880aa5/content/browser/renderer_host/render_widget_host_view_cocoa.mm [modify] https://crrev.com/190f4ac2295c7f9d1044ea55e82b234790880aa5/content/browser/renderer_host/render_widget_host_view_mac.h [modify] https://crrev.com/190f4ac2295c7f9d1044ea55e82b234790880aa5/content/browser/renderer_host/render_widget_host_view_mac.mm [modify] https://crrev.com/190f4ac2295c7f9d1044ea55e82b234790880aa5/content/test/BUILD.gn
,
Apr 20 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a47843470aa36cd4c3a497df71b521ecc37ced4e commit a47843470aa36cd4c3a497df71b521ecc37ced4e Author: Joe Downing <joedow@chromium.org> Date: Fri Apr 20 01:24:38 2018 [KeyboardLock] Integrating the animated press and hold UI control This change integrates the FullscreenControlPopup with the KeyboardLock feature (via the ExclusiveAccessManager). The KeyboardLockController continues to own which WebContents is granted keyboard lock and the initial display of the exclusive access message, but now the FullscreenControlHost is responsible for showing the UI popup. I decided to go this route as the logic for mouse/touch exists in the FullscreenControlHost (via the events it is fed) and the alternative involved punching a hole through several interfaces to expose the popup to the KeyboardLockController. BUG= 680809 Change-Id: I152003587cc872b9e2f52883f0698fa26c5dea12 Reviewed-on: https://chromium-review.googlesource.com/1014633 Reviewed-by: Yuri Wiitala <miu@chromium.org> Reviewed-by: Robert Liao <robliao@chromium.org> Reviewed-by: Yuwei Huang <yuweih@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#552224} [modify] https://crrev.com/a47843470aa36cd4c3a497df71b521ecc37ced4e/chrome/browser/ui/exclusive_access/keyboard_lock_controller.cc [modify] https://crrev.com/a47843470aa36cd4c3a497df71b521ecc37ced4e/chrome/browser/ui/exclusive_access/keyboard_lock_controller.h [modify] https://crrev.com/a47843470aa36cd4c3a497df71b521ecc37ced4e/chrome/browser/ui/views/fullscreen_control/fullscreen_control_host.cc [modify] https://crrev.com/a47843470aa36cd4c3a497df71b521ecc37ced4e/chrome/browser/ui/views/fullscreen_control/fullscreen_control_host.h [modify] https://crrev.com/a47843470aa36cd4c3a497df71b521ecc37ced4e/chrome/browser/ui/views/fullscreen_control/fullscreen_control_view_interactive_uitest.cc
,
Apr 30 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0a445800d9af4815b80f5dd71e169b348804a154 commit 0a445800d9af4815b80f5dd71e169b348804a154 Author: Joe Downing <joedow@chromium.org> Date: Mon Apr 30 18:42:33 2018 [KeyboardLock] Enabling browser-level keyboard lock for X11 This CL adds a minimal KeyboardHook impl for X11 which enables browser-level keyboard lock functionality. I split up the original X11 KeyboardHook impl into two pieces as the browser level keyboard lock functionality is well understood and can be tested now whereas the system level keyboard lock for X11 has a few questions that need to be resolved before checking it in. Therefore I want to get the the browser-level lock functionality working so it can be tested in Canary while I sort out the system shortcut aspect of the impl. BUG= 680809 Change-Id: I47ea23f50d6c61364343574ab4cdc73bd17f0c3f Reviewed-on: https://chromium-review.googlesource.com/1034272 Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#554822} [modify] https://crrev.com/0a445800d9af4815b80f5dd71e169b348804a154/ui/events/BUILD.gn [add] https://crrev.com/0a445800d9af4815b80f5dd71e169b348804a154/ui/events/mac/keyboard_hook_mac.mm [delete] https://crrev.com/1d649dd8c61b03fc7aefe1e67b4b194a97d3e169/ui/events/x/keyboard_hook_posix.cc [add] https://crrev.com/0a445800d9af4815b80f5dd71e169b348804a154/ui/events/x/keyboard_hook_x11.cc
,
May 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/64999bc278706e59d6e0d2d55b95cdd82eca994a commit 64999bc278706e59d6e0d2d55b95cdd82eca994a Author: Joe Downing <joedow@chromium.org> Date: Tue May 01 04:43:00 2018 [KeyboardLock] Show fullscreen exit instructions after repeated ESC keypresses Engaging KeyboardLock with ESC set as a reserved key will require the user to press and hold the ESC key to exit fullscreen. The instructions on what action to take to exit are displayed when fullscreen is entered, however they are not shown again. If the user did not read the instructions the first time then they may become frustrated and press the ESC key rapidly. In this case we want to display the instructions again for them so they can exit. The other consideration is that we don't want to display the instructions too often as that will annoy the user. Thus we need to find a balance between number of keypresses and time winodw so that we show the instructions when they will be useful and keep them hidden when the user is just interacting with the website normally. BUG= 680809 Change-Id: I80d6cf6828b1cded20ec66f6828d5efa3ac2e9a1 Reviewed-on: https://chromium-review.googlesource.com/1019604 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: ccameron <ccameron@chromium.org> Reviewed-by: Yuri Wiitala <miu@chromium.org> Reviewed-by: Ilya Sherman <isherman@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#554994} [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/browser_command_controller_unittest.cc [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/cocoa/browser/exclusive_access_controller_views.h [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/cocoa/browser/exclusive_access_controller_views.mm [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/exclusive_access/exclusive_access_context.h [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/exclusive_access/exclusive_access_manager.cc [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/exclusive_access/exclusive_access_manager.h [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/exclusive_access/fullscreen_controller_browsertest.cc [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/exclusive_access/fullscreen_controller_state_unittest.cc [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/exclusive_access/fullscreen_controller_test.cc [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/exclusive_access/fullscreen_controller_test.h [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/exclusive_access/keyboard_lock_controller.cc [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/exclusive_access/keyboard_lock_controller.h [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/views/apps/chrome_native_app_window_views_aura_ash.cc [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/views/apps/chrome_native_app_window_views_aura_ash.h [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/views/exclusive_access_bubble_views.cc [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/views/exclusive_access_bubble_views.h [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/views/frame/browser_view.cc [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/views/frame/browser_view.h [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/views/media_router/presentation_receiver_window_view.cc [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/chrome/browser/ui/views/media_router/presentation_receiver_window_view.h [modify] https://crrev.com/64999bc278706e59d6e0d2d55b95cdd82eca994a/tools/metrics/histograms/histograms.xml
,
May 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2a494dfdb10cdda3149864314b4d6a3b90e705ea commit 2a494dfdb10cdda3149864314b4d6a3b90e705ea Author: Joe Downing <joedow@chromium.org> Date: Tue May 01 20:11:56 2018 [KeyboardLock] Prevent FullscreenControlHost from being re-displayed This CL fixes a bug which occurs when holding ESC to dismiss the Fullscreen exit UI. The issue occurred when the FullscreenControlHost receives keyboard input as fullscreen mode is being exited. Due to the ordering of events, the press and hold timer was being set and then the BrowserView would hide and disconnect the input handler for the control. There are a couple of other ways to fix this issue based on the event ordering but I think the safest is to just cancel the timer when the control is hidden. BUG= 680809 Change-Id: I507aa751a8d29a5a39de6cf2fc338e3bff5fa564 Reviewed-on: https://chromium-review.googlesource.com/1037931 Reviewed-by: Yuwei Huang <yuweih@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#555163} [modify] https://crrev.com/2a494dfdb10cdda3149864314b4d6a3b90e705ea/chrome/browser/ui/views/fullscreen_control/fullscreen_control_host.cc
,
May 2 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3402ee5a0246b60fb567a27433df5fbb7ba78b48 commit 3402ee5a0246b60fb567a27433df5fbb7ba78b48 Author: Joe Downing <joedow@chromium.org> Date: Wed May 02 16:17:56 2018 [KeyboardLock] Ensure API is called from a top-level browsing context This change adds some checks to the keyboard lock API to ensure it was called from within a supported context, otherwise it now rejects the promise. BUG= 680809 Change-Id: I3d127422c640d16e43c22adb14755b65eb2cdc6a Reviewed-on: https://chromium-review.googlesource.com/1038888 Reviewed-by: Gary Kacmarcik <garykac@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#555417} [add] https://crrev.com/3402ee5a0246b60fb567a27433df5fbb7ba78b48/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-keyboard-lock-blocked-from-iframe.https.html [add] https://crrev.com/3402ee5a0246b60fb567a27433df5fbb7ba78b48/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/resources/iframe-lock-helper.html [modify] https://crrev.com/3402ee5a0246b60fb567a27433df5fbb7ba78b48/third_party/blink/renderer/modules/keyboard/keyboard.cc [modify] https://crrev.com/3402ee5a0246b60fb567a27433df5fbb7ba78b48/third_party/blink/renderer/modules/keyboard/keyboard.h [modify] https://crrev.com/3402ee5a0246b60fb567a27433df5fbb7ba78b48/third_party/blink/renderer/modules/keyboard/keyboard.idl [modify] https://crrev.com/3402ee5a0246b60fb567a27433df5fbb7ba78b48/third_party/blink/renderer/modules/keyboard/keyboard_lock.cc [modify] https://crrev.com/3402ee5a0246b60fb567a27433df5fbb7ba78b48/third_party/blink/renderer/modules/keyboard/keyboard_lock.h
,
May 2 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/992ef47a1588efc7ce65ce40979d66bc7aa8c38c commit 992ef47a1588efc7ce65ce40979d66bc7aa8c38c Author: Joe Downing <joedow@chromium.org> Date: Wed May 02 19:02:04 2018 [KeyboardLock] Enabling browser-level keyboard lock for Ozone This CL adds a minimal KeyboardHook impl for ozone which enables browser-level keyboard lock functionality. System-level keyboard lock will require some additional investigation / integration work and will be implemented in a future CL. BUG= 680809 Change-Id: Ib3ff830f04750667afa4b34602bd11d277fe7880 Reviewed-on: https://chromium-review.googlesource.com/1028725 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Kevin Schoedel <kpschoedel@chromium.org> Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org> Cr-Commit-Position: refs/heads/master@{#555493} [modify] https://crrev.com/992ef47a1588efc7ce65ce40979d66bc7aa8c38c/ui/aura/window_tree_host_platform.cc [modify] https://crrev.com/992ef47a1588efc7ce65ce40979d66bc7aa8c38c/ui/aura/window_tree_host_platform.h [modify] https://crrev.com/992ef47a1588efc7ce65ce40979d66bc7aa8c38c/ui/events/BUILD.gn [add] https://crrev.com/992ef47a1588efc7ce65ce40979d66bc7aa8c38c/ui/events/android/keyboard_hook_android.cc [modify] https://crrev.com/992ef47a1588efc7ce65ce40979d66bc7aa8c38c/ui/events/keyboard_hook.h [add] https://crrev.com/992ef47a1588efc7ce65ce40979d66bc7aa8c38c/ui/events/ozone/keyboard_hook_ozone.cc
,
May 3 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f18d97c04edfd09b849a08b5c56ebab0b329628d commit f18d97c04edfd09b849a08b5c56ebab0b329628d Author: Joe Downing <joedow@chromium.org> Date: Thu May 03 04:41:44 2018 [KeyboardLock] Use DomCode instead of NativeKeyCode This CL changes the data type used in platform independent code from a NativeKeyCode to a DomCode. This is a follow-up from a previous CL in which I received feedback that DomCode is the preferred mechanism for storing keyboard keys above the native API level. For this CL, I updated every interface which previously took a NativeKeyCode (or a set of them) to use DomCode. It updates some callsites which previously did a conversion to/from NativeKeyCode and simplified them to use DomCode. It also updates the KeyboardHook impl to use Domcode (platform impls will receive a NativeKeyCode from the OS which is now translated to a DomCode first before checking if it needs to be forwarded). BUG= 680809 Change-Id: I0126a8ce65e317316bd0c85e35f7d80d89c63704 Reviewed-on: https://chromium-review.googlesource.com/1037927 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: Kevin Schoedel <kpschoedel@chromium.org> Reviewed-by: ccameron <ccameron@chromium.org> Cr-Commit-Position: refs/heads/master@{#555667} [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/browser/keyboard_lock/keyboard_lock_service_impl.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/browser/renderer_host/render_widget_host_impl.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/browser/renderer_host/render_widget_host_impl.h [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/browser/renderer_host/render_widget_host_ns_view_bridge.h [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/browser/renderer_host/render_widget_host_ns_view_bridge.mm [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/browser/renderer_host/render_widget_host_view_aura.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/browser/renderer_host/render_widget_host_view_aura.h [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/browser/renderer_host/render_widget_host_view_base.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/browser/renderer_host/render_widget_host_view_base.h [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/browser/renderer_host/render_widget_host_view_cocoa.h [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/browser/renderer_host/render_widget_host_view_cocoa.mm [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/browser/renderer_host/render_widget_host_view_event_handler.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/browser/renderer_host/render_widget_host_view_event_handler.h [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/browser/renderer_host/render_widget_host_view_mac.h [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/browser/renderer_host/render_widget_host_view_mac.mm [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/content/public/browser/render_widget_host_view.h [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/headless/lib/browser/DEPS [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/headless/lib/browser/headless_window_tree_host.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/headless/lib/browser/headless_window_tree_host.h [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/aura/scoped_keyboard_hook.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/aura/scoped_keyboard_hook.h [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/aura/window.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/aura/window.h [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/aura/window_tree_host.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/aura/window_tree_host.h [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/aura/window_tree_host_platform.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/aura/window_tree_host_platform.h [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/events/android/keyboard_hook_android.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/events/keyboard_hook.h [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/events/keyboard_hook_base.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/events/keyboard_hook_base.h [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/events/mac/keyboard_hook_mac.mm [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/events/ozone/keyboard_hook_ozone.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/events/win/keyboard_hook_win.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/events/x/keyboard_hook_x11.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/views/widget/desktop_aura/desktop_window_tree_host_win.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/views/widget/desktop_aura/desktop_window_tree_host_win.h [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc [modify] https://crrev.com/f18d97c04edfd09b849a08b5c56ebab0b329628d/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h
,
May 3 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4d96f549921aee8c95064ca88a5dd16e6334aa3a commit 4d96f549921aee8c95064ca88a5dd16e6334aa3a Author: Joe Downing <joedow@chromium.org> Date: Thu May 03 21:28:29 2018 [KeyboardLock] Enable BrowserTests for all platforms Now that all desktop platforms have a browser-level implementation for keyboard lock, it is time to remove the platform restriction for the keyboard lock BrowserTests. BUG= 680809 Change-Id: Iad4ddea988069a73dd6cb31683a3a2086c753c47 Reviewed-on: https://chromium-review.googlesource.com/1042542 Reviewed-by: Scott Violet <sky@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#555880} [modify] https://crrev.com/4d96f549921aee8c95064ca88a5dd16e6334aa3a/content/browser/keyboard_lock_browsertest.cc
,
May 7 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e4543340ea4a15ead0a7583352bba743a92d9b3e commit e4543340ea4a15ead0a7583352bba743a92d9b3e Author: Joe Downing <joedow@chromium.org> Date: Mon May 07 23:54:53 2018 [KeyboardLock] X11 system-level keyboard lock impl This change includes an implementation of the KeyboardHook class for Linux/X11 which allows for intercepting system level shortcuts. It builds on a previous CL which integrated KeyboardLock functionality into RenderWidgetHostViewAura and the base X11 KeyboardHook impl. BUG= 680809 Change-Id: I7fc4b5856870eff4a10ea2f15c1cfe1c68044c76 Reviewed-on: https://chromium-review.googlesource.com/981126 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org> Reviewed-by: Thomas Anderson <thomasanderson@chromium.org> Cr-Commit-Position: refs/heads/master@{#556615} [modify] https://crrev.com/e4543340ea4a15ead0a7583352bba743a92d9b3e/ui/aura/window_tree_host_platform.cc [modify] https://crrev.com/e4543340ea4a15ead0a7583352bba743a92d9b3e/ui/events/android/keyboard_hook_android.cc [modify] https://crrev.com/e4543340ea4a15ead0a7583352bba743a92d9b3e/ui/events/keyboard_hook.h [modify] https://crrev.com/e4543340ea4a15ead0a7583352bba743a92d9b3e/ui/events/keyboard_hook_base.h [modify] https://crrev.com/e4543340ea4a15ead0a7583352bba743a92d9b3e/ui/events/mac/keyboard_hook_mac.mm [modify] https://crrev.com/e4543340ea4a15ead0a7583352bba743a92d9b3e/ui/events/ozone/keyboard_hook_ozone.cc [modify] https://crrev.com/e4543340ea4a15ead0a7583352bba743a92d9b3e/ui/events/win/keyboard_hook_win.cc [modify] https://crrev.com/e4543340ea4a15ead0a7583352bba743a92d9b3e/ui/events/x/keyboard_hook_x11.cc [modify] https://crrev.com/e4543340ea4a15ead0a7583352bba743a92d9b3e/ui/views/widget/desktop_aura/desktop_window_tree_host_win.cc [modify] https://crrev.com/e4543340ea4a15ead0a7583352bba743a92d9b3e/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
,
May 9 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c1a57efe005f2355728f06ea23175b5b322d287a commit c1a57efe005f2355728f06ea23175b5b322d287a Author: Joe Downing <joedow@chromium.org> Date: Wed May 09 18:23:54 2018 [KeyboardLock] Implementing Content BrowserTest TODOs This CL implements tests for a couple of TODOs that arose during the initial code review for my content layer changes for this feature. During implementation I found an issue where we weren't clearing KeyboardLock during navigation, that now works correctly. A big portion of this change involves codifying the behavior between iframes and the KeyboardLock feature. I haven't written many of these tests before so I'd like to make sure that the tests I have are set up correctly, testing what I think they are testing, and the behavior I have codified is reasonable. BUG= 680809 Change-Id: Ief1fbfef48d396f4df72319bb5bb61120033eada Reviewed-on: https://chromium-review.googlesource.com/1041137 Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#557249} [modify] https://crrev.com/c1a57efe005f2355728f06ea23175b5b322d287a/content/browser/BUILD.gn [add] https://crrev.com/c1a57efe005f2355728f06ea23175b5b322d287a/content/browser/keyboard_lock/keyboard_lock_metrics.h [modify] https://crrev.com/c1a57efe005f2355728f06ea23175b5b322d287a/content/browser/keyboard_lock/keyboard_lock_service_impl.cc [modify] https://crrev.com/c1a57efe005f2355728f06ea23175b5b322d287a/content/browser/keyboard_lock_browsertest.cc [modify] https://crrev.com/c1a57efe005f2355728f06ea23175b5b322d287a/content/browser/web_contents/web_contents_impl.cc
,
May 9 2018
This feature is now testable on Canary. I have some follow-up CLs for adding tests but otherwise the impl is ready for testing. Just enable this flag: chrome://flags/#keyboard-lock-api Note: You may need to enable this flag for system-shortcuts once the CL lands: chrome://flags/#system-keyboard-lock
,
May 10 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/10e91c4ab4e3342407cf9b607475d8161038ad98 commit 10e91c4ab4e3342407cf9b607475d8161038ad98 Author: Joe Downing <joedow@chromium.org> Date: Thu May 10 20:41:47 2018 [KeyboardLock] Add cross-origin iframe webkit test BUG= 680809 Change-Id: I923a3c5735f1769703e9e3c5bef6e9c2df80d91b Reviewed-on: https://chromium-review.googlesource.com/1054127 Reviewed-by: Gary Kacmarcik <garykac@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#557660} [add] https://crrev.com/10e91c4ab4e3342407cf9b607475d8161038ad98/third_party/WebKit/LayoutTests/external/wpt/keyboard-lock/navigator-keyboard-lock-blocked-from-cross-origin-iframe.https.html
,
May 14 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/386ea32692c1e8f1fa7866d90400496986e8d497 commit 386ea32692c1e8f1fa7866d90400496986e8d497 Author: Joe Downing <joedow@chromium.org> Date: Mon May 14 16:46:22 2018 [KeyboardLock] Enable keyboard-lock API by default We've received 3 LGTMs for our blink I2S so I'm enabling the API: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/isXS3f3Tqo8 I am marking the API as 'stable' for M68 and will remove the runtime flag after the next branch point. BUG= 680809 Change-Id: If805053651d5ffb3d9963bf176faf9c67dfa5e40 Reviewed-on: https://chromium-review.googlesource.com/1054329 Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Reviewed-by: Philip Jägenstedt <foolip@chromium.org> Reviewed-by: Gary Kacmarcik <garykac@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#558336} [modify] https://crrev.com/386ea32692c1e8f1fa7866d90400496986e8d497/content/browser/keyboard_lock_browsertest.cc [modify] https://crrev.com/386ea32692c1e8f1fa7866d90400496986e8d497/third_party/WebKit/LayoutTests/virtual/stable/webexposed/global-interface-listing-expected.txt [modify] https://crrev.com/386ea32692c1e8f1fa7866d90400496986e8d497/third_party/blink/renderer/modules/keyboard/keyboard.idl [modify] https://crrev.com/386ea32692c1e8f1fa7866d90400496986e8d497/third_party/blink/renderer/platform/runtime_enabled_features.json5
,
May 14 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8cbbc19fd6005d334c732b3c4028b9ab019b9d53 commit 8cbbc19fd6005d334c732b3c4028b9ab019b9d53 Author: Joe Downing <joedow@chromium.org> Date: Mon May 14 17:37:07 2018 [KeyboardLock] Adding a SystemKeyboardLock feature This feature controls whether the low-level keyboard hook is enabled when keyboard lock is requested. I wanted to separate browser and system level keyboard lock functionality as I get closer to launching the blink api for keyboard lock. This will allow us to release browser-level keyboard lock w/o the system hooks if needed and will also give us the ability to target a finch kill switch for the system-level functionality if needed. BUG= 680809 Change-Id: I2d522046c90fd8776bfb1d9c53978f2c41e1c7cc Reviewed-on: https://chromium-review.googlesource.com/1046154 Reviewed-by: Scott Violet <sky@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#558367} [modify] https://crrev.com/8cbbc19fd6005d334c732b3c4028b9ab019b9d53/chrome/browser/about_flags.cc [modify] https://crrev.com/8cbbc19fd6005d334c732b3c4028b9ab019b9d53/chrome/browser/flag_descriptions.cc [modify] https://crrev.com/8cbbc19fd6005d334c732b3c4028b9ab019b9d53/chrome/browser/flag_descriptions.h [modify] https://crrev.com/8cbbc19fd6005d334c732b3c4028b9ab019b9d53/tools/metrics/histograms/enums.xml [modify] https://crrev.com/8cbbc19fd6005d334c732b3c4028b9ab019b9d53/ui/aura/BUILD.gn [add] https://crrev.com/8cbbc19fd6005d334c732b3c4028b9ab019b9d53/ui/aura/scoped_simple_keyboard_hook.cc [add] https://crrev.com/8cbbc19fd6005d334c732b3c4028b9ab019b9d53/ui/aura/scoped_simple_keyboard_hook.h [modify] https://crrev.com/8cbbc19fd6005d334c732b3c4028b9ab019b9d53/ui/aura/window_tree_host.cc [modify] https://crrev.com/8cbbc19fd6005d334c732b3c4028b9ab019b9d53/ui/base/ui_base_features.cc [modify] https://crrev.com/8cbbc19fd6005d334c732b3c4028b9ab019b9d53/ui/base/ui_base_features.h [modify] https://crrev.com/8cbbc19fd6005d334c732b3c4028b9ab019b9d53/ui/views/widget/desktop_aura/desktop_window_tree_host_win.cc [modify] https://crrev.com/8cbbc19fd6005d334c732b3c4028b9ab019b9d53/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
,
May 14 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/58b53a10eb85bd22be215438cf5ce1398c7278fa commit 58b53a10eb85bd22be215438cf5ce1398c7278fa Author: Joe Downing <joedow@chromium.org> Date: Mon May 14 20:55:47 2018 [KeyboardLock] Fixing an F11/JS fullscreen interaction issue This CL fixes a minor interaction issue where the Fullscreen exit UI can remain visible when transitioning out of tab initiated fullscreen into browser fullscreen. The Exit UI does disappear when the user releases escape, but we should try to be more proactive and hide the UI as soon as the transition occurs. Note: This fix is for the Aura platforms, I will test on MacOS and make a separate fix there if needed. BUG= 680809 Change-Id: I0bd375005aef05cacf430d14169f28c43e52c5be Reviewed-on: https://chromium-review.googlesource.com/1057897 Reviewed-by: Yuwei Huang <yuweih@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#558453} [modify] https://crrev.com/58b53a10eb85bd22be215438cf5ce1398c7278fa/chrome/browser/ui/views/fullscreen_control/fullscreen_control_host.cc
,
May 14 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d44a078416a4bffffd4c01d902f037a06efc1449 commit d44a078416a4bffffd4c01d902f037a06efc1449 Author: Joe Downing <joedow@chromium.org> Date: Mon May 14 23:16:27 2018 [KeyboardLock] Remove press and hold UI flag Now that KeyboardLock has been implemented, we no longer need the flag used to force the press and hold esc behavior to exit fullscreen. In fact this flag has actually been causing problems as several people have enabled this flag in addition to the KeyboardLockApi flag and reported UI issues (these have all been due to the UI flag). This CL removes the un-necessary flag to prevent further confusion and problems. BUG= 680809 Change-Id: Ib2ef9d8cb28125fb19bcbd31d96823217a97f283 Reviewed-on: https://chromium-review.googlesource.com/1058044 Reviewed-by: Scott Violet <sky@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#558517} [modify] https://crrev.com/d44a078416a4bffffd4c01d902f037a06efc1449/chrome/browser/about_flags.cc [modify] https://crrev.com/d44a078416a4bffffd4c01d902f037a06efc1449/chrome/browser/flag_descriptions.cc [modify] https://crrev.com/d44a078416a4bffffd4c01d902f037a06efc1449/chrome/browser/flag_descriptions.h [modify] https://crrev.com/d44a078416a4bffffd4c01d902f037a06efc1449/chrome/browser/ui/exclusive_access/keyboard_lock_controller.cc [modify] https://crrev.com/d44a078416a4bffffd4c01d902f037a06efc1449/chrome/common/chrome_features.cc [modify] https://crrev.com/d44a078416a4bffffd4c01d902f037a06efc1449/chrome/common/chrome_features.h
,
May 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ac8b8e1198e7db4b4aec1f7182224df904c6e2c7 commit ac8b8e1198e7db4b4aec1f7182224df904c6e2c7 Author: Joe Downing <joedow@chromium.org> Date: Tue May 15 17:38:39 2018 [KeyboardLock] Enabling API and system-lock by default Enabling the feature for Canary/Dev by default. We are working through the final signoffs for the feature and want to start getting stability info and test feedback from dev/canary. BUG= 680809 Change-Id: I93bdc72aac156668ed758572066a2da29d4d684b Reviewed-on: https://chromium-review.googlesource.com/1058928 Reviewed-by: Scott Violet <sky@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#558765} [modify] https://crrev.com/ac8b8e1198e7db4b4aec1f7182224df904c6e2c7/content/public/common/content_features.cc [modify] https://crrev.com/ac8b8e1198e7db4b4aec1f7182224df904c6e2c7/ui/base/ui_base_features.cc
,
May 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bd02a98fad587d0f20f5f1e6bd7fde254ceb0232 commit bd02a98fad587d0f20f5f1e6bd7fde254ceb0232 Author: Joe Downing <joedow@chromium.org> Date: Tue May 15 19:15:58 2018 [KeyboardLock] Removing Esc key string from context menu when lock is active Per UX feedback, we should not show [esc] in the context menu when we know that press and hold is required to exit fullscreen. This change updates the context menu to query the current keyboard lock state to handle that scenario. BUG= 680809 Change-Id: Iea80d64b0c3f905521f9bf07473b6b26791fa042 Reviewed-on: https://chromium-review.googlesource.com/1055659 Reviewed-by: Allen Bauer <kylixrd@chromium.org> Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#558800} [modify] https://crrev.com/bd02a98fad587d0f20f5f1e6bd7fde254ceb0232/chrome/browser/renderer_context_menu/render_view_context_menu.cc [modify] https://crrev.com/bd02a98fad587d0f20f5f1e6bd7fde254ceb0232/chrome/browser/renderer_context_menu/render_view_context_menu.h [modify] https://crrev.com/bd02a98fad587d0f20f5f1e6bd7fde254ceb0232/chrome/browser/ui/views/renderer_context_menu/render_view_context_menu_views.cc
,
May 16 2018
FYI for those interested, this feature is now enabled by default in today's Chrome Canary build.
,
May 16 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e8567a18bd2957086a7b2a7b5357ee3c3861bbe8 commit e8567a18bd2957086a7b2a7b5357ee3c3861bbe8 Author: Joe Downing <joedow@chromium.org> Date: Wed May 16 22:28:50 2018 [KeyboardLock] Add debug console message for invalid DOMStrings This CL adds a debugging message to the console window if the caller supplies one or more invalid DOMStrings. We currently reject the promise if all strings are invalid, but if a subset are invalid, there was no good way to debug that issue before this change. Now it is obvious which DOMString is not a valid DomCode. It also helps prevent silent failures if a single invalid key was passed in. BUG= 680809 Change-Id: If978952e53e35e128528aad28ff1e0bdc969ba14 Reviewed-on: https://chromium-review.googlesource.com/1062367 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#559314} [modify] https://crrev.com/e8567a18bd2957086a7b2a7b5357ee3c3861bbe8/content/browser/keyboard_lock/keyboard_lock_service_impl.cc
,
May 22 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bddd12fc016134ca138d42a1547365d4ac076fb2 commit bddd12fc016134ca138d42a1547365d4ac076fb2 Author: Joe Downing <joedow@chromium.org> Date: Tue May 22 19:22:16 2018 [KeyboardLock] KLSI should return an error if lock request fails Previously the KeyboardLockServiceImpl would silently fail if the keyboard lock request failed in some cases (we returned an error for some scenarios but not all). This change will ensure that if the keyboard.lock() promise succeeds, the request was registered successfully. BUG= 680809 Change-Id: I65228603592a871173e6df4a1c265b14fc6a6d8f Reviewed-on: https://chromium-review.googlesource.com/1066699 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Gary Kacmarcik <garykac@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Cr-Commit-Position: refs/heads/master@{#560726} [modify] https://crrev.com/bddd12fc016134ca138d42a1547365d4ac076fb2/content/browser/keyboard_lock/keyboard_lock_service_impl.cc [modify] https://crrev.com/bddd12fc016134ca138d42a1547365d4ac076fb2/content/browser/keyboard_lock_browsertest.cc [modify] https://crrev.com/bddd12fc016134ca138d42a1547365d4ac076fb2/content/browser/renderer_host/render_widget_host_impl.cc [modify] https://crrev.com/bddd12fc016134ca138d42a1547365d4ac076fb2/content/browser/renderer_host/render_widget_host_impl.h [modify] https://crrev.com/bddd12fc016134ca138d42a1547365d4ac076fb2/third_party/blink/public/platform/modules/keyboard_lock/keyboard_lock.mojom [modify] https://crrev.com/bddd12fc016134ca138d42a1547365d4ac076fb2/third_party/blink/renderer/modules/keyboard/keyboard_lock.cc
,
May 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b965593188cecf524366545158347e17285f8f9a commit b965593188cecf524366545158347e17285f8f9a Author: Joe Downing <joedow@chromium.org> Date: Thu May 24 00:39:45 2018 [KeyboardLock] Adding feature check to FullscreenControlHost There is a chance that the FullscreenControlHost work will not be ready for M68 so I am adding a feature check for the keyboard lock api feature flag to enable this control. Note that the control will not appear for mouse / touch users, only in the keyboard lock scenario where the escape key has been locked. BUG= 680809 Change-Id: I4eb1fa4608f59d89d418200d1b0b88bc334be8c1 Reviewed-on: https://chromium-review.googlesource.com/1070877 Reviewed-by: Yuwei Huang <yuweih@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#561339} [modify] https://crrev.com/b965593188cecf524366545158347e17285f8f9a/chrome/browser/ui/views/fullscreen_control/fullscreen_control_host.cc
,
May 30 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a7235f97495cea57f36fbb750ae3e07fcd90b657 commit a7235f97495cea57f36fbb750ae3e07fcd90b657 Author: Joe Downing <joedow@chromium.org> Date: Wed May 30 22:40:52 2018 [KeyboardLock] Adding Chrome UX Browsertests These tests are similar to the tests in the content layer, however these test exercise Chrome E2E instead of using stubs. BUG= 680809 Change-Id: I371d1cdec025517634e62b7ee4cde674c480307c Reviewed-on: https://chromium-review.googlesource.com/1068122 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#563038} [modify] https://crrev.com/a7235f97495cea57f36fbb750ae3e07fcd90b657/chrome/browser/ui/browser_command_controller_interactive_browsertest.cc [modify] https://crrev.com/a7235f97495cea57f36fbb750ae3e07fcd90b657/chrome/browser/ui/fullscreen_keyboard_browsertest_base.cc [modify] https://crrev.com/a7235f97495cea57f36fbb750ae3e07fcd90b657/chrome/browser/ui/fullscreen_keyboard_browsertest_base.h [add] https://crrev.com/a7235f97495cea57f36fbb750ae3e07fcd90b657/chrome/browser/ui/keyboard_lock_interactive_browsertest.cc [modify] https://crrev.com/a7235f97495cea57f36fbb750ae3e07fcd90b657/chrome/test/BUILD.gn [modify] https://crrev.com/a7235f97495cea57f36fbb750ae3e07fcd90b657/chrome/test/data/fullscreen_keyboardlock/fullscreen_keyboardlock.html [modify] https://crrev.com/a7235f97495cea57f36fbb750ae3e07fcd90b657/content/browser/keyboard_lock_browsertest.cc [modify] https://crrev.com/a7235f97495cea57f36fbb750ae3e07fcd90b657/content/public/test/browser_test_utils.cc [modify] https://crrev.com/a7235f97495cea57f36fbb750ae3e07fcd90b657/content/public/test/browser_test_utils.h
,
May 31 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/860703f7335079210125c9cf0f8dbac1bac3af0f commit 860703f7335079210125c9cf0f8dbac1bac3af0f Author: Joe Downing <joedow@chromium.org> Date: Thu May 31 01:08:21 2018 [KeyboardLock] Removing KeyboardLock blink feature Now that we've branched to M69 and the KeyboardLock feature is enabled by default, we can remove the blink API feature flag. Note: I want to keep the Chrome feature flags around a bit longer, but will be removing them at some point in the future. BUG= 680809 Change-Id: I6dcb76a0a8e7874fd20627f9126ff48a9a0625a6 Reviewed-on: https://chromium-review.googlesource.com/1073674 Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: Philip Jägenstedt <foolip@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#563099} [modify] https://crrev.com/860703f7335079210125c9cf0f8dbac1bac3af0f/content/child/runtime_features.cc [modify] https://crrev.com/860703f7335079210125c9cf0f8dbac1bac3af0f/third_party/blink/renderer/modules/keyboard/keyboard.idl [modify] https://crrev.com/860703f7335079210125c9cf0f8dbac1bac3af0f/third_party/blink/renderer/modules/keyboard/navigator_keyboard.idl [modify] https://crrev.com/860703f7335079210125c9cf0f8dbac1bac3af0f/third_party/blink/renderer/platform/runtime_enabled_features.json5
,
Jun 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8992682411d37e9610da2988b5075841e4bf91e6 commit 8992682411d37e9610da2988b5075841e4bf91e6 Author: Joe Downing <joedow@chromium.org> Date: Fri Jun 01 05:52:24 2018 [KeyboardLock] Remove test bool from KeyboardLockController Now that keyboard lock is supported on all desktop platforms, I can remove the test boolean and drive the test using classes in the content layer. BUG= 680809 Change-Id: I82075ca292ebdaee4cc63d8c210447c8505305a2 Reviewed-on: https://chromium-review.googlesource.com/1073891 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Yuri Wiitala <miu@chromium.org> Reviewed-by: Robert Liao <robliao@chromium.org> Reviewed-by: Yuwei Huang <yuweih@chromium.org> Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Cr-Commit-Position: refs/heads/master@{#563544} [modify] https://crrev.com/8992682411d37e9610da2988b5075841e4bf91e6/chrome/browser/ui/exclusive_access/fullscreen_controller_browsertest.cc [modify] https://crrev.com/8992682411d37e9610da2988b5075841e4bf91e6/chrome/browser/ui/exclusive_access/fullscreen_controller_test.cc [modify] https://crrev.com/8992682411d37e9610da2988b5075841e4bf91e6/chrome/browser/ui/exclusive_access/fullscreen_controller_test.h [modify] https://crrev.com/8992682411d37e9610da2988b5075841e4bf91e6/chrome/browser/ui/exclusive_access/keyboard_lock_controller.cc [modify] https://crrev.com/8992682411d37e9610da2988b5075841e4bf91e6/chrome/browser/ui/exclusive_access/keyboard_lock_controller.h [modify] https://crrev.com/8992682411d37e9610da2988b5075841e4bf91e6/chrome/browser/ui/views/fullscreen_control/fullscreen_control_view_interactive_uitest.cc [modify] https://crrev.com/8992682411d37e9610da2988b5075841e4bf91e6/content/public/test/browser_test_utils.cc [modify] https://crrev.com/8992682411d37e9610da2988b5075841e4bf91e6/content/public/test/browser_test_utils.h
,
Jun 1 2018
,
Jun 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7e79d96078ef0e5e06246b842424f120dcf83b7b commit 7e79d96078ef0e5e06246b842424f120dcf83b7b Author: Joe Downing <joedow@chromium.org> Date: Fri Jun 15 21:34:27 2018 [KeyboardLock] Updating behavior for invalid key_codes param Per discussion with API owner, we want the behavior for invalid params to be a bit stricter. Prior to this change, if someone called the API with at least one valid DomString, then we would allow lock to be set. This made sense when we were translating the key_codes param into native key codes (where we couldn't determine the difference between 'invalid for this platform' and 'invalid key for all platforms'. Now that we use DomCodes, we can do better validation. The second change is to cancel any current keyboard lock requests if the API is called with invalid params. The scenario here involves lock() being called correctly (request is registered) and then a second lock call being made w/ invalid params. Since we reject the promise in this case, it didn't make sense to keep the lock request since the intention by the caller was to override the initial call. In practice, we don't think this will occur often but it is a case we wanted to handle better. BUG= 680809 Change-Id: I0ca54cca262761133739ab1d43f22e219792ca7c Reviewed-on: https://chromium-review.googlesource.com/1099762 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Gary Kacmarcik <garykac@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#567800} [modify] https://crrev.com/7e79d96078ef0e5e06246b842424f120dcf83b7b/content/browser/keyboard_lock/keyboard_lock_service_impl.cc [modify] https://crrev.com/7e79d96078ef0e5e06246b842424f120dcf83b7b/content/browser/keyboard_lock_browsertest.cc
,
Jun 22 2018
MacOS System Keyboard Lock functionality has been split out of this bug and is now being tracked via crbug.com/855738. I'd like to track the core feature work for the KeyboardLock API via this bug and track the work needed for the MacOS System Hook separately.
,
Jul 27
Feature has been released and is available in M68 stable. W00t!
,
Nov 5
Hi, I am developing a web-app www.Photopea.com and many users are complaining about not being able to do some stuff, they were used to do in their previous native programs. I think we should make a single Permission, which will be asked from the user only once, and will unlock a whole set of possibilities to a webapp. We could call it a "Native Permission". There are three things that native apps can do, and I need to do them Photopea (and all my users want Photopea to do them): - prevent the native behaviour of any keyboard shortcut (Ctrl+T, Ctrl+W, ...) - read the Clipboard content / initiate Pasting without the explicit pasting (to make a custom Paste button) - preserve a link to a file, opened from a local filesystem, and rewrite that file without a Save As dialog (to implement File - Save). These rights could be placed under one "Native" permission. We could even put the Fullscreen API, Mouse Lock API or access to a mic and a camera under this (to not bother users with multiple requests for permissions).
,
Nov 6
I think the keyboard shortcut aspect that's relevant to this bug is already "unlocked" after selecting "Install Photopea" from the three-dot menu, using the stuff provided by https://developers.google.com/web/progressive-web-apps/desktop . Maybe that can unlock other stuff too - perhaps file a feature request.
,
Nov 6
Many users want to use these features (like shortcuts and saving to a filesystem) without adding such "bookmark" to their OS. Or they use everything in a browser because of their own principle. I am a fan of "one web", which works the same way everywhere. Creating an "installed app" as a new platform next to the web, is not a good thing in my oppinion :/
,
Nov 6
Precisely, I do like the idea to let the webapp to be started by an icon, without the browser UI. But I want it to behave in the same way. I would feel bad for telling my users "Please, install Photopea to unlock new features".
,
Nov 6
As tapted@ mentioned, please file a new bug for your request. It is related to keyboard lock in that the permission might include keyboard lock, but the request represents brand new work and is something that is more nuanced that it might seem. A separate bug should be used to document those discussions and track history / context. This bug tracked the implementation of the KeyboardLock API in Chrome and is closed (since the work has been completed) so it isn't the right place to discuss new features. |
|||||||||||||||
►
Sign in to add a comment |
|||||||||||||||
Comment 1 by zijiehe@chromium.org
, Jan 13 2017