Github reports waterfox classic not being supported again

[Felipefpl]

What happened?

See pic below, i wonder if they'll ban browsers someday based on this.

Reproducible?

• [ ] I have tested this on Firefox.

Version

G3.𝑋 (Current)

What platform are you seeing the problem on?

Windows

Relevant log output

No response

[hawkeye116477]

Well, currently GH works almost correctly only if you will use Polly extension. So they say correct.

[zakius]

While that's true WebExtensions approach proven to be pretty messy and sometimes unreliable, is there some better way of injecting polyfills, without the use of network filters? ContentScripts often ended up not being executed on time so that's out of question too

[Felipefpl]

Well, currently GH works almost correctly only if you will use Polly extension. So they say correct.

I used pollyfill and it didnt work, the trick with rootnode/webcomponents in the hidden settings is better.

[reallyuniquename]

@zakius

is there some better way of injecting polyfills, without the use of network filters?

Yes. You can use beforescriptexecute event to synchronously execute arbitrary javascript code but you would have to modify Github CSP first.

[reallyuniquename]

Actually legacy extensions execute document-start userscripts so early document doesn't even have a head. So the only issue is CSP.

[zakius]

@zakius

is there some better way of injecting polyfills, without the use of network filters?

Yes. You can use beforescriptexecute event to synchronously execute arbitrary javascript code but you would have to modify Github CSP first.

CSP seems to be ignored when dealing with web accessible resources but document-start (at least the WE version) is unreliable, sometimes scripts on the page start executing before injection finishes

[reallyuniquename]

I did try beforescriptexecute + document-start before and it worked well with legacy extensions. Firefox doesn't run any of the Github scripts until after my code is executed. You only have to add event listener as early as possible so maybe you could get away with just beforescriptexecute on WE.

CSP seems to be ignored when dealing with web accessible resources

The problem is unsafe-eval is required and that is prohibited by Github CSP.

[zakius]

any method of injecting scripts using ContentScript sometimes fails to execute polyfill on time (even when using beforescriptexecute) while using request filters always works, in both cases it triggers some CSP errors, but the latter works anyway

[reallyuniquename]

Well it doesn't for me. How do you execute a polyfill inside beforescriptexecute event?

[zakius]

by adding script tag with source targeting web accessible resource on top of the head, though it looks like in ContentScript it doesn't guarantee that script being executed first, when I do it with RequestFilters document is modified before it gets parsed so it goes properly in order

eval-ing the polyfill may work with beforescriptexecute though, but as you said it requires playing with CSP header and that probably should be avoided

[reallyuniquename]

Yeah you need to eval it to execute it synchronously. If you go this road I recommend @JustOff/scriptlet-doctor for CSP patching on per site basis.

[zakius]

I was hoping for something non-intrusive and reliable enough to be usable as a system-extension, may be possible with legacy if dug deep enough but probably still a bad idea.

On the other hand using beforescriptexecute potentially could allow automatic recognition of required polyfills to make it just work without injecting too much code into pages that don't need it

[reallyuniquename]

Well I don't see any other ways to do that. Any script injection through DOM insertion will be unreliable and bug 1267027 is still open. Modifying CSP does feel intrusive but you can't even block some ads without it.

Do share if you figure anything else.