Flypig's gecko dev diary

Platform Development
#160

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.

8 Likes
#161

May these missing Sec-Fetch headers cause problems in the current browser as well?

Sometimes CloudFlare treats a user request as a bot.

3 Likes
#162

“Sometimes” is a misleading term; more like “Always” is more suited…
Im beginning to remember all the sites hosted on Cloudflare because of this :confused:

3 Likes
#163

So from MDN:

image
Firefox supports Fetch headers ONLY since ver 90…
makes sense the page works on ESR 78! So you’ve got yourself a smoking gun :slight_smile:

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 :confused: (they have been supported since ESR-90 only after all)…

Perhaps there’s some hints in the bug tracker of firefox?

6 Likes
#164

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:

6 Likes
Browser - Github not rendering codetree and readme anymore
#165

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.

2 Likes
#166

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…

1 Like
#167

Don’t mention it. If I can help, I’ll be happy :wink: How much does it will take to have an installable rpm?
btw, what is the usual way to test it? Compile from sources?

1 Like
#168

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 :slight_smile:

9 Likes
#169

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.

3 Likes
#170

Makes perfect sense!
Finally we might get rid of the overrated Cloudflare “Are you a Human” \o/

1 Like
#171

I’m looking forward to your presentation at FOSDEM!

2 Likes
#172

Thank you @PeperJohnny! I’m looking forward to seeing you there and at the event in the evening!

#173

I admit I’ve not done much testing of this with ESR 91, but I would love it if this happens!

#174

Oh fantastic! Looking forward to this being up on Chum so I can get my grubby hands on it!

1 Like
#175

Its easy check

https://www.nettiauto.com/vaihtoautot?id_country[]=73

1 Like
#176

@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…

1 Like
#177

@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

3 Likes
#178

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 :smiley:

1 Like
#179

A note about user agents: I now have an aarch64/arm64 laptop (with Windows still) and I noticed that Firefox at least claims to be an x86 browser instead of arm64 one. That was done for better compatibility with many web sites. There was a bug report for it but I can’t find it again… So perhaps it would be okay to default to the mobile user agent string, something like in post for day 144, or at least not report the architecture. Somethink what mobile Firefox does perhaps?

1 Like