user.js
user.js copied to clipboard
arkenfox
RFP: zoom per eTLD+1 per tab not remembered on some sites
🟥 https://github.com/arkenfox/user.js/wiki/5.2-Troubleshooting
- [x] I have read the troubleshooting guide, done the checks and confirmed this is caused by arkenfox
- unchecked issues ~~may~~ will be closed as invalid
🟪 REQUIRED INFO
- Browser version & OS: FF 109.0.1, macOS
- Steps to Reproduce (STR):
a. In a fresh profile, flip
browser.contentblocking.categorytostrictandprivacy.resistFingerprintingtotrue. b. Go to http://www.hdtvsolutions.com/ and change the zoom to something other than 100%. c. Go to any other page on that site. - Expected result: Zoom on the new page should be the same as it was on the homepage.
- Actual result: Zoom has reset to 100%.
- Console errors and warnings: Nothing relevant
- Anything else you deem worth mentioning: Also occurs on https://www.chicagomanualofstyle.org/. Haven't come across any others so far. Only noticed this since updating FF & AF to 109.
One more thing: If you set default zoom to anything other than 100% in about:preferences, that setting will be respected when you first open either of those websites I mentioned, but then when you go to any other page on those sites it will open at 100%.
RFP ignores site settings for zoom preferences on each new tab, and any eTLD+1 change. It's not meant to "reset" if you stay on the same eTLD+1 in the same tab
using http://www.hdtvsolutions.com/
nothing
- RFP is off, everything sanitized (site prefs etc)
- load site: am at 100%
- turn ETP off on the site (it auto-reloads)
- zoom to 120%
- open another page, e.g.
Pricesin the same tab - we are at 120% - open another page, e.g.
Typein a new tab (right click > open in a new tab) - we are at 120% (because it's using site preferences)
just ETP strict
- close + sanitize
- load site
- RFP is off
- load site: am at 100% - ETP is on (shield is blue)
- zoom to 120%
- open another page, e.g.
Pricesin the same tab - we are at 120% - open another page, e.g.
Typein a new tab (right click > open in a new tab) - we are at 120% (because it's using site preferences)
just RFP
- close + sanitize
- enable RFP
- load site
- turn ETP off on the site (it auto-reloads)
- load site: am at 100% - ETP is on (shield is blue)
- zoom to 120%
- open another page, e.g.
Pricesin the same tab - we are at 100% (not expected) - open another page, e.g.
Typein a new tab (right click > open in a new tab) - we are at 100% (expected, it's anew tab)
won;t check the 4th combo of ETP + RFP
AFAICT this isn't anything to do with ETP, it's RFP and how it's handling the eTLD+1 for some sites ?
same with https://www.chicagomanualofstyle.org/ - make sure you use a same eTLD+1, e.g the red box - it's RFP on it's own
FWIW, I changed to ETP standard with RFP and same result
@tomrittervg
STR
- enable RFP
- go to https://www.chicagomanualofstyle.org/
- zoom to 110%
- click the red box link for "The Chicago Manual of Style Contents" (as it's one that has the same eTLD+1)
- zoom not remembered per tab per eTLD+1
I wonder if it's the www part causing an issue
~~edit: regression is in FF94 ... will run moz-regression~~
Just tested tor browser 12.0.3 based on ESR102 and using http://www.hdtvsolutions.com/ the problem does not exist
regression ended with
INFO : Narrowed nightly regression window ... to [2021-12-15, 2021-12-16] (1 days) (~0 steps left)
@practik , see my last comment, last line. I think you're right, this has something to so with ETP (wasn't that switched on by default in FF94?). I bisected my FF portables, which are all defaults except I sanitize on close and a few visual tweaks. 93 was good, 94 was bad
But I ran moz-regression on the whole 94 nightly cycle and came up empty
must be something that was backported/flipped - regression is in 97
INFO : Narrowed nightly regression window from [2021-12-15, 2021-12-17] (2 days) to [2021-12-15, 2021-12-16] (1 days) (~0 steps left)
WARNING : Skipping build 646bd6a3104d: Unable to find build info using the taskcluster route 'gecko.v2.mozilla-central.shippable.revision.646bd6a3104d8a94a342f6de273f829cecf1de50.firefox.win64-opt'
WARNING : Skipping build 66b5b425d27f: Unable to find build info using the taskcluster route 'gecko.v2.mozilla-central.shippable.revision.66b5b425d27f9880ebde030e4c0a5e433da569ee.firefox.win64-opt'
WARNING : Skipping build 792c9fbceb71: Unable to find build info using the taskcluster route 'gecko.v2.mozilla-central.shippable.revision.792c9fbceb7170c1c00d8bed57a2c3d2cf6d1913.firefox.win64-opt'
INFO : Stopped
this has something to so with ETP (wasn't that switched on by default in FF94?)
what made you think it might be ETP, the TB test? I run mozregression as well but ETP doesn't seem to make a difference.
I also tried on https://www.youtube.com and the www doesn't seem to matter there.
what made you think it might be ETP,
just speculation .. you know, urlclassifiers and stuff and TB doesn't use any of ETP (AFAICK). I tried to look at commits on mercurial for 2021-12-16 but not sure how to get an actual list. There were a couple of interesting patches but TBH, IDK what I'm looking for
understood. did you fill a ticket at bugzilla or we can avoid that since you tagged Tom above?
not sure how to get an actual list
you could run hg log --date 2021-12-16 --stat in mozilla-central but it's not very telling at first glance..
or we can avoid that since you tagged Tom above
we'll see if he pokes his head up, otherwise I might poke him in a week's time
Has this ever worked? The code seems to imply this is what should happen and it's working as 'intended' and has always done that.
Has this ever worked
Yes. Issue was not present before - hence moz-regression good vs bad
Issue was not present before
Just to confirm this: I use the Chicago site pretty regularly and started noticing the issue there about two weeks ago when I updated to FF 109. It never used to happen before that.