[Bug] Dark Reader + RFP causes Fennec 116/Mull 116 to become unresponsive or show pages partially

[opusforlife2]

Prerequisites

• I searched for any existing report about this bug to avoid opening a duplicate.
• I can reproduce this bug in a new, unmodified web browser profile with Dark Reader installed as the only extension.
• I understand I need to use the Broken Website Report template if this bug I am reporting occurs on a single website.

Bug Description

I can reproduce this bug in a new, unmodified web browser profile with Dark Reader installed as the only extension.

This template bullet is quite restrictive. RFP counts as modifying the browser profile, but it's necessary to reproduce the bug here.

Anyway, ever since version 116, Fennec/Mull have been facing this bug where page display and interactions become problematic.

It has many manifestations:

• Some pages load only partially.
• Some pages don't load at all (the loading indicator never shows up, and the tab just stays like that, unresponsive)
• Some pages become unresponsive, where you cannot tap on links or even refresh the page.

And so on.

This bug does not occur on 115 and below. It is new in 116. It also occurs on 117.

Website Address

N/A

Steps To Reproduce

1. Enable RFP in about:config
2. Install Dark Reader.
3. Start browsing.

Expected Behavior

Just like 115 and below, browsing should be unaffected.

Actual Behavior

The combo of the extension (as of version 4.9.65) and the pref causes pages to stop loading halfway, or not load at all, or become unresponsive, etc.

Screenshots

No response

Operating System

Android 13

Web Browser name and version

Mull/Fennec 116.3.0 and 117.0.0

Dark Reader version

4.9.65

Additional Context

No response

[opusforlife2]

I just remembered even Firefox Beta has access to about:config. Flipping RFP there and using Dark Reader doesn't seem to cause this bug.

Does that mean this bug is already fixed (as of 117.0b9)?

[SkewedZeppelin]

because context was left out: https://gitlab.com/divested-mobile/mull-fenix/-/issues/82#note_1525643244

[Riteo]

I can confirm identical behaviour on desktop firefox 116.0.3 (115 worked fine), so this is probably not limited to fennec/mull.

[lfourquaux]

This happens with Dark Reader in dynamic mode, but filter, filter+ and static mode seem unaffected (at least to me). Maybe the dynamic mode is looping endlessly? In this case, issue #11546 may be related.

[Riteo]

Maybe the dynamic mode is looping endlessly?

@lfourquaux that could definitely be the case, as my laptop fan was going crazy and htop reported a single core with an utilization of 100% at full speed.

[cpeterso]

Firefox 116 (desktop and Android) was released on August 1 (https://whattrainisitnow.com/calendar) and Dark Reader version 4.9.65 was released shortly after, on August 10: https://addons.mozilla.org/en-US/firefox/addon/darkreader/versions.

To determine whether this regression was caused by a code change in Dark Reader 4.9.65 or Firefox 116, has anyone tested:

• the latest Dark Reader (4.9.65) in Firefox 115
• and/or the previous Dark Reader (4.9.64) in Firefox 116?

[Uj947nXmRqV2nRaWshKtHzTvckUUpD]

Happens for me was well on mull browser on android latest version 116.3. Whole page freezes and never loads. dark reader version 4.9.65. However I didn't experience this on fennec same versions combo

Can confirm that fennec has privacy.resistFingerprinting set as false while mull has it true (in about: config)

Disabing dark reader in mull fixes the issue

[lfourquaux]

On my phone, the problem appeared before the upgrade to 4.9.65, probably after the upgrade to Firefox (Fennec) 116.

[cpeterso]

I tried reproducing in Windows Firefox 116 by installing Dark Reader (4.9.65), setting the privacy.resistFingerprinting about:config pref to true, and loading a dozen news websites. Some pages seemed slow to load, but I wasn't able reproduce the browser or page hangs.

I was hoping I could use the mozregression tool to bisect the Firefox Nightly builds and identify the first bad build. If anyone has reliable steps to reproduce on Firefox Desktop, here are the instructions for testing with mozregression:

https://mozilla.github.io/mozregression/quickstart.html

[opusforlife2]

the latest Dark Reader (4.9.65) in Firefox 115
and/or the previous Dark Reader (4.9.64) in Firefox 116?

@cpeterso I tested DR 4.9.65 with Fenix Beta 115.0b9, and I don't see the bug.

I can install Fenix Beta 116.0b9, but there's currently no way to install an older version of an extension on Android, as you know.

---

This happens with Dark Reader in dynamic mode

I can confirm this too. Only dynamic mode has this problem. Setting it to one of the others lets you browse normally. But they are quite inferior to dynamic mode (some websites are white with filter+, some with filter, so you have to keep switching frequently).

[kujaw]

Darkreader 4.9.65

Abrowser 97.0.2 - no problem
Abrowser 116.0.3 - 100% CPU on some websites when using dynamic mode.

[cpeterso]

Here's a Firefox bug reporting tracking this regression: https://bugzilla.mozilla.org/show_bug.cgi?id=1848474

[opusforlife2]

117 also has the bug. Description updated.

[opusforlife2]

Has it been figured out where the bug fix needs to occur? In FF's code, or DR's?

[dev0T]

Don't know if this is related but Dark Reader was making unable for me to interact with pages on Fennec/Mull.

[opusforlife2]

Yes, that's what this bug is about. But you shouldn't have this bug on Fennec, unless you enable RFP manually. Mull has it on by default.

[magicgoose]

RFP = resist fingerprinting?

I have
privacy.resistFingerprinting = false,
privacy.fingerprintingProtection = true,
and vanilla Firefox (latest, on Fedora), and I also have this problem
(pages would randomly lock up with 100% single core CPU, so far reproduced with Gmail and Wikipedia)

edit: oops, didn't realize it's on Android. Anyway, looks like almost the same thing happens on desktop since recently (only with DarkReader enabled)

[Humorist2601]

I have been using Dark Reader for some time on mull and haven't encounter the same unresponsive pages issue again