1611954 - The zoom level is reset to the default value in normal window when the user reset the zoom in private browsing

Status: NEW

(Firefox :: Disability Access, defect)

Description

[Alin Ilea, Desktop Test Engineering]

Attachment: 2020-01-27_14h09_28.mp4

Affected versions:

Nightly 74.0a1 (2020-01-27), Beta 73.0b10

Affected platforms:

ALL

Steps:

1. Launch Firefox with a new profile, open a new private window and go to about:preferences.
2. Under General, go to Zoom section and select any value from the "Default zoom" dropdown e.g 150%.
3. Reach any website e.g www.facebook.com in the private window and change the zoom level manually to any level using ctrl + mousewheel or ctrl and "+ , -".
4. In the normal window access the same website like in private window (in our case www.facebook.com) and also change the zoom level manually to any level using ctrl + mousewheel or ctrl and "+ , -".
5. Go to the private window and click on the zoom level badge displayed in the address bar.
6. Go to the normal window and refresh the page.

Actual result:

When the user click on the zoom level badge in private window (step 5) and refresh the normal window page (step 6) the zoom level is reset to the default value also in normal window.

Expected result:

The zoom level in the normal window should not be reset when the user reset it in the private window.

Comment 1

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

The priority flag is not set for this bug.
:asa, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[:Gijs (he/him)]

This was marked as blocking bug 1590485; is it actually a regression from that change or did the same thing happen before the global zoom changes?

Comment 3

[Alin Ilea, Desktop Test Engineering]

Hi,

I retested the issue without changing anything on default level from about:preferences (Global zoom feature) and also using an old build where global zoom feature has not yet been introduced and the issue still occurs. So, its not a regression from that changes, but I've marked as blocking bug 1590485 because I found this issue while testing the global zoom feature. Seems to be not a global zoom feature related issue.
I think this is not a recent regression since the issue is reproducible on Nightly 64.0a1 (2018-10-06) as well.

Thanks for the observation.

Comment 4

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

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 5

[Augusto Pace]

Hi,

I was able to reproduce this issue on Mac 10.14 with Firefox version Nightly 77.0a1 (2020-04-28) (64 bits). Marking that flag as affected.

Comment 6

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

Change the status for beta to have the same as nightly and release.
For more information, please visit auto_nag documentation.

Comment 7

[:Gijs (he/him)]

It doesn't really make sense to track this on a release-by-release basis.

Comment 8

[:Gijs (he/him)]

Emilio, curious if your work on the zoom code may have fixed this already, perchance? :-)

Comment 9

[Emilio Cobos Álvarez (:emilio)]

No, not really. This seems more related to how the ContentPrefs are accessed / saved / cleared across private browsing sessions and regular sessions.

Comment 10

[Timea Cernea [:tbabos][inactive]]

Reproducible on the latest Nightly 78 on Windows 7. Updating affected flag.

Comment 11

[Seba S.]

Hello,

passing by to confirm on Ubuntu 20.04 LTS Nightly 79.0a1 (2020-06-23)(64-bit).

Regards,

Comment 12

[Alin Ilea, Desktop Test Engineering]

Still reproducible on latest Nightly 80.0a1 (2020-07-22).

Comment 13

[Marcela (Please NI request to Brindusa Tot)]

Reproducible on the latest Nightly 81.0a1 on macOS 10.14. Updating affected flag.

Comment 14

[Florencia Di Ciocco, NI to vbalducci]

Reproducible on the latest Nightly 2.0a1 (2020-09-12) (64-bit) on Ubuntu 20. Updating affected flag.

Comment 15

[Andrei Vaida [:avaida]]

Desktop QA has been highlighting this defect as a known issue for several release cycles now, following regression testing. Jamie, it would really help us if you set a priority on this bug — it will give us clarity on whether this issue is still worth mentioning in future test reports.

Comment 16

[Morgan Reschenberg [:morgan]]

(In reply to Andrei Vaida [:avaida] from comment #15)

Desktop QA has been highlighting this defect as a known issue for several release cycles now, following regression testing. Jamie, it would really help us if you set a priority on this bug — it will give us clarity on whether this issue is still worth mentioning in future test reports.

Hi avaida, we use severity to triage the extent to which users are impacted by this bug. This bug is (appropriately) an S3. You can read more about our triage guidelines here: https://wiki.mozilla.org/Accessibility/Triage
It doesn't have an assigned priority because it isn't part of our team's current roadmap, and likely belongs in another module (the fix isn't within /accessible, but there isn't a component specific to zoom so it lives here for now).