1889406 - Input in user/password field not possible on a-trust.at without switching focus

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[cooperbang]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:124.0) Gecko/20100101 Firefox/124.0

Steps to reproduce:

• Open https://www.a-trust.at/konto
• Click at Log-In mit ID-Austria
• Click at Anmelden mit ID-Austria
• Try to enter username and password

The problem does not occur with the "rpm" version of Firefox.

Actual results:

Input not possible until you open Gnome Activities overview and switch back to Firefox afterwords.

Expected results:

Input of username and password should be possible without opening GNOME Activities Overview before.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Toolkit::Password Manager' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[cooperbang]

Info: Same problem occurs when using the Firefox Snap in Ubuntu 22.04 Wayland.

Comment 3

[Monica Chiorean]

I used snap 124.0.2 on Ubuntu 23.10 and I was able to enter characters in the email/password field.
Cooperbang, does the problem still happen if you start Firefox in Safe Mode? (Safe Mode disables add-ons, extensions and themes, hardware acceleration and some JavaScript stuff in order to exclude some possible reasons for problems.) See https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode. Thank you.

Comment 4

[cooperbang]

I have also tried it with windows 11 (Firefox Safe Mode activated).
Here, too, it is not possible to enter the user name and password directly after accessing the website. Only after you move the focus to another Firefox tab or click on the URL bar can you enter something in the input fields.

Comment 5

[cooperbang]

Additional information:

It apparently only happens if you start via https://www.a-trust.at/de

• Open https://www.a-trust.at/de
• Click on the "Konto" button
• Click on the "Log-In mit ID-Austria" button
• Click on "Anmelden mit ID-Austria" button
• Try to enter username and password

Comment 6

[Monica Chiorean]

I was able to reproduce it on Win11x64 and FF 124.0.2 using steps from comment #5.
Marking issue as New for engineering input.

Seems to be a regression:
2024-04-05T13:53:27.855000: DEBUG : Found commit message:
Bug 1850335 - Google Advanced Search terms not remembered when navigating back after visiting a search result. r=smaug

Differential Revision: https://phabricator.services.mozilla.com/D190467

2024-04-05T13:53:27.856000: DEBUG : Did not find a branch, checking all integration branches
2024-04-05T13:53:27.862000: INFO : The bisection is done.
2024-04-05T13:53:27.863000: INFO : Stopped

app_name: firefox
build_date: 2023-10-17 08:00:37.950000
build_file: C:\Users\svuser_1.mozilla\mozregression\persist\fd6b422ae3e6--autoland--target.zip
build_type: integration
build_url: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/INIklFHLS2GOlnRG48pfCw/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
changeset: fd6b422ae3e6288547b10ebdb73868dbf8146f3c
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e891ad8158b3106dceb2199ed2c74c0c2f05fa88&tochange=fd6b422ae3e6288547b10ebdb73868dbf8146f3c
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: INIklFHLS2GOlnRG48pfCw

Comment 7

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

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

:peterv, since you are the author of the regressor, bug 1850335, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 8

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

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

Comment 9

[Pascal Chevrel:pascalc]

Is there something we can do since it's a P1/S2? Thanks

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to cooperbang from comment #0)

Actual results:

Input not possible until you open Gnome Activities overview and switch back to Firefox afterwords.

To clarify the actual-results here: from my testing, it seems input isn't entirely impossible; it's just that the relevant text-field doesn't get fully autofocused when the page loads, for some reason; it doesn't get styled as focused, and entered text doesn't end up in it.

We do show it focused (and allow text to be entered) if you explicitly click it, or change the focus forward-and-back using Tab / Shift+Tab, or (as in the STR) if you let the Firefox window as-a-whole lose and regain focus.

(The fact that changing window focus makes a difference here suggests that the textfield does seem to have some sort of pending/partial autofocus status.)

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug

Comment 12

[Daniel Holbert [:dholbert]]

So the bug here is that the textfield isn't focused when the site loads (at t=16s in my screencast), though it is focused when I switch tabs away and back (t=24s). And as noted above, users can explicitly focus the textfield by clicking it (not shown in screencast).

Comment 13

[cooperbang]

The bug is that the focus cannot be set on the input field until another tab is clicked or the url bar is clicked.

Comment 14

[James Graham [:jgraham]]

I also can't focus by clicking the input. Using tab the focus does eventually end up in the textbox after cycling through the chrome controls. Similarly I can click on the URL bar and then click on the input and it does get focus. So it seems like as long as we do something that resets the focus state then the page works as expected, but it's a non-trivial workaround and a user would be forgiven for assuming the page is just totally broken in Firefox.

It seems probably relevant that the input element is in a (same-origin) iframe.

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to James Graham [:jgraham] from comment #14)

I also can't focus by clicking the input. Using tab the focus does eventually end up in the textbox after cycling through the chrome controls.

Yeah, my results match yours when I'm testing today. I'm not sure how I was getting less-bad results in comment 10, but I'm not seeing those less-bad results anymore.

Comment 16

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

Moving back to DOM:Navigation after chatting with :denschub.

S2 based on the webcompat triage rating. Let me know if you have a different thought.

Hi Adam, can you please help with this bug? Thank you.

Comment 17

[Adam Vandolder [:avandolder]]

Reverting the patch linked in comment #6 does appear to fix the issue.

In particular, without reverting that patch, I get a series of logged warnings of the form:

[Child 185771, Main Thread] WARNING: aNode has the parent node but it does not have aNode!: 'nodeStart >= 0', file /home/adam/dev/moz/dom/base/RangeUtils.cpp:190
[Child 185771, Main Thread] WARNING: 'child1Index.isNothing()', file /home/adam/dev/moz/dom/base/nsContentUtils.cpp:3190

when interacting with the login form, which do not occur with the patch reverted.

Comment 18

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

Assigning to Adam, thank you!

Comment 19

[Donal Meehan [:dmeehan]]

:avanholder, next week is the final week of beta for Fx129.
Do you expect to have something in time for Fx129 release that is safe to uplift?

Comment 20

[Adam Vandolder [:avandolder]]

Unfortunately, no, at this point it doesn't look like we'll be able to make 129. I have yet to find a minimal reproducible test case.

Comment 21

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

We're still sorting out a solution which won't cause side effects.

Comment 22

[Sean Feng [:sefeng]]

I think the issue is related to how we handle process switches.

When we get to use a new content process for navigation, we notify https://searchfox.org/mozilla-central/rev/5959ec6b84d66592a77a3e5e2d2aedc1b3e7d4c5/docshell/base/BrowsingContextGroup.cpp#225-239 the content process if the active BC is in a BrowsingContextGroup that the process owns. But we don't do the same operation if we reuse a launched process.

This also explains why we only see the issue with loading https://www.a-trust.at/de first (comment 5), and no issues with https://www.a-trust.at/konto, because we'd reuse the process for https://a-trust.at only if we start with https://www.a-trust.at/de.

I'll put up a patch for this. Hope it's as simple as applying the same operation to reusing a launched process.

Comment 23

[Sean Feng [:sefeng]]

Attachment: Bug 1889406 - Notify the focus/active BC to content process for subframes when BrowserParent is first created

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1f04fc7b4c57
Notify the focus/active BC to content process for subframes when BrowserParent is first created r=dom-core,hsivonen

Comment 25

[Noemi Erli[:noemi_erli]]

Backed out changeset 1f04fc7b4c57 (Bug 1889406) for causing build bustages CLOSED TREE

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&collapsedPushes=842382&resultStatus=testfailed%2Cbusted%2Cexception&revision=1f04fc7b4c574538fa911e87f2484fc706c55ff3

Log: https://treeherder.mozilla.org/logviewer?job_id=474987661&repo=autoland&lineNumber=133165

Backout: https://hg.mozilla.org/integration/autoland/rev/d262d4f4e51127d233153091e923bf5ae75ee84e

Comment 26

[Sean Feng [:sefeng]]

I forgot to commit two files, sorry!

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6de34af51f4b
Notify the focus/active BC to content process for subframes when BrowserParent is first created r=dom-core,hsivonen

Comment 28

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/6de34af51f4b

Comment 29

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

The patch landed in nightly and beta is affected.
:sefeng, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox131 to wontfix.

For more information, please visit BugBot documentation.

Comment 30

[Sean Feng [:sefeng]]

I'd prefer we let the patch ride the train, in case unexpected behaviour happens.

Comment 31

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Reproducible on a 2024-09-18 Nightly build on Windows 10 using the STR from Comment 5.
Verified as fixed on Firefox 132.0b2 and Firefox Nightly 133.0a1 on Windows 10, Ubuntu 22, macOS 14.