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

Status: VERIFIED FIXED

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

Description

[roland]

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.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Does this depend on Bug 1685300?

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

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

Comment 4

[Edgar Chen [:edgar]]

(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.

Comment 5

[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.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

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.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

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.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

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

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

Attachment: Bug 1770161 - Make `Element::PostHandleEventForLinks` stop setting focus to it at `mousedown` when its descendant editable element will get focus r=smaug

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.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
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

Comment 12

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/35481 for changes under testing/web-platform/tests

Comment 13

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/e850c76a0513

Comment 14

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 15

[Giorgia Nichita, Release Desktop QA]

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.