Closed Bug 1952343 Opened 10 months ago Closed 10 months ago

"Load and diff" not working on Nightly Linux

Categories

(Core :: DOM: Core & HTML, defect)

Firefox 138
Desktop
Linux
defect

Tracking

()

RESOLVED FIXED
138 Branch
Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 --- unaffected
firefox136 --- wontfix
firefox137 --- wontfix
firefox138 --- fixed

People

(Reporter: afranchuk, Assigned: edgar)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

I tried about:memory "Load and diff" on Nightly 138.0a1 (2025-03-05). After the first file dialog appeared and selecting a file, a second was never shown and no memory information was shown. I then tried on Release 135.0 and that worked as expected.

This works for me on MacOS Nightly, and this code has not changed in forever, so I suspect a file picker widget issue?

Component: about:memory → Widget: Gtk
Product: Toolkit → Core

And confirmed that if set browser.disable_pickers_background_tabs to false, then it works as expected.

Component: Widget: Gtk → DOM: Core & HTML

Pinged :edgar in Slack to ask to look at this

Severity: -- → S3
Flags: needinfo?(echen)
Flags: needinfo?(echen)

I could not reproduce this on Windows, either. It looks like this only occurs on Linux.

Summary: "Load and diff" not working on Nightly → "Load and diff" not working on Nightly Linux

Hmm, I think this is caused by the platform difference. The file picker causes the browser window to lose focus. about:memory attempts to open the file picker again after the first file is selected by waiting for the change event, and that occurs before the focus is switched back to the browser window on Linux, whereas other platform that occurs after the focus has switched back to the browser window.

I tried to "delay" the gtk response for file picker by scheduling it for the next event loop iteration. However, that didn't help; the focus switch still occurred later. It is probably not easy to make Linux behave like other platforms.

I created a similar case and tested it on Chrome, Chrome also block the second file picker on Linux, so I am not concerned about web compatibility.

I think we could either make about:memory check and wait the focus before attempting to open the picker again, or allow about page to open picker in background. I would opt for the former solution first. If more use cases arise on about pages, we could consider excluding them from the check.

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

The double file picker thing is very odd so a specific work around sounds good to me.

Otherwise, the HTMLInputElement doesn't handle the mPickerRunning flag right if
it is in parent process. There is no such problem on content process because
the IPC is async.

Next week is the final week of beta for Fx137.
Looks like this is on track to land in Fx138 and potentially uplift to Fx137 if needed.

That should be fine. While I could see a user looking at about:memory, doing diffs of them is a very niche activity so it is likely not very common for people to do.

Plus somebody can always save memory reports from an affected version, then do a diff in a fixed version.

Pushed by echen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/60d4fd3913aa Notify nsI{Color|File}PickerShownCallback asynchronously when picker is blocked; r=emilio https://hg.mozilla.org/integration/autoland/rev/bb4a8e6e5b41 [about:memory] Wait for document to regain focus before reopening the file picker; r=mccr8

Backed out for causing linting failure

Flags: needinfo?(echen)
Pushed by echen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/011e15bbbe66 Notify nsI{Color|File}PickerShownCallback asynchronously when picker is blocked; r=emilio https://hg.mozilla.org/integration/autoland/rev/f809c12942b6 [about:memory] Wait for document to regain focus before reopening the file picker; r=mccr8
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → 138 Branch
Flags: needinfo?(echen)

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

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

For more information, please visit BugBot documentation.

Flags: needinfo?(echen)

This is a developer feature and not common to use, developer can use a fixed version to open diff.

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

Attachment

General

Created:
Updated:
Size: