Closed Bug 1632425 Opened 2 years ago Closed 2 years ago

[ contenteditable ] In anchors I can't select one word with double click


(Core :: DOM: Selection, defect)

75 Branch



Tracking Status
firefox79 --- fixed


(Reporter: andrei.draganescu, Assigned: saschanaz)


(Blocks 1 open bug)



(4 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

  • Open a page that uses TinyMCE or another contenteditable text editor
    (e.g. WordPress' classic or Gutenberg editors)
  • Add a 5 word sentence (Pharetra Fusce Bibendum Mollis Cursus)
  • Select 3 words and make them an anchor by formatting as Link
  • Deselect the words
  • Try to select one of the linked words with double click

Actual results:

  • The whole link is selected

Expected results:

  • Only the double clicked word should be selected

Hi andrei.draganescu,

Thank you for your report.

Could you please attach a test page where we can try to reproduce and verify this issue?

Please also let us know if you see it reproducing on the latest Firefox Nightly version, you can download it from here:


Flags: needinfo?(andrei.draganescu)

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → DOM: Selection
Product: Firefox → Core

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (non,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Severity: normal → --
Severity: -- → S3
Attached file bug1632425.html
Ever confirmed: true

Element::PostHandleEventForLinks always marks MouseEvent as nsEventStatus_eConsumeNoDefault after the first click event, so the second one is ignored by nsIFrame::HandlePress and thus not handled by nsIFrame::PeekOffset.

Flags: needinfo?(andrei.draganescu)

Oh, turns out this behavior is intended to be a feature. HTMLEditorEventListener::MouseDown intentionally detects an anchor and selects the whole element.

Now the question is whether we want to keep the behavior or not. I think it makes sense, as selecting a whole anchor helps when a user wants to edit its href. Masayuki, thoughts?

Flags: needinfo?(masayuki)

Also, andrei.draganescu, have you seen any web incompatibility due to this Firefox behavior?

Flags: needinfo?(andrei.draganescu)

Yeah, our editor makes sence if user wants to update the link information including unlink it. On the other hand, if user wants to modify the text in a link, our editor behavior looks like inconsistent. If we could have both features with modifier steate difference, it might be better.

Flags: needinfo?(masayuki)

Any modifier in mind? A triple click might also make sense, not sure.

Assignee: nobody → krosylight

I think a triple click does make sense as it's intention is "select all in this paragraph", which can naturally translate in this case to "select all in this anchor". Workarounding is also easier in a triple click case as a user can just do it outside of an anchor.

Attachment #9153168 - Attachment description: Bug 1632425 - Triple click to select anchors → Bug 1632425 - Part 2: Triple click to select anchors

Depends on D77812

Attachment #9153168 - Attachment description: Bug 1632425 - Part 2: Triple click to select anchors → Bug 1632425 - Part 3: Triple click to select anchors
Pushed by
Part 1: Add EditorUtils::IsPointInSelection() r=masayuki
Part 2: Mark const methods as such r=masayuki
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla79
Pushed by
Part 3: Triple click to select anchors r=masayuki

Thank you everyone participating here! You are all awesome :)

Flags: needinfo?(andrei.draganescu)
Regressions: 1643495
You need to log in before you can comment on or make changes to this bug.