Inconsistent failure to load pages
Categories
(GeckoView :: General, defect, P2)
Tracking
(Not tracked)
People
(Reporter: cpeterson, Unassigned)
References
Details
From github: https://github.com/mozilla-mobile/fenix/issues/27576.
Steps to reproduce
This is an inconsistent error. It's only been happening since I updated to 106.1.0. Sometimes (I would guess, around 10%-20% of the time?), when I open a new page, the page will be entirely blank. The loading bar will continue to show on the bottom of the screen, but waiting forever won't do anything. Reloading the page won't do anything. Selecting the URL and pressing the return arrow usually makes it better. Fully closing the tab and reopening it sometimes makes it better.
I notice this issue more when opening a new tab from another app (e.g., the Google app) than when browsing from page to page within Firefox.
Usually, when I try the same page later in the day, it works fine, and when I try the page in Chrome it works fine, which makes it seem like it's not an issue with the website itself or with my network or device, but rather with the Firefox app itself. But it's inconsistent and I don't have a clear way to reproduce it.
Expected behaviour
The page should either open correctly or display an error
Actual behaviour
The page acts like it's loading forever
Device name
Google Pixel 3a
Android version
Android 12
Firefox release type
Firefox
Firefox version
106.1.0
Device logs
No response
Additional information
I use uBlock Origin, but no other add ons.
┆Issue is synchronized with this Jira Task
Change performed by the Move to Bugzilla add-on.
Reporter | ||
Comment 1•3 years ago
|
||
See the GitHub issue for more details from multiple people reporting the issue. Someone shared a Firefox profile:
Comment 2•3 years ago
|
||
I'm one of the affected ones. The problem still persists. If you need some info, let me know. I don't have a development env for building Fenec, but I can at least connect ADB or Firefox debugger to the running instance (if it helps).
Comment 3•2 years ago
|
||
Me too, this is getting to be a bind, having to empty the cache every time I open Firefox. Well, I suppose it's a clumsy work-around, to enable "Delete browsing data on quit":
- Open tabs
- Browsing history and site data
- Cached images and files
No need to delete cookies, site permissions or downloads thank goodness. At least that seems to work fairly reliably, just have to remember to bookmark everything you want to return to...
Unfortunately things are more complicated with PWAs, since there's no "Main menu", so no means of using "Quit". So after closing the PWA window, you have to open the main app in any case, and then quit it.
I think same problem as https://bugzilla.mozilla.org/show_bug.cgi?id=1815856 - just mentions specifically Discourse forums that I happen to use a lot.
Updated•2 years ago
|
Comment 4•2 years ago
|
||
Good news, thank you.
I take the opportunity to underline that having to delete browsing data after each visit to certain websites is a considerable nuisance for users and many may not know how to do it, which would inevitably lead them to change navigator.
Comment 5•2 years ago
|
||
I now tried 115.0.1 which fixed another similar issue. However, this issue persists.
I was, however, able to capture profile of the browser when this is happening. I also tried the new "Enable Gecko logs" debug option, but I don't know where I'd find these.
The stack trace for the most weird part of the profile is:
syscall (libc.so)
GetServiceByContractID @mozilla.org/security/random-generator;1
Date.now
moz-extension://<URL>
js::RunScript
pre-compiled-script execution
PrecompiledScript.executeInGlobal
inject
AsyncFunctionNext
js::RunScript
promise callback
EventDispatcher::Dispatch DOMDocElementInserted
EventDispatcher::Dispatch
nsHtml5TreeOpExecutor::RunFlushLoop
XRE_InitChildProcess
(root)
See whole profile on https://share.firefox.dev/46EAdDV .
So, is it possible that the system just doesn't return a random number when it is asked for it? Or what else could the syscall be? malloc?
Comment 6•2 years ago
|
||
As the susceptible code is in a moz-extension block, I tried disabling all addons. But the bug remains.
Description
•