UXP: GitHub relative timestamps broken since 20221107

[Vangelis66]

Browser: Serpent 52.9.0 (32-bit) (UXP-based recent build) Extension version: palefill-v1.23-3-git-20221106-g2e6e6f8

Description:

This has started happening sometime in the morning (EET) of Mon, Nov 7th 😠 ; was fine on the night of Nov 6th... Wherever GitHub displays any type of timestamp (in commits/releases/tags/comments pages etc.), relative timestamps are no longer being printed; in their place, various "mixed-type" timestamp formats are being displayed, depending on the specific GitHub page...

Example: https://github.com/violentmonkey/violentmonkey/releases/tag/v2.13.3.5

In my UXP-based browser:

In contrast, in a Chromium 87 fork:

AFAICT, no other major breakage is being observed here; FWIW, timestamp tooltips seem to work as before:

What's really peculiar, though, is that NO (Javascript) ERRORS are being printed in Serpent's Web/Browser/Error Consoles (???), making further troubleshooting here quite difficult 😞 ...

My educated guess is that this issue has a strong affiliation with recently submitted #59; however, the platform there is SeaMonkey v2.53.14 and the main hypothesis explaining the breakage seems to be that SM lacks Intl.RelativeTimeFormat support... But (recent) UXP does have native Intl.RelativeTimeFormat support, see: https://repo.palemoon.org/MoonchildProductions/UXP/issues/1969 => https://repo.palemoon.org/MoonchildProductions/UXP/pulls/1974 and it passes the test at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/RelativeTimeFormat with flying colours! 👍 Thus, either UXP's IRTF implementation is not good enough for Microsoft (i.e. GitHub), or something else is at play here... Either way, GH is still "usable" in UXP, but lack of relative timestamps is a major inconvenience 😡 ... Having a second (recent-Chromium-based) browser open just for GitHub becomes a PITA in under-resourced, older, H/W, which is "where" many of the UXP-forks users find themselves into 😉 ...

[l29ah]

In my opinion, absolute timestamps are strictly better than the relative ones.

[martok]

That's funny. It actually works. The CustomElement shadow content has the correct content. It just isn't put in place of the textContent? What the hell?

[SeaHOH]

It work on ShadyDOM.

[garoto]

All very tiresome.

[martok]

It work on ShadyDOM.

How does it compare to the polyfill you posted at JustOff/github-wc-polyfill#48 ? MutationObservers are apparently not supported in ShadyDOM (but github needs them), so that's not really an option? Or has anything changed? Also you implemented some CSS patching for :host that is pretty important...

[SeaHOH]

Yes, I can't understand how it works, and ShadyCSS is unavailability for UXP. So, I just specifically patched dispatchEvent on custom element RELATIVE-TIME.

    function dispatchEvent (event) {
      if (event.type == 'relative-time-updated')
        this.textContent = this.shadowRoot.textContent;
    }
    customElements.define = function (name, cls) {
      if (name == 'relative-time')
        cls.prototype.dispatchEvent = dispatchEvent;
      ......
    };

[Vangelis66]

... Speaking of ShadyDOM, I just saw that it got an update to v1.10.0 three weeks ago... The extension uses v1.9.0,

https://github.com/martok/palefill/blob/2e6e6f8491bdeb97885f9df199f9c22756b263b3/lib/main.js#L61-L65

would it be wise to update it to the latest release?

[Vangelis66]

What appears to be a related bug (or, probably, a different manifestation of the same bug) is that timestamp tooltips are no longer being shown when one accesses (via the edited dropdown) a comment's revision history and hovers on a specific revision :disappointed: :

in UXP:

With no timestamp tooltip, it isn't obvious (at a quick glance) how far apart those revisions stand :angry: ...

In Chromium (v86-fork):

Here, we don't have the "relative timestamps" bug (of course), so at a quick glance we can immediately tell that the two revisions are ca. 1hr apart... And since timestamp tooltips are also available, one can determine their time-distance within 1min accuracy... :wink:

[martok]

Yes, I can't understand how it works, and ShadyCSS is unavailability for UPX. So, I just specifically patched dispatchEvent on custom element RELATIVE-TIME.

I think I can roughly see how it works, but the thing is: that may be part of a solution to #30, but not this one. The event is just for future extensions, nothing listens to it.

The problem here is that changes to the attached shadow other than are not propagated from the fragment to the content elements, it seems. This is even reproducible in a simple test, to the point that I don't get why it works so often at all.

Edit: I may have come up with something that works at least without slots, but in the process broke the event redirection even more. Will have to get back to that.

Edit2: We need slots, for example for tooltips on things like reaction buttons. Which I have now also implemented, at least to the point where it works for exactly one render :smile: Carrying events over from the off-screen ShadowRoot to the real node tree is going to be wild, but shadydom as a reference should be useful.

[martok]

What appears to be a related bug (or, probably, a different manifestation of the same bug) is that timestamp tooltips are no longer being shown when one accesses (via the edited dropdown) a comment's revision history and hovers on a specific revision disappointed :

That must have been broken for ages, as UXP apparently handles title attributes on elements within <button> just completely wrong (as in, ignores them). Compare this simple test case in PM and any other browser. Report this to Moonchild, please.

[Vangelis66]

That must have been broken for ages, as UXP apparently handles title attributes on elements within <button> just completely wrong (as in, ignores them). ... Report this to Moonchild, please.

(Very long and technical) Discussion over at UXP #2030, resulting in UXP PR #2043. Many thanks @martok 👍

[martok]

Done in 1.24.

The mousover hints in the "edited" dropdown depend on the button-hittest-change in UXP, so that's going to be a bit out. But for now, we're done here. :partying_face: