Firefox extension not working under FF 125 and Wayfire; works in Sway

[flexibeast]

i opened an issue about this problem in the extension's GitHub repo. However, a user there reported they didn't observe the problem under X, and having now checked whether the problem happens under Sway, it seems it only occurs under Wayfire (built from e2d4e767).

This problem only appeared with FF 125; downgrading to e.g. FF 124 fixes the problem.

i use the Firefox Simple Tab Groups extension. Since upgrading from FF 124 to 125, groups with more than 11 entries aren't displayed correctly; instead of a list of tabs, only a blank canvas is displayed. Thus, instead of e.g.:

i instead get:

Additionally, searching for a particular tab by name results in a blank canvas, regardless of the number of results.

Any suggestions as to what i might be able to do to narrow down what's going on?

[ammen99]

Are you sure that Firefox runs natively in Wayland in both Sway and Wayfire?

If yes, I would bet that the bug is related to subsurfaces and their ordering. I recently implemented subsurface reordering but it might still be wrong. If you know a bit of C++, see this code around here: https://github.com/WayfireWM/wayfire/blob/master/src/view/wlr-surface-controller.cpp#L101

[ammen99]

Looking at it myself, I think one of the list iterations should not be reverse, maybe try removing the _reverse suffix from this:

wayfire/src/view/wlr-surface-controller.cpp

Line 135 in e2d4e76

wl_list_for_each_reverse(sub, &surface->current.subsurfaces_above, current.link)

Scrap that, the order should be correct like this. Are you using latest Wayfire-git or Wayfire 0.8.1 ?

[flexibeast]

Yes, i can confirm it's running natively in Wayland - it's not listed in the output of xlsclients(1) in both cases, and i double-checked via xeyes(1).

i also double-checked that i'm running a binary built from e2d4e76, which is HEAD in my local repo, and the latest commit on master. The binary is in /usr/local/bin/, has a birth time of 21 April (which sounds roughly correct in terms of when i last did a build), is the only Wayfire binary on my system, and the output of Gentoo's eix command doesn't list 0.8.1 as installed.

[ammen99]

Alright, if you want to fix this bug ASAP I would try fiddling with the code I linked, maybe try removing the reverse call (even though that is wrong) to see whether it fixes the problem. It would be weird if it worked in Sway but not in Wayfire in this case though. I'll look into it myself when I have a bit more time.

[flexibeast]

Use of this extension is a core part of managing my workflow, so i do want to try to fix this asap. 🙂 But at the same time, i'm not at all familiar with C++, and i certainly don't expect you to do anything other than get to it if and when you can. 🙂

i tried removing the reverse call. That resulted in the extension no longer working at all - that is, the icon is still present and visible on the toolbar, but clicking it does nothing whatsoever. Reverting that change fixed this, but unsurprisingly, the original problem is still present.

[soreau]

I tested the extension from here and it seems to work ok here with firefox nightly and wayfire git master.

[flexibeast]

Dang. i've wondered whether it's something specific to my setup .... i just tried Nightly (i.e. 127.0a1.en-US.linux-x86_64), and still get the issue. 😕

Any suggestions as to debug output i could look at? i meant to say, i've tried running FF from the command line, and looking for anything untoward, but even with MOZ_DEBUG=1, didn't get any errors or warnings in this regard ....

[flexibeast]

Ah hah! i went to about:config, searched for 'tabs', and examined those settings that were different from the defaults. browser.tabs.inTitlebar, a setting i've never manually changed myself, was different to the default: it was set to 0. When i changed it to its default, it got set to 2. And then the issue disappears. Which is good, except: So does the title bar on the FF window, which i'd prefer to keep.

In my wayfire.ini, preferred_decoration_mode is set to server, but changing it to client seems to make no difference.

@soreau: Are you able to reproduce the problem by setting browser.tabs.inTitlebar to 0? More generally, is there something in Wayfire's titlebar code that might explain what's happening on my system?