GitHub broken (again) on Palefill 1.24 + SeaMonkey (Shadow DOM)

[dilworks]

Just updated to 1.24 here to notice that GitHub goes back to its usual state of brokenness (for example: being unable to read commit history on file lists, or view assets on release tags). The console shows loads of "TypeError: this.attachShadow is not a function" (with 9-level stacktraces), and this: "TypeError: DarkTree: NodePrototype.getRootNode is available, but ShadowDOM is not.".

Rolling back to 1.23 restores regular operation here. Shadow DOM is not implemented AT ALL on SeaMonkey (yet!), so full polyfills are a must here.

[martok]

Shadow DOM is not implemented AT ALL on SeaMonkey (yet!)

That's not true, which is what the error message is saying. Implementing getRootNode without the rest of ShadowDOM is a completely ridiculous patch that UXP has hidden behind a default-off pref dom.getRootNode.enabled for good reason. Maybe Seamonkey has that too?

DarkTree is theoretically able to work around that more cleanly than the previous version, but the error message is there specifically because this is a clear sign of a (more than usual) broken browser.

[SeaHOH]

Maybe we should overwrite it without throws a error?

[dilworks]

Shadow DOM is not implemented AT ALL on SeaMonkey (yet!)

That's not true, which is what the error message is saying. Implementing getRootNode without the rest of ShadowDOM is a completely ridiculous patch that UXP has hidden behind a default-off pref dom.getRootNode.enabled for good reason. Maybe Seamonkey has that too?

DarkTree is theoretically able to work around that more cleanly than the previous version, but the error message is there specifically because this is a clear sign of a (more than usual) broken browser.

Decided to ask upstream and got the following answer: https://ircbot.comm-central.org:8080/seamonkey/20221203#c205826

SeaMonkey has no dom.getRootNode.enabled pref (but it has dom.webcomponents.enabled and dom.webcomponents.customelements.enabled, both defaulting to false for good reasons, although on later betas enabling them is useful)

[martok]

SeaMonkey has no dom.getRootNode.enabled pref

Thanks for asking. This was what UXP did, see also the commit message for rationale. Maybe frg finds something like that useful.

---

Don't get me wrong, this is less of a technical and more of a policy issue. Palefill is developed on Pale Moon. Everthing else is contributor-developed or accidental, and looking at the logs I would consider our Seamonkey support unmaintained as of now. Which is interesting given the recent influx of quite a few Seamonkey users.

That doesn't mean I won't accept a pull request from someone who has actually tested it (in this case that would be a PR to the DarkTree repo), but one thing I've learned from coming back after that involuntary break is that the technical debt that comes from adding random untested changes is not something I want to have again.

[dilworks]

Well, apparently SeaMonkey is not picking this for good reasons too (risk of breaking things even more, needs developer consensus, and the obvious constrained manpower limitations), and I understand that the focus of Palefill is Pale Moon/UXP, so your reasoning is also sound.

SeaMonkey-targeting addons are getting rarer and rarer, which explain the sudden increase of SM users of Palefill as we also have the same web compatibility troubles (thanks Google!), and I'm very thankful for your addon if any case. Hope someone else can pick up the slack here and bring a more proper fix, while our favorite browsers continue with the arduous (almost impossible!) task of getting up with the JavaScript vomit that we know as the "modern web of living standards".

[martok]

Doesn't look like anyone volunteered, closing.