Potential bug with StyloaiX AGENT_SHEET loading

[Sneakpeakcss]

There's a known [1] [2] problem with customizing tooltip pop outs in Firefox where some tooltips (e.g. home button,search,extension buttons) can't be styled with the usual code in userChrome.css:

tooltip{
  -moz-appearance: none !important;
  background: red !important;
  color: blue !important;
}

The only way to make it work that i ever found was to "load the agent sheet before the first window has opened" which this loader unfortunately doesn't support out of box(.ag.css,as.css), but previously in Firefox 78 ESR i was able to do it with StyloaiX with the same code as above.

Unfortunately after updating to FF ESR 91.8 (portable)/FF Developer Edition 100.0b2 (portable) and downloading newest loader/styloaix files, this no longer works:

No matter if it's AGENT/USER/AUTHOR it doesn't seem to make a difference now. I've tested this on a different script loader mentioned in [2] and it works there without a problem, so i'm not sure if this is a bug or just intended drawback after some changes to loader/styloaix in the past year.

[xiaoxiaoflood]

Until 2020, userChromeJS listened to domwindowopened to inject scripts. Since then it's using chrome-document-global-created which runs even a little earlier. So I don't believe it was something caused by something I changed.

It was a change in Firefox codebase or it never worked at all with StyloaiX. You said it worked with ESR78, but exactly with which version of StyloaiX and, more importantly, of userChrome.jsm?

I confirm that current version doesn't work.

MrOtherGuy's userChromeJS (which btw is a fork from mine) injects userChrome_ag_css.uc.js and userChrome_au_css.uc.js before anything, that's why it works. This is something they implemented, my userChromeJS has never worked that way.

I could add something similar to my userChromeJS, but given that the style only works properly when it loads before the window is created, there's no purpose on handling it with StyloaiX, because a restart would be needed anyway, right? So it would only work as a separated script/style just like it's in MrOtherGuy's repo.

[Sneakpeakcss]

Well this is going to be "amusing" in a way…

Technically my main browser that i'm using atm is ESR78 based (Waterfox G3), but while fixing my userChrome.css i always switch to a Portable Firefox version, just to make sure nothing is breaking between the two.

And i actually found my FF ESR78 Portable with the same profile (userChrome.jsm + styloaix.uc.js) and it seems like you were correct… This never worked with Firefox and it seems to be based on Waterfox codebase change.

So it's no surprise that it doesn't work in newer FF versions while i'm fighting with proton theme. Whoops.

And yes, my usage of StyloaiX for this purpose was mostly an easy way to make tooltip styling work with your loader, which was a more 'sane' option than the workarounds found at the time (scripts that silently opened(?) Browser Toolbox, because for some reason opening it correctly applies tooltip styling from userChrome.css).

While MrOtherGuy's loader seems to be more helpful with css styling it unfortunately introduces changes that makes a lot of scripts break, while yours seems to be the more universal one when it comes to scripts from random forums/repositories (not to mention extensions without any tinkering).

So yes, at the end it looks like this is more of an enhancement request for the ability to load .ag.css,as.css files in a similar way to help with Firefox styling.

[xiaoxiaoflood]

I just tried with WF G3.2.6 and it doesn't work either. Still skeptical if there was ever a condition in which StyloaiX was able to work for that edge case, applying the style without needing to open a new window or Browser Toolbox for the first time,

[Sneakpeakcss]

I've created a new Waterfox G3.2.6 profile and it turns out that it doesn't work… At least not out of box.

First you have to change "Tab Bar Position" to "Top under address bar" user_pref("browser.tabBar.position", "topUnderAB"); After that change waterfox theme in customise menu so it creates an extensions.activeThemeID preference in config (you can also do it by hand with an empty string and it still works as long as this pref exists in about:config)

And at the end the most random step… You have to close waterfox window while it's in maximized state. As long as "sizemode":"maximized" exists in xulstore.json and previous preferences are in about:config then StyloaiX somehow manages to style tooltips.

Here's a prepared package with my current loader+StyloaiX+xulstore.json+prefs.js that you can just drop into a new profile to see it working without doing everything by hand.

TestSetup.zip

This is so random that i'm not surprised about any scepticism, but after some time i managed to pinpoint it and reproduce this with 100% consistency on my end.

[xiaoxiaoflood]

Thanks for detailed steps to reproduce.

This should be fixed now, not only to apply style in initial window but also to instant apply any change you make.

[Sneakpeakcss]

It works! At least on my Win10 ESR91, thanks for a quick update.

There's one marginal behavior i found, while it instantly applies the style on/off in editor window, if you try to turn off the whole style file in the popup window

it doesn't refresh in this scenario, at least while turning it off (turning it on applies correctly).

Also it looks like the file on/off state isn't respected by editor window at all. You can apply any changes in it even if the edited file is turned off. From what i can tell this isn't a new behavior and it acted the same way in pre-update version of StyloaiX.

At the end of the day unless someone edits files that are turned off then this is very marginal.

[xiaoxiaoflood]

if you try to turn off the whole style file in the popup window it doesn't refresh in this scenario, at least while turning it off (turning it on applies correctly).

Thanks, fixed.

Also it looks like the file on/off state isn't respected by editor window at all. You can apply any changes in it even if the edited file is turned off. From what i can tell this isn't a new behavior and it acted the same way in pre-update version of StyloaiX.

It's working as expected. Enabled/disabled is respected, it's just that Instant Preview has higher priority. If preview is enabled, you want the style to be temporarily applied even if its state is disabled. As soon as you close Editor, style (preview) is removed.

If Instant Preview is not checked and you haven't clicked Preview button, disabled styles will never be applied, even after being modified and saved.