Hi,
I am one of those who read your gecko dev diary. I have one idea on the blank page. For me this happens on amazon Germany’s product detail pages. The workaround which works on ESR78 is to unlock orientation (I always lock it to portrait) and flip the phone from portrait mode to landscape mode.
I can confirm having the same experience on Amazon.
Me too, Xperia 10iii on latest “vanilla” sfos (no patches or anything fancy).
Reading your last post I was wondering if Firefox remote debugging could somehow get to work with sailfish-browser? Unfortunately my attempts (via about:config) failed so far. But maybe someone else knows some more tricks?
user_pref("devtools.chrome.enabled", true);
user_pref("devtools.debugger.remote-enabled", true);
user_pref("devtools.debugger.prompt-connection", false);
and then some sources claim you need to add --start-debugger-server
and a port (this would obviously need to be implemented for sfos-browser…)
and finally you could connect using about:debugging
from desktop to debug what’s happening on the phone.
Thanks for all of the super-useful feedback. I’ve commented on both the Amazon issue and remote debugging in the blog, although I’ve not yet done them justice, but will return to them. This is all really useful input.
Finally remembering to post thoughts i have accumulated after the last weeks of following the blog:
Have you tried with a wildly different User Agent override for DucDuckGo, like iPhone or something?
The hanging parallel compile - could that be related to some syscall that gets used in synchronization, but which is stubbed in sb2?
The syscall sounds like a very plausible reason; llvm is very picky w/r to them…the problem being that pinpointing the syscall will not be too straightforward…I had a similar issue back in the days when compiling llvm for the x86_64 target,
and finding the correct spot took alot of effort and tracing…perhaps the best would be to see if theres a test suite for sb2 to be run on the aarch64 arch and take it from there. Though I recall sb2 was not too easy to work with…shrughs
@flypig can we get a build of the browser somewhere to collect sites that are not working? Maybe it helps to find other pages.
I wonder if Firefox ESR 91 and Firefox ESR 78 behave the same way with DuckDuckGo as Browser does…
Can’t wait to see this improved browser just hearing esr91 feels good
I tried to run them a few weeks ago but failed.
Maybe the easiest thing would be to simply replace the binary…
someone already tried that?
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.
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?
I am avaible to help the testing, no problem in reflashing if something get broken so count me in
@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: