Issue metadata
Sign in to add a comment
|
MacOS System-wide Text Selection Shortcuts Broken in Webpage Textboxes/areas/etc.
Reported by
bgros...@gmail.com,
Aug 14
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 Steps to reproduce the problem: 1. On a Mac, go to Google.com 2. In the search input, type "test test" 3. Press OPTION-SHIFT-LEFT What is the expected behavior? Each press of OPTION-SHIFT-LEFT should select the previous word. So on press selects the last 'test', while another press selects the first 'test'. What went wrong? Nothing happens. Did this work before? Yes This is still working on an older machine running the same version of Chrome and same version of MacOS. Chrome version: 68.0.3440.106 Channel: stable OS Version: OS X 10.13.6 Flash Version: Strangely, SHIFT-OPTION-LEFT (or RIGHT) still works as expected in the location bar. But it doesn't work in input fields on webpages themselves. Still works in other browsers (Firefox, Safari), so appears to be a regression. Note that this keyboard shortcut is a standard one for MacOS (https://support.apple.com/en-us/HT201236).
,
Aug 15
Hi, thanks for the report! I can't reproduce this (same version of macOS and Chrome). Does this still reproduce in a clean profile/Incognito? Is this every text field, or just specific ones?
,
Aug 15
I tried it on a Guest profile and in an Incognito window with the same result. It seems to be every text field within the webpage (I made a test page using input types of text, textarea, email, search). I should have noted that other MacOS text selection shortcuts work as expected, including SHIFT-LEFT to select a character at a time, and SHIFT-CMD-LEFT to select from the cursor to the beginning of the line. In case it matters, this is also on a brand new Apple MBP with latest OS and all updates and a brand new user account (e.g. not a transfer but starting fresh). Happy to provide more info as needed.
,
Aug 15
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 16
Unable to reproduce the issue on reported chrome version #68.0.3440.106 and on latest chrome version #70.0.3522.0 using Mac OS 10.13.6, by following below steps. Steps: ===== 1.Launched chrome. 2.Navigated to google.com. 3.Entered 'test test' in the the search box. 4.By using the keyboard shortcut 'option+shift+left', observed that the second test gets selected first later first test gets selected. Note: Tried with incognito mode and by creating a new profile, but unable to reproduce the issue. Attached screencast fo reference. @Reporter: Could you please review the attached screen-cast and confirm if anything being missed here and request you to retry this issue with fresh profile without any extensions/apps or reset all the flags and let us know if issue still persists. Thanks.!
,
Aug 16
Could you post the contents of "Variations" from chrome://version? Maybe there's an experiment enabled for you that's keeping us from reproducing. If you have the opportunity/time could you also check if this is fixed for you in the latest Canary? https://www.google.com/chrome/canary/
,
Aug 16
I can't see your keystrokes, but I don't think you're missing anything. I have tried with new profiles on Chrome 68.0.3440.106 and on Canary 70.0.3524.0. I reset all flags to defaults using chrome://flags. I turned off the extensions installed/enabled by default (Google Docs). Same behavior. Happy to record a screencast of it if useful. Here is the output of Variations for Chrome and Canary--> Chrome Variations (from chrome://version): c134752e-1ece3553 59aeb88e-3f4a17df 1a0d11d4-ca7d8d80 ebeb14fc-3f4a17df 34a6bf44-ca7d8d80 752a9400-3d47f4f4 bacf97b2-ca7d8d80 241fff6c-1623a499 3095aa95-3f4a17df 7c1bc906-f55a7974 47e5d3db-3d47f4f4 125b7f68-26e7b859 1149accc-3f4a17df 4dc30737-b8a5ea08 a582a1b8-ad75ce17 3042ad4b-ca7d8d80 ebbb4e0a-ca7d8d80 44827ee5-3f4a17df 9eab0f00-3f4a17df d0ecf1da-52a3491f 8f1e27f-ca7d8d80 9773d3bd-f23d1dea 43f62d3b-28165b59 9e5c75f1-b6621078 f79cb77b-3d47f4f4 e5218ffe-ca7d8d80 4ea303a6-ecbb250e bcc34a89-3f4a17df 2c1d398c-ca7d8d80 6973a1cf-3f4a17df 58a025e3-36e97b2c 2a32876a-ca7d8d80 ff29b1bd-37ef7e17 da460ac8-3f4a17df 4bc337ce-b2a7d6c5 9a2f4e5b-3fe32955 1354da85-ca7d8d80 17507c76-ca7d8d80 494d8760-52325d43 f47ae82a-746c2ad4 3ac60855-486e2a9c f296190c-dda7873d 4442aae2-a90023b1 ed1d377-e1cc0f14 12e17bc5-e1cc0f14 75f0f0a0-a5822863 e2b18481-7158671e e7e71889-e1cc0f14 b1ceb06f-d1372334 3a4029d-ca7d8d80 94e68624-803f8fc4 8834fcca-ca7d8d80 Canary Variations: c134752e-95b424ac 2c707b42-5940ee21 411b6d4e-f23d1dea fe69e053-f23d1dea 9d7f502c-d5d68bac d01ab0d3-ca7d8d80 3e006338-3f4a17df 1a0d11d4-f23d1dea 16e0dd70-3f4a17df ebeb14fc-3f4a17df b7e2524c-f23d1dea 3cd9377c-aed099c4 da89714-4ad60575 64da5c1e-f23d1dea 8982496f-ca7d8d80 b1681d28-1410f10 61832c80-f23d1dea cc20827f-ca7d8d80 9041608a-3f4a17df 5852bcb0-f23d1dea 241fff6c-444559b8 afb5d7b8-f23d1dea 9853922b-c200976c 6025934e-3f4a17df 7c1bc906-86bf56d9 47e5d3db-3d47f4f4 125b7f68-26e7b859 d442dfb7-41afa35c 9ca1387e-f23d1dea 1149accc-3f4a17df 34d450b1-e9aea2ba a582a1b8-ad75ce17 495970ba-6fc99f5e 3042ad4b-f23d1dea 249dd49a-f23d1dea ac6e1b9-d93a0620 44827ee5-f23d1dea d0ecf1da-9ebb8c3a edbcf7c5-2d3ce014 5485fc4d-3f4a17df 9773d3bd-ca7d8d80 93731dca-585ca4c0 41f007f9-41f007f9 9b4c4257-6ad6e56e 43f62d3b-f23d1dea c992f345-4ad60575 9e5c75f1-cf6200b9 6fa07eb4-ca7d8d80 f2fd8aaf-f23d1dea f79cb77b-3d47f4f4 7a5ba892-f23d1dea d1cd70a5-36012f6a 4ea303a6-e2ca4846 6e6e0c7e-bfd1fe3 95876445-ca7d8d80 d92562a9-6014a724 74c3667-6ab49ebf dc5b1f29-f23d1dea 2c1d398c-3f4a17df cc54eb06-f23d1dea 58a025e3-36e97b2c ad6d27cc-7075cd8 df072bba-ca7d8d80 ff29b1bd-f21dcc16 5a42b5d9-3f4a17df 344833e9-1525b35b 4bc337ce-4077d4f3 9a2f4e5b-556b4118 494d8760-52325d43 3ac60855-486e2a9c f296190c-fd6d2f5a 4442aae2-d7f6b13c ed1d377-e1cc0f14 12e17bc5-e1cc0f14 75f0f0a0-d7f6b13c e2b18481-75cb33fc e7e71889-e1cc0f14 f9e5da91-f23d1dea 5e60f31d-803f8fc4 6e3b857e-1410f10 6a51bb09-ca7d8d80 308674c4-ca7d8d80 94e68624-f23d1dea cc73f8a1-a2d707c6 de384ee6-7652bd75 b4e8892d-3f4a17df 8834fcca-cf4f6ead Just out of curiosity, does any of you have a 2018 Macbook Pro to test on? That's the only thing unusual about this machine for me (though this is the only issue I've noticed with any app).
,
Aug 16
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 16
Just in case, I compared key codes between this machine and an older Macbook Pro, and with an external Apple keyboard, and they all match. I also verified that the external keyboard works the same (in this regard) as the built-in keyboard.
,
Aug 17
After a ton of testing/experimentation, I seem to have isolated a set of conditions that can reproduce this bug (and relieve it)---at least for me. My first clue came when I created a new MacOS user and loaded Chrome, only to find that OPTION-SHIFT-LEFT worked as expected. I then went about trying to adjust system settings a bit at a time (as I would on any new account) until I broke it. Once I found a setting that triggered the problem, I realized that all along OPTION-SHIFT-LEFT was working on any new load of Chrome, but only for about 5-10 seconds. Then, it would quit working for good. Quit/Reload would give me another 5-10 seconds. The offending MacOS setting, somehow, is the way I (re)set two default system shortcuts for MacOS Mission Control. For many years I have always set the 'Move left/right a space' shortcuts to OPT-LEFT and OPT-RIGHT (instead of the default CTRL-LEFT and CTRL-RIGHT). Yet for some reason, on this machine, setting to OPT-LEFT/RIGHT sets up conditions that break OPT-SHIFT-LEFT/RIGHT text selection *only* in Chrome webpage inputs (but not anywhere else in the system, or in any other browser or even in the Chrome location bar input). Here are the steps I have now verified several times that will make the bug start and stop: 1. Create new user with Users & Groups system preference pane (I used administrative rights) 2. Login as the new user (no need to logout current user) 3. Open Chrome 4. Don’t sign in 5. Go to google.com 6. Type ‘test test’ in the search box (or, really, in any webpage text input anywhere) 7. Test OPTION-SHIFT-LEFT to highlight the words in the search box one at a time 8. Do it over and over for at least 10-15 seconds to verify it works that long 9. Go to the Keyboard system preference pane and select Shortcuts tab 10. Select Mission Control in left tab 11. Click the default shortcut for ‘Move left a space’ (^<— aka CTRL-LEFT) 12. Reset the shortcut to OPTION-LEFT by pressing those keys 13. Reset the shortcut for ‘Move right a space’ to OPTION-RIGHT 14. Go to Chrome, test OPTION-SHIFT-LEFT for 10-15 seconds to verify it still works (it should) 15. Quit Chrome 16. Open Chrome 17. Go to google.com 18. Type ‘test test’ in the search box 19. Repeatedly and quickly test OPTION-SHIFT-LEFT (e.g. opt-shift-left, then lift up, then press right arrow to move cursor back to end, and repeat). It will work for about 5-10 seconds and then stop working. Closing/reopening Chrome will allow you to get another 5-10 seconds or so before it stops. 20. Go back to Keyboard preferences Shortcut tab, and select ‘Restore Defaults’ to set the shortcuts back to defaults. 21. Quit Chrome, open Chrome 22. Go back to google.com, type ‘test test’ and once again test OPTION-SHIFT-LEFT. It will work indefinitely again. I have tested this formula over and over now, and am finding it repeatable. If it would be helpful for me to screen record a demo, I'd be happy to.
,
Aug 17
bgrosser@: Many thanks for the detailed steps to reproduce the issue. I can confirm that I am able to reproduce it with your described steps. This is really strange. I am wondering why it is only breaking the shortcut when you focus a textfield of the web content and not when you focus the Omnibox? Not sure, but may be this is a blink issue? (+erikchen@, maybe you have an idea what is going on here - thanks :) )
,
Aug 17
Unable to reproduce the issue after following all steps mentioned in comment#10 ,on chrome version #68.0.3440.106 using Mac OS 10.13.6. Attached screencast for reference. @reporter:Could you please review the screencast and let us know if anything is being missed here so that it would be really helpful for further triaging.If possible please provide screencat for better undestanding of issue. Thanks.!
,
Aug 17
This is likely caused by: https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_view_cocoa.mm?type=cs&q=renderwidgethostviewcocoa&sq=package:chromium&g=0&l=631 We have some kind-of-janky code to detect if a key is reserved by the system. If so, we don't send it to the renderer. I've wanted to do something more clever/robust but that would take a more thorough investigation and time. Given that the current code seems to work well enough for most users [with default system hotkeys], I'm going to mark this as Available, Pri-3.
,
Aug 17
Thanks for your feedback and the clarification.
,
Aug 17
swarnasree.mukkala asked for a screencast, so here is one where I demonstrate and discuss the bug. Thanks everyone!
,
Aug 17
BTW, I just realized that there is a kind of workaround that may also help illuminate the problem. As long as my MacOS Mission Control keyboard shortcuts are at the default when I first open Chrome, then the SHIFT-OPTION-LEFT text selection will work indefinitely, even when I change my 'move to next space' shortcuts to OPTION-LEFT/RIGHT. In other words, Chrome windows and tabs --- even *new* windows and tabs --- will not have this bug until Chrome is quit and started anew when the custom shortcuts are in place. So it seems that somehow, whatever is causing the bug in Chrome, it must be dependent on what the system shortcuts are set to when Chrome is opened (?) |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by swarnasree.mukkala@chromium.org
, Aug 15