Issue metadata
Sign in to add a comment
|
Move-and-select to the end/begining of line does not work
Reported by
ariel.ha...@gmail.com,
Sep 12 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36 Steps to reproduce the problem: 1. Go to: https://jsfiddle.net/v1gz5c5m/1/ 2. Click on the input box in the bottom-right quadrant 3. With a Mac computer, type the combination: CMD (Apple key) + SHIFT + Arrow-Left (or Arrow-Right) 4. See that the arrow event is not emitted. What is the expected behavior? The arrow event in the previous combination should be emitted. This shortcut normally allows to move to the beginning or end of a line while selecting from the current position of the cursor; there is _*NO OTHER WAY*_ to move to the beginning or end of a line with OSX, without using the mouse, so I consider this a serious issue. This combination _*works fine with other browsers*_ (eg Firefox or Safari), so I am reasonably confident that this has to do with Chromium internally. What went wrong? The events related to pressing the right/left arrow key is not emitted when prefixed with CMD + SHIFT. It seems to be filtered by Chromium before it gets to the page, but supposedly not before Chromium (eg by the OS), because this behaves as expected with other browsers (eg Firefox or Safari). It also seems to be unrelated to permission issues, eg due to extended attributes, because I made sure Google Chrome was not in quarantine. In fact, Firefox was in quarantine when I tested it, but still behaved as expected. Did this work before? Yes I cannot remember Chrome version: 61.0.3163.79 Channel: stable OS Version: OS X 10.12.6 Flash Version: This issue was uncovered originally from a bug in Visual Studio Code (code editor), see https://github.com/Microsoft/vscode/issues/33610 for details. A link to this Chromium issue will be referenced on GitHub.
,
Sep 13 2017
Tested in chrome #61.0.3163.79 and Canary #63.0.3213.3 on Mac 10.12.6 and not able to reproduce the issue.Please find the screen shots for your reference and same behaviour observed in other browser(Fire fox) @ariel.hadida: Could you please let me know if i have missed anything and if possible,Please create new profile without extensions and apps.Re-check once and let us know the observations of the issue which would help us to triage the issue further. Thanks in Advance.
,
Sep 13 2017
I am a bit baffled; the versions seem to match mine exactly. Can I ask whether you ran this from a virtual machine? I am not sure how events are managed then, but could this make a difference? Otherwise, I don't think you missed anything, but I can still reproduce this bug on my machine, even in incognito mode (without extensions) or as a guest user. That being said, I just tried on an older MBP with a colleague, and I cannot reproduce this! Could this have to do with the hardware, even though other programs can detect this event?? [FYI, my machine is an MBP 15 inch 2017] Also, it turns out I was wrong in my original post; there is another shortcut to move to the end/beginning of line: CTRL + A/E This also works in combination with SHIFT for selection, apologies for my earlier claim. Unless you have the same hardware handy, I will try to find other colleagues with the same laptop to reproduce this before bothering you again. I would be surprised if it was a hardware issue, given that other programs can see it, but I don't know enough about events to rule this out...
,
Sep 13 2017
Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 14 2017
Unable to reproduce this issue on Mac 10.13 MBP retina(High Sierra) 15.4 inch display with chrome Stable #61.0.3163.79, Dev #63.0.3213.3, Canary #63.0.3214.0 Observed arrow event is firing as expected. Note: 1. Tested machine is physical machine not virtual. 2. Since TE was unable to reproduce the issue, removing Bisect label for now, will add once we have consistent repro steps. Thank You...
,
Sep 16 2017
[mac bug triage]
,
Sep 17 2017
,
Sep 21 2017
@kkaluri Unable to reproduce on a 13 inch MBP 10.12.6 either. I really don't understand what could be causing this, given that other programs seem to have no issue detecting this event.
,
Sep 21 2017
After more testing, it gets even weirder. Closing Chrome completely (ie using CMD+Q), and restarting it, the event seems to be detected for a few seconds (~10), and then stops working. Exact same behaviour with VSCode, but not with Atom (the event works fine with Atom).
,
Sep 21 2017
Maybe the version differences between VSCode and Atom can help? Although that does not explain why this cannot be reproduced on different laptops... Atom versions: ares:"1.10.1-DEV" atom-shell:"1.6.9" chrome:"56.0.2924.87" electron:"1.6.9" http_parser:"2.7.0" modules:"53" node:"7.4.0" openssl:"1.0.2j" uv:"1.10.1" v8:"5.6.326.50" zlib:"1.2.8" VSCode versions: ares:"1.10.1-DEV" atom-shell:"1.7.3" chrome:"58.0.3029.110" electron:"1.7.3" http_parser:"2.7.0" microsoft-build:"1.7.3" modules:"54" node:"7.9.0" openssl:"1.0.2k" uv:"1.11.0" v8:"5.8.283.38" zlib:"1.2.11"
,
Sep 21 2017
Really sorry for the spam, but you can close this issue. I created another user and there doesn't seem to be a problem in that new session, so it must have something to do with my own session --- probably a program running in the background. Sincere apologies for the disturbance!
,
Sep 22 2017
Mark it as WontFix as per comment #11 provided by reporter.Feel free to raise a new issue if still facing. Thank You! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ligim...@chromium.org
, Sep 12 2017