RFP: zoom per eTLD+1 per tab not remembered on some sites

[practik]

🟥 https://github.com/arkenfox/user.js/wiki/5.2-Troubleshooting

• 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.category to strict and privacy.resistFingerprinting to true.
  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.

---

[practik]

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

[Thorin-Oakenpants]

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. Prices in the same tab - we are at 120%
• open another page, e.g. Type in 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. Prices in the same tab - we are at 120%
• open another page, e.g. Type in 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. Prices in the same tab - we are at 100% (not expected)
• open another page, e.g. Type in 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 ?

[Thorin-Oakenpants]

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

[Thorin-Oakenpants]

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

[Thorin-Oakenpants]

@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

[Thorin-Oakenpants]

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

[fxbrit]

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.

[Thorin-Oakenpants]

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

[fxbrit]

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

[Thorin-Oakenpants]

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

[tomrittervg]

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.

[Thorin-Oakenpants]

Has this ever worked

Yes. Issue was not present before - hence moz-regression good vs bad

[practik]

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.