@flypig (perhaps) silly suggestion that came to mind : have you tried the ESR-78 User agent on the ESR-91 build yet (when querying Duckduck go)?
The browser rendering pipeline is different on the emulator, so I think it won’t work there yet unfortunately (@piggz tried it on a native port which has a similar pipeline to the emulator, but the results weren’t good).
Thanks for flagging this; it was a mistake I made during cloning which completely changes the rendering. It might also hint that the locale has something to do with ESR 91’s rendering problems with DDG. But that needs a bit more investigation. Thanks for this input @simonschmeisser; really helpful stuff.
Thank you @Valorsoguerriero97! I’ll try to get some installable packages and instructions worked out (it might take some time; please bear with me).
Not a silly question at all. It is something I tried and while it doesn’t fix it alone, as I’ve written about today, it is at part of the problem!
Thanks all for this great input.
May these missing Sec-Fetch headers cause problems in the current browser as well?
Sometimes CloudFlare treats a user request as a bot.
“Sometimes” is a misleading term; more like “Always” is more suited…
Im beginning to remember all the sites hosted on Cloudflare because of this
So from MDN:
Firefox supports Fetch headers ONLY since ver 90…
makes sense the page works on ESR 78! So you’ve got yourself a smoking gun
EDIT: The question now is, what would break the Fetch headers on the ESR-91?
Given they are handled inside the browser; and assuming nothing has changed as such during the integration / compilation of it…meaning, they were working on the vanilla version of the ESR-91 that was used to start the work…
Worst case, they were not / there is a bug in ESR-91 (they have been supported since ESR-90 only after all)…
Perhaps there’s some hints in the bug tracker of firefox?
Only slightly related, but for people who want to test breaking/working sites on both ESR78 and ESR91 (or any other version), there are Portable packages (for Windows) of all legacy ES releases available at:
Without looking too deeply into the code, given the missing flag flypig ia talking about, it makes sense for the secfetch header to “report cross-site”, since flypig is navigating from “nowhere” to ddg. Therefore i would totally expect sameorigin to be false and not worry about that yet.
But here’s the thing; the “missing” flag is obviously set in the vanilla version of Firefox ESR-91 (as it works out of the box);
why wouldnt it be the case in the version flypig has been using?
Yes, flypig was querying the URL from the command line (which might trickle the parameter down to the browser via a case-specific path); but this would not explain - by itself - why “normal” navigation (i.e. from the URL bar of the browser) is broken too…
Don’t mention it. If I can help, I’ll be happy How much does it will take to have an installable rpm?
btw, what is the usual way to test it? Compile from sources?
Thanks all for the interesting discussion and encouragement. Just to talk around some of the points that have been raised, the reason why these Sec-Fetch
flags aren’t working properly is because they involve interaction between the front-end and the engine. For example, when a URL is loaded the front-end can signal using a flag that means “this was triggered by an external application” or “this was triggered by a user interaction”.
Only the front-end knows this info and without those signals the engine doesn’t know how to correctly set the header values, which is why we end up where we are.
I’m now working through the code to try to hook those signals up, which unfortunately is trickier than it might sound (because it has to pass through many layers of indirection to get to the place it’s needed). But I’m confident it’ll get there
The build pipeline outputs rpms, so when I’m testing I’m usually installing rpms. So in theory I have the rpms available, but in practice making sure I’ve actually got all of the rpms in the same place and that there are some sensible instructions for how to use them requires a bit of work.
It would probably make most sense to offer them via OBS (i.e. like Chum) but I don’t recall whether that’s working right now with gecko.
Makes perfect sense!
Finally we might get rid of the overrated Cloudflare “Are you a Human” \o/
I’m looking forward to your presentation at FOSDEM!
I admit I’ve not done much testing of this with ESR 91, but I would love it if this happens!
Oh fantastic! Looking forward to this being up on Chum so I can get my grubby hands on it!
@flypigz, is there a way to deploy the javascript as individual files? It would probably speed up your dev to be able to validate changes on the fly, on device…
@flypig Any news on the possibility to download and test ESR91 on SFOS devices?
I know you attended to FOSDEM 2024, but would be cool to try things out.
We’ve been a bit awaiting recently with new things here on the Jolla boat
Thanks for the detour with the avatars. I hoped during the presentation that you didn’t have to do this by hand, because it looked like quite a bit of work