1848474 - [116 Regression with RFP and "Dark Reader" extension] Pages stop showing midway, new pages don't load, refresh stops working

Status: REOPENED

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[zesanup]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

This bug occurs very frequently during general browsing. Not hard to encounter at all.

Actual results:

The bug starts off by refusing to show part of the page you've just loaded. So on Wikipedia, for example, you could end up seeing the introductory section, but the rest of the page below it is blank. Scrolling up and down does nothing. There is no loading indicator, so I have to assume that the page must be loaded and is just not showing up properly.

Once the bug shows up, interaction with the page doesn't work, except for scrolling. You can't tap on any links.

And new pages don't load either. The loading indicator gets stuck around 1/3rd of the way and stays there forever.

Also, refresh stops working. The button does nothing. Not even long-press.

Finally, the bug also starts affecting previously opened tabs. They are fully loaded and viewable because the page load happened pre-bug, but refresh doesn't work, and neither does tapping any links.

There is no way to reset the bug except to force-close the app, or swipe it away from Recents.

Expected results:

All pages should open and work normally like in 115 and below.

Comment 1

[zesanup]

My bad. Only force-stopping works. Not swiping away from Recents.

Comment 2

[zesanup]

Could this please be triaged? I would have waited longer before bumping this, but the bug is horrible. Depending on my browsing needs, I now need to force-close Fenix about 40-50 times a day.

If I only need to open a few pages for long-form reading, then this bug doesn't get triggered as much. But if I need to open link after link, such as when browsing Wikipedia or Reddit, then it becomes a major obstruction.

Comment 3

[Chris Peterson [:cpeterson]]

zesanup, thanks for reporting this problem! Knowing that this is a new regression in 116 gives us a good head start for debugging.

What device model and Android OS version are you using? Do you have any add-ons installed? Can you please share your Firefox's about:support information?

Comment 4

[zesanup]

A Xiaomi Mi 5 on LOS 19.1 (Android 12L) and a Pixel 5a on LOS 20 (Android 13). Both have the exact same set up. uBO, Decentraleyes, Dark Reader, and Privacy Badger. uBO is set to hard mode.

Let me see if there's any private data to be redacted in my about:support info.

Comment 5

[zesanup]

Okay. The txt file is ready. How do I send it to you?

Comment 6

[Chris Peterson [:cpeterson]]

(In reply to zesanup from comment #4)

A Xiaomi Mi 5 on LOS 19.1 (Android 12L) and a Pixel 5a on LOS 20 (Android 13). Both have the exact same set up. uBO, Decentraleyes, Dark Reader, and Privacy Badger. uBO is set to hard mode.

Thanks!

Maybe try testing with your extensions disabled for a day? Maybe there is a regression in 116's extension code or a recent uBO blocklist update is causing problems? We have been making a lot of changes to Fenix's extension code, in preparation to support more extensions:

https://blog.mozilla.org/addons/2023/08/10/prepare-your-firefox-desktop-extension-for-the-upcoming-android-release/

Comment 7

[Chris Peterson [:cpeterson]]

(In reply to zesanup from comment #5)

Okay. The txt file is ready. How do I send it to you?

You can attach it to this Bugzilla bug report or, if you prefer, email me at cpeterson at mozilla dot com. The about:support data does not include any personal information about the user, browsing history, or saved passwords.

Comment 8

[zesanup]

Attachment: Fenix-about-support.txt

Here you go.

Comment 9

[Chris Peterson [:cpeterson]]

Thanks. You might also try clearing Firefox's app cache in system settings > Apps > Firefox > App info > Storage > Clear cache. Clearing the app cache shouldn't affect your saved cookies or passwords, but clearing storage would.

https://www.androidcentral.com/how-and-when-clear-app-cache-or-data-android

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 11

[Lorand Janos]

Hi!
We have tried reproducing this issue on the following RC builds: 116.2.0 (from August 7th) as the build prior to logging the issue, also 116.3.0 build 1 and 116.3.0 build 2 with the following scenarios:

• checked the builds without any addons installed and the browsing experience was as expected.
• installed and activated the add-ons that were mentioned above (uBO, Decentraleyes, Dark Reader, and Privacy Badger, with uBO set to hard mode) and the browsing experience was as expected in this situation as well.

We don't have the exact devices mentioned in the ticket, but we tested the ones closest to those:

• Xiaomi Mi11 Lite (Android 11).
• Redmi 9C NFC (Android 10).
• Google Pixel 7 (Android 14).
• Google Pixel 7 Pro (Android 14).
• Huawei P40 Lite (Android 10).
• Huawei P50 Pro (Android 11).
• OnePlus 6 (Android 9).

Comment 12

[zesanup]

Hi, I got the bug again even after clearing cache. Anything else I could try out?

Also, the important preferences listed above don't seem to show the usual suspects that are enabled: RFP, FPI, etc. (Basically, Mull implements the Arkenfox user.js). I'm uncertain if any of those could be relevant. This looks like a display+requests issue.

Comment 13

[Chris Peterson [:cpeterson]]

(In reply to zesanup from comment #12)

Also, the important preferences listed above don't seem to show the usual suspects that are enabled: RFP, FPI, etc. (Basically, Mull implements the Arkenfox user.js). I'm uncertain if any of those could be relevant. This looks like a display+requests issue.

I overlooked that you're using the Mull browser. I don't know the effect of those user.js changes on Android or what other changes Mull makes. I recommend trying Firefox 116 from the Google Play Store (with and without the same extensions you have with Mull) to see if the problem is still reproducible.

Comment 14

[zesanup]

Seriously, my bad on this. It turns out this bug is already known to the Mull developer as being caused by the Dark Reader extension. I should have checked beforehand.

However, from what I've read, there is still no clarity on whether the bug is in Firefox 116, in Mull 116, or in the extension itself. Let me see if I can get more info on this.

I'm closing this myself for now. If it turns out to be a problem in Firefox after all, I'll reopen it and ping you.

Comment 15

[zesanup]

Update: The bug is caused due to interaction between RFP and Dark Reader. However, I also tried Firefox Beta 117.0b9 (since about:config isn't available on Stable yet) , and it doesn't occur on this version. So there's a possibility that it's already fixed as a matter of course.

Comment 16

[Chris Peterson [:cpeterson]]

(In reply to zesanup from comment #15)

Update: The bug is caused due to interaction between RFP and Dark Reader. However, I also tried Firefox Beta 117.0b9 (since about:config isn't available on Stable yet) , and it doesn't occur on this version. So there's a possibility that it's already fixed as a matter of course.

Thanks for identifying that this bug is caused by an interaction between RFP and Dark Reader. Do you have a link to a Mull bug report?

I'm still curious to know which code change in version 116 caused this new problem. Did you try reproducing the problem in Firefox Nightly with Dark Reader by manually enabling privacy.resistFingerprinting in about:config? (Firefox Nightly because about:config is not currently enabled in the regular Firefox release version.)

Comment 17

[zesanup]

Thanks for identifying that this bug is caused by an interaction between RFP and Dark Reader.

The bug was already known to the Mull developer. It was silly of me to complain here right away, instead of checking that repo first. :/

Do you have a link to a Mull bug report?

https://gitlab.com/divested-mobile/mull-fenix/-/issues/82#note_1525643244

Did you try reproducing the problem in Firefox Nightly with Dark Reader by manually enabling privacy.resistFingerprinting in about:config?

What I've stated above is that I did this test with Firefox Beta 117.0b9, because it's one version closer to release, and also lets the user access about:config. Should I try it using Nightly specifically?

---

I just thought of another alternative: I could perform this test using the last 116 beta (https://github.com/mozilla-mobile/firefox-android/releases/tag/fenix-v116.0b8) so that we can get as close to the 116 release version as possible.

Comment 18

[zesanup]

Update: A user confirmed that the problem extends to Desktop Firefox as well: https://github.com/darkreader/darkreader/issues/11631#issuecomment-1694239188

Comment 19

[Chris Peterson [:cpeterson]]

(In reply to zesanup from comment #18)

Update: A user confirmed that the problem extends to Desktop Firefox as well: https://github.com/darkreader/darkreader/issues/11631#issuecomment-1694239188

Thanks for finding that! I'll share the report with the Desktop Firefox's Add-ons team.

Comment 20

[Chris Peterson [:cpeterson]]

• Reopening this bug since multiple Dark Reader users have confirmed that this is a regression in Firefox 116, not Dark Reader: https://github.com/darkreader/darkreader/issues/11631#issuecomment-1697943515. They report that the problem is only reproducible in Dark Reader's dynamic mode and not in its filter, filter+, or static modes.

• Moving from Fenix to Core product because Dark Reader users report seeing hangs on both Android and desktop: https://github.com/darkreader/darkreader/issues/11631#issuecomment-1694239188

Comment 21

[Chris Peterson [:cpeterson]]

What RFP changes made in 116 might cause an extension that modifies a page to use a lot of CPU or get stuck in an infinite loop? :tjr says: "we did change a lot of underlying things in RFP [in 116] that could be related".

Comment 22

[Tim Huang[:timhuang]]

The recent RFP change doesn't touch on how RFP works regarding protection mechanisms. It changes how we enable fingerprinting protections individually. However, we did implement new fingerprinting protection features, such as canvas randomization and font visibility restriction. But, it's unclear to me if they are the root cause.

I've tested both Desktop Nightly 119 and 116 but couldn't reproduce the issue on both versions. Maybe it's because the websites I browsed don't have this issue. Are there known websites that can reliably reproduce this issue so that we can further analyze the underlying problem here? Also, comment 15 reports that this issue no longer exists after Beta 117. Does this mean this issue got fixed somewhere already?

:zesanup, since you reported this issue, would you be able to verify if this issue has already been fixed on the Desktop as well? Thanks.

Comment 23

[zesanup]

Sorry, I'm stuck on Windows 7 and so ESR 115. You'd probably get the needed info by asking users in the linked Dark Reader issue. I can test on Android, if that'll help. Fenix Beta is on 118 now so that'll be an additional data point.

Are there known websites that can reliably reproduce this issue so that we can further analyze the underlying problem here?

Wikipedia. Super easy to notice the bug, on mobile at least. Just keep opening new pages or tabs rapidly and you're bound to come across it.

Comment 24

[zesanup]

Status update: Fenix version 117 is also affected. Dark Reader version still the same: 4.9.65. Again, the easiest and fastest method to reproduce is to open a few tabs of Wikipedia and tap on links.

I don't know why my Fenix 117 beta test from earlier didn't show the bug.

Comment 25

[Chris Peterson [:cpeterson]]

QA, can you please try to reproduce this bug in Fenix 117 with Dark Reader extension version 4.9.65?

I don't know which Android device models or OS versions the affected users have. I don't see any device info mentioned in these related bug reports;

Dark Reader bug report: https://github.com/darkreader/darkreader/issues/11631
Mull bug report: https://gitlab.com/divested-mobile/mull-fenix/-/issues/82

Comment 26

[miralobontiu]

Attachment: logcat.txt

I was able to reproduce a "freeze" of loading some news pages (bbc.com, cnn.com) on the Beta 118.0b7 build with Google Pixel 6 (Android 14).
I had the following settings:

• in about:config I set the 'privacy.resistFingerprinting' pref to "true",
• I had the Dark Reader add-on installed and enabled, version 4.9.65.

As seen in the short video below, the news pages aren't loading.

Additional details:

• NOT able to reproduce this on Nightly 119.0a1,
• I set the pref back to "false", and the pages loaded, and were actionable,
• I reset the pref to "true" and was not able to reproduce it for the second time,
• tried the same settings on a Xiaomi Mi8 Lite (Android 12), without any luck,

Comment 27

[miralobontiu]

Attachment: 1848474.mp4

Comment 28

[Harshit Sohaney]

Do we support this pref for android? Can you still verify the behaviour?

Comment 29

[Chris Peterson [:cpeterson]]

(In reply to Harshit Sohaney from comment #28)

Do we support this pref for android? Can you still verify the behaviour?

We don't support about:config on Firefox Android, though we do allow Nightly and Beta users to use about:config at their own risk. We have no settings UI to enable privacy.resistFingerprinting in the Release channel, but the Tor Android Browser does enable privacy.resistFingerprinting in their own builds. We don't want to break Tor.

Comment 30

[Ryan VanderMeulen [:RyanVM]]

Tim, we're seeing more reports about this issue in the wild affecting both desktop and Android. Can you please give this another look and set a severity?

Comment 31

[Chris Peterson [:cpeterson]]

Emilio's fix for RFP infinite loop bug 1866409 should fix this Android bug. This fix will be uplifted to a Firefox 120.0.1 dot release.

Comment 32

[Tim Huang[:timhuang]]

I am looking into an issue that we don't properly exempt fingerprinting protection from extension in Bug 1856732. It could be the root cause of the issue.

Comment 33

[Donal Meehan [:dmeehan]]

:timhuang could you triage the severity on this?