Waterfox Classic not rendering "config screen" as "overlay"

[IzzySoft]

In Waterfox Classic (here: 2020.12, i.e. the latest version), "config screen" doesn't show as overlay (as displayed in the readme), but is simply appended to the end of the page, seemingly without any CSS being applied – which makes it pretty hard to use. Apart from that, the script seems to work fine.

Note: I discovered your fork only today, I was still using a (slightly modified) version of the "original" MPIV. There the "config screen" shows fine as overlay.

Another note: using IDs (like <div id="#mpiv-setup">, as the original MPIV did) instead of rendering the CSS inside the tags (<div style=) would make it easier to adjust such things with custom UserStyles :wink:

[tophf]

The config dialog is displayed inside ShadowDOM intentionally to prevent the page from influencing and breaking the UI so apparently that browser is using a really old rendering engine if it doesn't support this technology. I won't change this ~but I can probably add an option to specify custom CSS for the config dialog if you describe a convincing example of what you want to customize there.~

[tophf]

The script will apply the custom CSS to its own config dialog, implemented in 98ea0a8a57bab54c64e76bd81836ee4b2372b15d. You can either install directly from github or wait for the new version after I test this for a while.

[IzzySoft]

The config dialog is displayed inside ShadowDOM

Ah, that indeed explains something. I vaguely remember Waterfox Classic having issues with parts of ShadowDOM.

The script will apply the custom CSS to its own config dialog

Thanks for the fast update! Just tried it (still identifies as 1.1.20), but no success: it's still appended to the very bottom of the page. Screenshot (taken from the repo's main page, so you can compare):

If you think there's some related about:config setting I should try (just looked, found nothing for "shadow" but e.g. dom.forms.select.customstyling = false and layout.css.DOM* which are all 3 enabled), please let me know.

[tophf]

The self-styling feature is not related to the appearance problem you observe in Waterfox and I don't know what to change in about:config but maybe dom.webcomponents.enabled, ShadowDOM should be supported since Firefox 63

[tophf]

Also dom.webcomponents.shadowdom.enabled

[IzzySoft]

dom.webcomponents.enabled I already had to enable to get Github working again. No such thing as dom.webcomponents.shadowdom.enabled, though (the only other is dom.webcomponents.customelements.enabled, which is enabled); WF Classic is based off FF57 with several backports, so what was added with FF63 might not be there. I don't find any mention of "shadowdom" at its issue tracker either.

It's a shame that Mozilla is permanently breaking FF (I switched to WFC when that happened to me for the 3rd time, there was one more such occasion again already I've heard). Seems like the saying is true: "most of what they call progress these days is replacing things that work with things that sound fancy" :cry:

Would you see a way to have the "old styling" available as fall-back? Just brain-storming: maybe by having that in a separate file to simply replace? Or a second script "overriding" the "standard one", so only those affected have to load it?

[tophf]

I won't implement workarounds for ShadowDOM because a normal page element would be affected by page styles and attempting to fight it by increasing CSS specificity is unreliable and fragile.

[IzzySoft]

Understandable, thanks! I guess sooner or later I have to switch to WF Current (or Nextgen) anyway, which would solve this issue as a side-effect (but make some of my addons unavailable again). For now, my "manually fix-hack'd 2017-kuehlschrank" version still works in Classic – so I keep yours bookmarked (actually, installed in parallel but disabled to not conflict), and perform the switch to yours with the switch to Current/Nextgen.

Thanks a lot for your help and fast responses!