Issue metadata
Sign in to add a comment
|
Cut, copy, paste disabled in context menu in Ace editor
Reported by
amjad.ma...@gmail.com,
Jan 28 2017
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Steps to reproduce the problem: 1. Open the following which includes the latest version of Ace https://ace.c9.io/build/kitchen-sink.html 2. Select some text in the editor 3. Right click What is the expected behavior? To see cut, copy, and paste enabled in the context menu What went wrong? context menu opens but with cut, copy, and paste disabled. Did this work before? Yes 54 Chrome version: 55.0.2883.95 Channel: stable OS Version: OS X 10.11.6 Flash Version: Shockwave Flash 24.0 r0 Works in Firefox and Safari
,
Jan 28 2017
Bisect: 413691 (good) - 413695 (bad), 54.0.2838.0 https://chromium.googlesource.com/chromium/src/+log/e5958aeb..53001533?pretty=fuller Suspecting r413695 ( issue 637860 ) "Selection API of INPUT/TEXTAREA should not update FrameSelection without focusing"
,
Jan 28 2017
Thanks for the bisect.
,
Jan 30 2017
It seems the root issue is that Chrome requires to focus on INPUT/TEXTAREA to show correct context menu after r413695, and usually right-mousedown focuses on the element, but Ace editor seems to prevent to focus. I'm not sure how to fix this yet.
,
Jan 30 2017
I've made a jsbin demonstrating the issue, without ace. Focusing and bringing textarea under the cursor on mousedown trigger correct contextmenu for textareas with visible text, but doesn't work with empty textarea or one containing invisible space https://jsbin.com/fejuwewibo/edit?html,output.
,
Jan 31 2017
> but doesn't work with empty textarea or one containing invisible space Though the difference between visible text and invisible text is a bug of Chrome, we can avoid it by e.preventDefault() in mousedown event handler. The event remove focus from the textarea.
,
Jan 31 2017
Thanks, we can use preventDefault until the issue is fixed. We were not using it before, because calling preventDefault breaks menu item hover on firefox.
,
Apr 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/adc8910776c64a876f0422454da618a37d01167b commit adc8910776c64a876f0422454da618a37d01167b Author: tkent <tkent@chromium.org> Date: Mon Apr 10 04:46:38 2017 Factor out code to set up editing-related context menu items to a static function. Introduces ContextMenuClientImpl::ComputeEditFlags() to set WebContextMenuData::edit_flags up. This CL will make unit-testing easier. This CL has no behavior changes. BUG=686339 Review-Url: https://codereview.chromium.org/2813463002 Cr-Commit-Position: refs/heads/master@{#463171} [modify] https://crrev.com/adc8910776c64a876f0422454da618a37d01167b/third_party/WebKit/Source/web/ContextMenuClientImpl.cpp [modify] https://crrev.com/adc8910776c64a876f0422454da618a37d01167b/third_party/WebKit/Source/web/ContextMenuClientImpl.h
,
Jun 7 2017
Blink Editing team discussed this. The current policy is that context menu actions and keyboard shortcuts should be equivalent. * When Ctrl-C is pressed, selected text in the focused element is copied if the focused element exists. Otherwise selected text in the body is copied. * "Copy" menu action should work in the same way. The current behavior is correct according to this policy. However, showing editing menu items in context menu for unfocused editable element is confusing. We should disable such menu items.
,
Oct 4 2017
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by amjad.ma...@gmail.com
, Jan 28 2017