Closed Bug 1770161 Opened 10 months ago Closed 7 months ago

When link contains contenteditable element focus/focusin event is not consistent with Chrome

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Firefox 101
Desktop
All
defect

Tracking

()

VERIFIED FIXED
105 Branch
Tracking Status
firefox105 --- verified

People

(Reporter: roland, Assigned: masayuki)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.67 Safari/537.36

Steps to reproduce:

  1. Open https://jsfiddle.net/4knL8hav/1/
  2. Click anywhere on the "Hello" text

Actual results:

console->

  • focus <a href="#">
  • focusin <a href="#">
  • focus <span contenteditable="true">
  • focusin <span contenteditable="true">

There was a focus/focusin event for both the link and the contenteditable element.
Also content editor is not working.

Expected results:

In Chrome the console output is:

  • focus <span contenteditable="true">
  • focusin <span contenteditable="true">

And content is editable.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: UI Events & Focus Handling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → DOM: UI Events & Focus Handling
Product: Firefox → Core

Does this depend on Bug 1685300?

Flags: needinfo?(masayuki)

No. It seems that this is a bug of nsFocusManager...

Flags: needinfo?(masayuki)

(In reply to roland from comment #0)

Also content editor is not working.

Thanks for reporting this issue, could you elaborate more about "content editor is not working"?
I did some quick try, I do see the focus event behavior is different than Chrome, but content editor is working.

Flags: needinfo?(roland)

It might look like it is working, but it is not working properly:

  • There is no blinking cursor sometimes. To reproduce: focus/blur several times the edited area
  • Unable to place the cursor with mouse in the edited area sometimes. To reproduce: focus/blur several times. Sometime it will be at the right position, but usually at the start of the text.
  • Unable to select text within the edited area
  • TinyMce 5 has trouble with the multiple focus/blur with different target which results in editor blur.

For example with the current implementation blur event can not be trusted:

  1. Open https://jsfiddle.net/cbqhu8m2/
  2. Click on the Hello text to start edit
  3. Click on the Hello again somewhere to change cursor position

Actual result:
#2 first click

  • Focus <A>
  • Blur <A>
  • Focus <Span>
    #3 second click
  • Blur <Span>
  • Focus <A>
  • Blur <A>
  • Focus <Span>

Expected result:
#2 first click

  • Focus <Span>
    #3 second click

Real world example which won't work in Firefox: You want to remove contenteditable attribute on blur event to cancel editing.

Flags: needinfo?(roland)

I see the odd events only when I move focus with a left mouse button click. So I think that it's caused by here:
https://searchfox.org/mozilla-central/rev/4bce7d85ba4796dd03c5dcc7cfe8eee0e4c07b3b/dom/base/Element.cpp#3178,3188,3192-3193

We should stop doing this in the reported case, but I'm not sure why we do this. So, we need to investigate the reason first.

I reached this change (attachment 86986 [details] [diff] [review]). It's caused by the race of focus handling after mousedown event listener and a popup opened by it. So, when editable area in the link is clicked, we don't need to do this since opening popup at clicking editable region is not a realistic scenario.

Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → Desktop

The severity field is not set for this bug.
:sefeng, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(sefeng)
Severity: -- → S2
Flags: needinfo?(sefeng)

I'll take a look in my spare time, but feel free to take this if you'd like to work on this😉

Assignee: nobody → masayuki
Status: NEW → ASSIGNED

If <a href="..."> element has editable elements and clicked in it, focus will
be moved to the editing host of the clicked element. Therefore,
Element::PostHandleEventForLinks shouldn't set focus to the link element in
the case.

Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/e850c76a0513
Make `Element::PostHandleEventForLinks` stop setting focus to it at `mousedown` when its descendant editable element will get focus r=smaug
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/35481 for changes under testing/web-platform/tests
Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → 105 Branch
Upstream PR merged by moz-wptsync-bot
QA Whiteboard: [qa-105b-p2]

Reproduced this issue on Win 10, using the STR from Comment 0, on an affected Nightly build from 2022-05-19.
Verified as fixed on Firefox 105.0 (20220915150737) on Win 10, Ubuntu 21.04 and macOS 10.15.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-105b-p2]
You need to log in before you can comment on or make changes to this bug.