Closed Bug 1864334 Opened 1 year ago Closed 1 year ago

Right click in compose clears selection - Write composing area highlight text right click 'Undo', 'Cut', 'Copy' and 'Delete' is disabled

Categories

(Core :: DOM: Editor, defect, P1)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
121 Branch
Tracking Flags:
Tracking Status
thunderbird_esr115 --- unaffected
firefox-esr115 --- unaffected
firefox119 --- unaffected
firefox120 --- fixed
firefox121 + fixed

People

(Reporter: anjeyelf, Assigned: masayuki)

References

(Regression,
URL
)

Details

(Keywords: regression)

Attachments

(1 file)

Bug 1864334 - Make `nsIFrame::MovingCaretToEventPointAllowedIfSecondaryButtonEvent` check whether the right click point is in a selection range first r=emilio!,#dom-core
48 bytes, text/x-phabricator-request
Details | Review

Windows 10 OS
beta 120.0b5

  • Click on 'Write' or 'Reply'
  • 'Write' message window opens.
  • Enter anything in the composing area.
  • Highlight text - single word, sentence or use Ctrl +A
  • Right click on highlighted text

Actual Results
Text immediately becomes not highlighted
Upon Right click menu has 'Undo', 'Cut', 'Copy' and 'Delete' as disabled

Expected REsults
Highlighted text to remain highlighted
Upon right click all menu items to be enabled.

Additional:
tested in 'Troubleshoot Mode' and get same results.
tested in 'Offline' and 'Online' modes and get same result.

Bug is Right click on highlighted text removes the highlight,
so it will not offer 'Undo', 'Cut', 'Copy' and 'Delete' as options.

Confirmed on trunk.

status-thunderbird_esr115: --- → unaffected
Flags: needinfo?(alice0775)
Keywords: regression, regressionwindow-wanted
Summary: Write composing area highlight text right click 'Undo', 'Cut', 'Copy' and 'Delete' is disabled → Right click in compose clears selection - Write composing area highlight text right click 'Undo', 'Cut', 'Copy' and 'Delete' is disabled

Thank you Alice!
Masayuki, please advice.

Flags: needinfo?(masayuki)

Indeed, I reproduce it in Thunderbird too. Fortunately, I reproduce this bug within Firefox if I load data:text/html,<iframe srcdoc="abc" onload="event.target.contentDocument.designMode='on'"></iframe>.

Assignee: nobody → masayuki
URL: data:text/html,<iframe srcdoc="abc" o...
Severity: -- → S2
Status: NEW → ASSIGNED
status-thunderbird119: unaffected → ---
status-thunderbird120: affected → ---
status-thunderbird121: affected → ---
tracking-thunderbird120: ? → ---
Component: Message Compose Window → DOM: Editor
Flags: needinfo?(masayuki)
OS: Unspecified → All
Priority: -- → P1
Product: Thunderbird → Core
Hardware: Unspecified → All
Version: Thunderbird 120 → unspecified

Set release status flags based on info from the regressing bug 1845241

status-firefox119: --- → unaffected
status-firefox120: --- → affected
status-firefox121: --- → affected
status-firefox-esr115: --- → unaffected

[Tracking Requested - why for this release]:

This is a serious regression for web apps which use designMode (I'm not sure how may apps using the legacy editor mode) or making <html> content-editable. Perhaps, backing-out bug 1845241 from the release candidate is the most reasonable fix for this in this stage.

tracking-firefox120: --- → ?

The simplest testcase is data:text/html,<html contenteditable>abc</html>

  1. Load data:text/html,<html contenteditable>abc</html>
  2. Do "Select all"
  3. Right click on the selected text
URL: data:text/html,<iframe srcdoc="abc" o... → data:text/html,<html contenteditable>...

If <body> or something which is not the root element is the editing host, this bug is not reproducible.

This is a simple mistake of the previous patch. The code path is originally for
a left click handling. Therefore, there is no check whether the click point is
in a selection range because in that case, left click should collapse selection.
However, the selection should not be collapse when it's a right click in a
selection range because the context menu target is the selection range.

The ui.mouse.right_click.collapse_selection.stop_if_non_collapsed_selection
pref is set to true by default. Therefore, the existence of a non-collapsed
selection has hidden this bug. However, it's set to false, this always
happens. Additionally, editor does not set ancestor limiter of selection if the
root element is editable [1]. I think that we can now remove this special path,
but it's risky. Therefore, this patch just adds the new check into the method.

  1. https://searchfox.org/mozilla-central/rev/ce4599d3d4e20e34cb6db68f255c3dff1aec246b/editor/libeditor/EditorBase.cpp#5448,5450-5451

fixed in 120.0rc2 by backout of the regressor (bug 1845241)

status-firefox120: affected → fixed
tracking-firefox120: + → ---
tracking-firefox121: --- → +

(In reply to Dianna Smith [:diannaS] from comment #10)

fixed in 120.0rc2 by backout of the regressor (bug 1845241)

Thank you very much!

Pushed by masayuki@d-toybox.com: https://hg.mozilla.org/integration/autoland/rev/85b941e46e82 Make `nsIFrame::MovingCaretToEventPointAllowedIfSecondaryButtonEvent` check whether the right click point is in a selection range first r=emilio

https://hg.mozilla.org/mozilla-central/rev/85b941e46e82

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
status-firefox121: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 121 Branch
See Also: → 1942996
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: