Gecko esr91 work (former "Flypig's gecko dev diary")

Platform Development
#156

I think the suggestion of having a build that people can use to find problem sites is a great idea. Unfortunately it’s quite intrusive as there’s no way to install it alongside the default browser.

I can’t think of a cleaner way than replacing all of these packages:

sailfish-browser
sailfish-browser-settings
embedlite-components-qt5
qtmozembed-qt5
xulrunner-qt5

If anyone is up for giving it a go I could put together some instructions. But I absolutely wouldn’t recommend doing this on a daily device I’m afraid.

5 Likes
#157

Broken browser is something we got used to but keep in mind that you won’t be able to read mails while you have a non-matching version installed.

Do we actually need a phone though? Would the i486 build actually work in the emulator?

I looked at the broken ddg and dev console on desktop said

Laden fehlgeschlagen für das <script> mit der Quelle "https://dd53jyxmgchu8.cloudfront.net/_next/static/chunks/pages/%5Blocale%5D/home-34dda07336cb6ee1.js". dd53jyxmgchu8.cloudfront.net:100:3307

and this file actually displays xml content:

<Error>
<Code>AccessDenied</Code>
<Message>Access Denied</Message>
<RequestId>WXJKRRHF18XFP8YA</RequestId>
<HostId>
660c1ob8vlnXLWH2rmA2wkUOuK37oFZ7HPKNtIwKZgT3lPqgQwr7pRfGTHPUA13IQdRP7bXmKyE=
</HostId>
</Error>

Is that an artifact of your cloning or possibly the actual problem?

3 Likes
#158

I am avaible to help the testing, no problem in reflashing if something get broken :wink: so count me in

5 Likes
#159

@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)?

#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