GitHub: copy and download button broken

[jrfnl]

GitHub is rolling out a new code view and it is very very broken....

The start of the page appears to load okay:

But as soon as you scroll down, the view looks empty...

The code does appears to be there, just not visible, which isn't very useful:

I'm seeing the following error in the console:

TypeError: navigator.clipboard is undefined[Learn More]  
vendors-node_modules_stacktrace-parser_dist_stack-trace-parser_esm_js-node_modules_github_bro-a4c183-ae93d3fba59c.js:1:8090
    Z https://github.githubassets.com/assets/vendors-node_modules_stacktrace-parser_dist_stack-trace-parser_esm_js-node_modules_github_bro-a4c183-ae93d3fba59c.js:1:8090
    X https://github.githubassets.com/assets/vendors-node_modules_stacktrace-parser_dist_stack-trace-parser_esm_js-node_modules_github_bro-a4c183-ae93d3fba59c.js:1:8261
    tO https://github.githubassets.com/assets/vendors-node_modules_stacktrace-parser_dist_stack-trace-parser_esm_js-node_modules_github_bro-a4c183-ae93d3fba59c.js:1:11997
    [74249] https://github.githubassets.com/assets/environment-de3997b81651.js:1:4298
    s https://github.githubassets.com/assets/wp-runtime-377d421cc9f7.js:1:136
    o https://github.githubassets.com/assets/environment-de3997b81651.js:5:134
    <anonymous> https://github.githubassets.com/assets/environment-de3997b81651.js:5:291
    s.O https://github.githubassets.com/assets/wp-runtime-377d421cc9f7.js:1:501
    <anonymous> https://github.githubassets.com/assets/environment-de3997b81651.js:5:307
    _ https://github.githubassets.com/assets/wp-runtime-377d421cc9f7.js:1:30619
    _ self-hosted:1055:17
    <anonymous> https://github.githubassets.com/assets/environment-de3997b81651.js:1:2

[rofl0r]

same here, since about a week. the output of CI actions is also no longer visible.

[Vangelis66]

GitHub is rolling out a new code view

Yes, it's been officially announced:

https://github.blog/2023-05-08-github-code-search-is-generally-available/

and it is very very broken...

same here, since about a week.

... At the time of this writing, non-signed-in GitHub members are still being served the old/UXP-fully-compatible code view, where lengthy code (>100 lines) renders fine, e.g. :

https://github.com/martok/palefill/blob/master/lib/polyfills.js

Good news is the next official Pale Moon/Basilisk release will be able to handle properly GH's new code view 😜 ...

[jrfnl]

At the time of this writing, non-signed-in GitHub members are still being served the old/UXP-fully-compatible code view,

Good to know! Unfortunately, not being signed in is not a realistic option for me. ;-)

Good news is the next official Pale Moon/Basilisk release will be able to handle properly GH's new code view.

Not sure we'll have to wait that long. I also reported it in the official feedback thread and there is the suggestion that they may have a fix and will be rolling it out in the next few days. See: https://github.com/orgs/community/discussions/54546#discussioncomment-5860133

[Vangelis66]

Not sure we'll have to wait that long.

... IIANM. official Pale Moon 32.2.0 will be released imminently; tag 32.2.0_RC1 was cut just 2 days ago 😉 ...

Later edit: PM 32.2.0_Release was tagged on May 15th and released in binary formats on May 16th...

BTW, my previous report was from the Serpent 52[/55] UXP-based unofficial/unbranded (Basilisk) forks (built from [forked]UXP master) on my older laptop...

See: https://github.com/orgs/community/discussions/54546#discussioncomment-5860133

This issue of the partially displaying/vanishing (long) code under UXP isn't reproducible by me on Chromium 86+ forks currently; OTOH, UXP isn't officially supported by GitHub/MS actually (only latest Chromium-based flavours like Google Chrome, Opera, Edge, etc. and latest Firefox stable/ESR), so I'm a bit puzzled that GH employee (AdamSchwert) in the linked discussion never queried you about the browser you're on... Let's hope the "fix" they have in the oven won't further break UXP when it goes live...

And speaking of future GH breakages under UXP, if you go and enable (under Feature Preview) the Global Navigation Update and reload a GH page, you'll find that the new GUI contains elements unresponsive under current UXP, like the + button pictured below:

New Code View was also, until recently, behind a Feature Preview enable switch, past experience dictates that GH will soon push Global Navigation Update to the masses (members), too 😞 ...

[jrfnl]

Yeah, I sometimes try those Feature Previews, but most of the time I revert that quite quickly as the user experience only degrades.

Thanks for the update on the status of the next PaleMoon release.

[Vangelis66]

as the user experience only degrades.

<rant>

Agreed 100% ; still, they'll eventually push whatever new GUI crap (best tailored for mobile devices) down our throats 😡 , with no way of reverting back - breaking along the way many user customisations (e.g. userstyles, userscripts) based around the previous GUI 😞 ...

</rant>

[Sa-Ja-Di]

Seems to be a missing ECMAScript feature/API perhaps?

Following error message are produced when trying to clicking on mentioned element:

• ReferenceError: HTMLDialogElement is not defined[Learn More] vendors-node_modules_primer_view-components_app_components_primer_primer_js-node_modules_gith-3af896-ba2b2ef33e4b.js:1:14909

(https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement)

[Vangelis66]

... Many thanks for your input 😄 , I'm aware... HTMLDialogElement is Chromium-specific code (a "Googl-ism", as nicknamed in the MSFN forums 😄 ) implemented since many years ago in Chrome (>= v36.0), however only recently adopted ("chrome-parity" policy) in Fx >=98 (!); no wonder UXP lacks such support 😭 ...

BTW, I fully agree with your comment below 😉 :

https://github.com/orgs/community/discussions/52083#discussioncomment-5898431

Regards 😸 ...

[martok]

I don't see anything obviously wrong anymore, apart from being horribly slow and looking like metabolic end-product. Can you confirm?

[jrfnl]

@martok I just upgraded to the latest Palemoon and yes, that does fix the original problem.

I agree it is excruciatingly slow when clicking on another file in the navigation pane and from what I have seen, it never actually loads that next file, but shows an error instead and you have to do an F5 page refresh for the next file to actually show, so yes, original problem fixed, but the new GH code view is still hugely problematic from a usability point of view. (but that's not a problem which Palefill can fix, or am I wrong ?)

[Vangelis66]

I don't see anything obviously wrong anymore,

... A multitude of things are currently broken under UXP-based browsers with the "new" Code View MS unleashed on May 8th 😡 ...

For starters, to mitigate their new CSS code pushed to all on May 3rd (see UXP #2230), I'm using now below uBlock Origin custom filter:

! May 3rd 2023 CSS breakage
||github.githubassets.com/assets/primer-primitives-$stylesheet,domain=github.com,important

With that out of the way, one has to simply visit (being signed-in) a "file code" page, to witness several breakages, e.g.:

https://github.com/martok/palefill/blob/master/.gitignore

1. If you place your cursor inside the code area (under Code tab), the browser's context menu can't be invoked - works in Chromium 86+ and Firefox 113:

2. The Download raw file button is unresponsive under UXP - works in roytam1's latest Serpent 55, Chromium 86+ and Firefox 113:

3. The Copy raw file button is unresponsive under UXP - if clicked, will produce a Something went wrong. Try again error message 😞 ; doesn't work in Chromium 86 (in fact, it doesn't work in any type of browser usable under XP/Vista 32-bit), but works in Firefox 113:

4. Ellipsis button, Raw file content => Download is also unresponsive under UXP and overall exhibits the same behaviour as Download raw file button described above:

5. Edit file button => Open with... github.dev will not succeed, because github.dev requires BigInt support, missing in UXP:

Add to the above the non-functioning + button I discussed previously 😡 ...

So, what I can confirm is breakage...

Regards.

[martok]

when clicking on another file in the navigation pane and from what I have seen, it never actually loads that next file, but shows an error instead and you have to do an F5 page refresh for the next file to actually show

Works for me.

1. If you place your cursor inside the code area (under Code tab), the browser's context menu can't be invoked - works in Chromium 86+ and Firefox 113:

Surprisingly, that's not because of navigator.clipboard. I actually think it's a bug that it works in Chromium: there's an explicit abort in there that should (and for us, does!) eat the event.

  if (event.button === 2) {
    event.preventDefault()
    event.stopPropagation()
    return
    //it was a right click
  }

2. The Download raw file button is unresponsive under UXP - works in roytam1's latest Serpent 55, Chromium 86+ and Firefox 113:

Works right up to the point where it should do the copy because of some old permission issue.

3. The Copy raw file button is unresponsive under UXP - if clicked, will produce a Something went wrong. Try again error message disappointed ; doesn't work in Chromium 86 (in fact, it doesn't work in any type of browser usable under XP/Vista 32-bit), but works in Firefox 113:

Not here, but also doesn't offer the file for download. Oh how I wish we had the "break on XHR" functionality from Chrome.

5. Edit file button => Open in... github.dev will not succeed, because github.dev requires BigInt support, missing in UXP:

Kinda off-Topic, github.dev never worked in PM.

[Vangelis66]

Thanks for your answers 👍 ; BTW, if it wasn't clear at first, all my "breakage" reports contained here were produced with palefill disabled, relying solely on UXP's native WC implementation (and I've been running my browser that way ever since dom.webcomponents.enabled;true became the default) ...

1. If you place your cursor inside the code area (under Code tab), the browser's context menu can't be invoked - works in Chromium 86+ and Firefox 113:

.... I actually think it's a bug that it works in Chromium:

As I wrote already, it works as planned in Firefox (113.0.1) too, so is it again a case of a bug Mozilla opted ("chrome-parity") to adopt from Google?

The Copy raw file button is unresponsive under UXP - if clicked, will produce a Something went wrong. Try again error message

Not here

Are you saying it works for you?

but also doesn't offer the file for download

It isn't supposed to; in Firefox (113.0.1/Win7SP1x64), when clicked, it produces a tooltip saying raw file copied (or something to that effect) and the code has been copied to the clipboard, after which point it can be easily pasted...

Kinda off-Topic, github.dev never worked in PM.

Well. probably 😜 ; but before the recent UXP developments (implementation of logical assignment operators, on which you worked 👍 ), github.dev would not load because of missing ??=; now it doesn't because of BigInt :cry: ...

One last thing: What is your expert view on running palefill in latest UXP browsers? Should one disable the native WC implementation? palefill disables GitHub's "soft navigation" (aka "Turbo"), I myself prefer "Turbo" enabled...

Kindest greetings.

[AroKol78]

Should one disable the native WC implementation? palefill disables GitHub's "soft navigation" (aka "Turbo"), I myself prefer "Turbo" enabled...

I have the native WC implementation and "polifill" turned on - I didn't notice any major problems (except cosmetics, but that's a different story), I think he chooses selectively, what is needed in a given version. If "soft navigation" (Turbo) option is enabled, it means lost memory (#50).

[Vangelis66]

Serpent v52.9.0 (2023-05-12) (32-bit):

After installing and enabling palefill-v1.27, together with keeping dom.webcomponents.enabled;true (will see how that goes...), I can confirm that reported issue 1:

If you place your cursor inside the code area (under Code tab), the browser's context menu can't be invoked

has been fixed 👍 ; thanks ❤️ ; all the rest (2, 3, 4, 5 here) persist...

[Vangelis66]

If "soft navigation" (Turbo) option is enabled, it means lost memory (https://github.com/martok/palefill/issues/50).

I am aware, thanks :smile: ; my browser sessions are, one way or the other, relatively short; sooner rather than later, the browser on my old H/W (2007 era Core 2 Duo) will hang (on JS-heavy pages 😠 ) and I'd have to restart it; I'm always monitoring (Task Manager) RAM and haven't yet come to a point to witness the reported memory leak - OTOH, "Turbo" saves time here for me, because GH pages load faster...

Regards

[martok]

.... I actually think it's a bug that it works in Chromium:

As I wrote already, it works as planned in Firefox (113.0.1) too, so is it again a case of a bug Mozilla opted ("chrome-parity") to adopt from Google?

Maybe. The code explicitly calls event.preventDefault() on the MouseUp-event for right button which should (and previously has - I've used it myself) suppress the context menu. Except it apparently doesn't anymore. Makes sense if we're talking about the security aspect of it, but if that was the case then why would they specifically program that "feature"? Really weird.

Are you saying it works for you?

No error message, but doesn't work either. Both buttons request the file contents, but "copy" fails due to the clipboard permission issue and "download" just... doesn't do anything, with no error.

---

One last thing: What is your expert view on running palefill in latest UXP browsers? Should one disable the native WC implementation? palefill disables GitHub's "soft navigation" (aka "Turbo"), I myself prefer "Turbo" enabled...

I have the native WC implementation and "polifill" turned on - I didn't notice any major problems (except cosmetics, but that's a different story), I think he chooses selectively, what is needed in a given version.

Correct, @AroKol78. The whole concept of a "polyfill" is that it only becomes active when it is required and doesn't do anything if not (but by actual "feature tests", not just "given version"). Additonally, Palefill tries to be smart and only inject the code if it expects it to do anything (the "superseding" mechanism). For example in the latest release we never inject the 20kB of Darktree if it looks like native WebComponents are available. And even before that, they weren't activated in that case.

If "soft navigation" (Turbo) option is enabled, it means lost memory (#50).

Correct again. Unless that has somehow changed, in which case let me know and we can disable the disabling.

[Vangelis66]

No error message, but doesn't work either. Both buttons request the file contents, but "copy" fails due to the clipboard permission issue...

Here's the tooltip generated when I press the Copy raw file button:

[dirkf]

This set of user scripts re-enables broken or non-existent tooltips when JS is disabled and bypasses the broken and pointless fake tooltip system when JS is enabled:

/* add title attribute to the parent of every <tool-tip> */
for (let ss of document.querySelectorAll('tool-tip[for]')) {
    let ll = document.getElementById(ss.getAttribute('for'));
    if (ll && !ll.hasAttribute('title')) {
        ll.setAttribute('title', ss.textContent);
    }
}
/* let's do the same for <relative-time> */
for (let ss of document.querySelectorAll('*>relative-time[datetime]')) {
    if (!ss.hasAttribute('title')) {
       ss.setAttribute('title', ss.getAttribute('datetime'));
    }
}
/* remove popover attributes to disable JS tooltips that obscure the parent element FFS */
for (let ss of document.querySelectorAll('tool-tip[popover]')) {
  ss.removeAttribute('popover');
}