Open Bug 1763900 Opened 3 years ago Updated 6 months ago

Focus does not change between the top document and IFRAME if an inactive Firefox window is clicked

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Version:
Firefox 99
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox-esr91 --- unaffected
firefox99 --- wontfix
firefox100 --- wontfix
firefox101 --- wontfix
firefox102 --- wontfix
firefox103 --- fix-optional

People

(Reporter: CoolCmd, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0

Steps to reproduce:

there are two <textarea> elements in the document: the first in the top document and the second in the <iframe>.

  1. click the fist <textarea>.
  2. switch to another application.
  3. click the second <textarea>.

Actual results:

"click" event has been send to the second <textarea>. the first <textarea> is still focused.

Expected results:

the second <textarea> must be focused.

this is a bug because if you switch to another tab and return, the second <textarea> will be focused.

in practice, user clicks the <textarea> in the <iframe> and starts typing a message, but the keys are handled in the top document (with commands bound to alpha keys), leading to unpredictable results.

Dear reporter,
I am not sure I am seeing your issue here.

Here is how I tested:

  1. visit the link https://jsfiddle.net/smzhgLre/
  2. click the "1st textarea" bottom_right corner
  3. switch to another app, then switch back to Firefox
  4. click the textarea showing <!DOCTYPE html> ... in the iframe

The textarea from step 4) was focused.

It would be huge help if you can provide a simple test case to show your issue. Thank you.

Flags: needinfo?(CoolCmd)
See Also: → 1764162
Flags: needinfo?(echen)

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #1)

  1. switch to another app, then switch back to Firefox
  2. click the textarea showing <!DOCTYPE html> ... in the iframe

no, you should activate Firefox by clicking the 2nd textarea

Flags: needinfo?(CoolCmd)

(In reply to CoolCmd from comment #2)

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #1)

  1. switch to another app, then switch back to Firefox
  2. click the textarea showing <!DOCTYPE html> ... in the iframe

no, you should activate Firefox by clicking the 2nd textarea

Oh right, I can reproduce it.
It seems to be a fission regression; if I disable the preference, it's not reproducible. I'll see if I can get a narrower regression window. Thanks!

I could also reproduce this with the test page in comment #1.
In my case, after activating firefox by clicking textarea in child frame, neither textarea in parent frame nor textarea in child frame get focused.
And after switching to another tab and back, the textarea in child frame will be focused.

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #3)

(In reply to CoolCmd from comment #2)

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #1)

  1. switch to another app, then switch back to Firefox
  2. click the textarea showing <!DOCTYPE html> ... in the iframe

no, you should activate Firefox by clicking the 2nd textarea

Oh right, I can reproduce it.
It seems to be a fission regression; if I disable the preference, it's not reproducible. I'll see if I can get a narrower regression window. Thanks!

I haven't found a specific commit for this rather than turning on fission. However, during the bisection, the behavior had changed and had been weird in various ways, so I think this is just one more scenario that we haven't handled well in focus management for fission.

Blocks: fission-focus
Severity: -- → S3
Priority: -- → P2
Regressed by: 1732358

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

status-firefox100: --- → affected
status-firefox101: --- → affected
status-firefox99: --- → affected
status-firefox-esr91: --- → unaffected
Has Regression Range: --- → yes

Okay, there is a case that OOP iframe tries to focus the clicked element for mousedown event, however the activate browsing context isn't yet updated, so FocusManager ends up not send the focus event, https://searchfox.org/mozilla-central/rev/d34f9713ae128a3138c2b70d8041a535f1049d19/dom/base/nsFocusManager.cpp#1673-1674. I will give a shot to fix this.

Assignee: nobody → echen
Flags: needinfo?(echen)

When clicking a OOP iframe, the mousedown event might arrive before the nsFocusManager::mFocusedBrowsingContextInContent get updated properly in iframe process, so focus event won't be fired in such case due to https://searchfox.org/mozilla-central/rev/4b3039b48c3cb67774270ebcc2a7d8624d888092/dom/base/nsFocusManager.cpp#1610-1613,1671-1674.

Status: UNCONFIRMED → NEW
status-firefox100: affected → wontfix
Ever confirmed: true

Any updates on this?

(I am not actively working on this.)

Assignee: echen → nobody
See Also: → 1860426
See Also: 1860426 → 1720990

Since Bug 1860426 (Copy disabled despite selection existing in the content process)
has been closed and moved to a duplicate of this

some 10 months later this still isnt fixed

this is what happens when your dev's dont use your product
this should have been picked up within 10mins of the bad merge going live
and fixed the next release

you all need firing out of a cannon

You need to log in before you can comment on or make changes to this bug.