Open Bug 1980162 Opened 10 months ago Updated 4 days ago

[Wayland] Request xdg activation token for new windows

Categories

(Core :: Widget: Gtk, defect, P3)

Firefox 141
defect

Tracking

()

REOPENED
145 Branch
Tracking Status
firefox145 --- fixed

People

(Reporter: xaver.hugl, Assigned: zzag)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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

Steps to reproduce:

Set "focus stealing prevention" under "Window behavior" settings in KDE Plasma to "Extreme" - this makes KWin require activation tokens for new windows (this will be the default in a future release). Open Firefox, or open a new window by dragging a tab out of an existing one.

Actual results:

The window does not get focused.

Expected results:

Firefox should request the window to be activated with xdg activation.

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

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

Slight correction: it only doesn't request activation on launch. When dragging a tab out, it does request activation, but apparently with an old serial, so it gets rejected by KWin.

Blocks: wayland
Priority: -- → P3
Summary: Request xdg activation token for new windows → [Wayland] Request xdg activation token for new windows
Severity: -- → S3

At the moment, when an activation token is requested, a focus serial
will be provided. But this is not what the compositor expects. From the
compositor side, we expect the last interaction serial, e.g. a serial of
a button press or a key press, in order to confirm that a window is
indeed raised in response to user input.

This change fixes Firefox dialogs not being raised with a new more
stricter activation model in the upcoming 6.5 Plasma release.

Assignee: nobody → vlad.zahorodnii
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Backed out for causing high failure rate on wayland mochitest plain.

Push with failures

Failure log

Backout link

Flags: needinfo?(vlad.zahorodnii)
Flags: needinfo?(emilio)

I don't see how that can be caused by this patch, pushed a try run to try to confirm but seems the pre-existing bug 1870146. Those error messages come from bug 815002, for context.

Flags: needinfo?(vlad.zahorodnii)
Flags: needinfo?(emilio)
Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → 145 Branch
Pushed by nfay@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/b5e380f17ef6 https://hg.mozilla.org/integration/autoland/rev/3458b0b1c297 Revert "Bug 1980162 - Fix activation token serials. r=emilio" for causing mochitest failures about v4l2loopback

Backed out for causing mochitest failures about v4l2loopback

Backout link

Push with failures

Failure log

Status: RESOLVED → REOPENED
Flags: needinfo?(vlad.zahorodnii)
Resolution: FIXED → ---
Target Milestone: 145 Branch → ---

That still doesn't make sense to me. Paul, are we misreading the logs somehow / are you familiar with this or know what might be going on?

There's a pre-existing intermittent for this (https://bugzilla.mozilla.org/show_bug.cgi?id=1870146) but presumably this somehow exacerbates it.

I'll try to repro in gnome or something locally.

Flags: needinfo?(padenot)
Flags: needinfo?(emilio)

FWIW I think what's going on is that the code is crashing mutter.

Flags: needinfo?(padenot)
Flags: needinfo?(vlad.zahorodnii)

I added gLastSerial = serial; to keyboard_handle_enter, that's the only diff from the original patch and seems to keep mutter happy.

Status: REOPENED → RESOLVED
Closed: 8 months ago8 months ago
Resolution: --- → FIXED
Target Milestone: --- → 145 Branch

(In reply to Emilio Cobos Álvarez [:emilio] from comment #12)

FWIW I think what's going on is that the code is crashing mutter.

That would explain what we're seeing here, good find.

QA Whiteboard: [qa-triage-done-c146/b145]

On startup, Firefox still doesn't use the activation token. The fix only improved the case where it was already running, but not initial startup.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

I confirm that the problem is still there.

see my bug report

https://bugzilla.mozilla.org/show_bug.cgi?id=2043836

See the answer of kde team on comment #7

https://bugs.kde.org/show_bug.cgi?id=520855

"You can set the focus stealing prevention to a lower value (like Medium) to make KWin apply some heuristics to activate it anyways."

thanks

Sure, let's fix that if we know how.

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

Attachment

General

Created:
Updated:
Size: