Open Bug 1813433 Opened 3 years ago Updated 5 months ago

Inconsistent failure to load pages

Categories

(GeckoView :: General, defect, P2)

All
Android
defect

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.

Severity: -- → S3

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).

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.

Severity: S3 → S2
Priority: -- → P2

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.

See Also: → 1840665

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?

As the susceptible code is in a moz-extension block, I tried disabling all addons. But the bug remains.

You need to log in before you can comment on or make changes to this bug.