Closed Bug 1599783 Opened 4 years ago Closed 4 years ago

Drop-down displayed in wrong position from Privacy & Security -> Enhanced Tracking Protection

Categories

(Firefox :: Settings UI, defect, P2)

72 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 73
Tracking Status
firefox-esr68 --- unaffected
firefox70 --- unaffected
firefox71 --- unaffected
firefox72 blocking verified
firefox73 + verified

People

(Reporter: ailea, Assigned: ntim)

References

(Regression)

Details

(Keywords: regression)

Attachments

(7 files)

Attached video 2019-11-27_16h56_18.mp4

Affected versions:

Nightly 72.0a1 (2019-11-27).

Affected platforms:

Windows 7, Windows 10.

Steps:

  1. Launch Firefox with a clean profile.
  2. Access the "about:preferences#privacy" page.
  3. From the Enhanced Tracking Protection section, click on the "Strict" radio button, then on the "Custom radio button".
  4. Open the Cookies drop-down menu or Tracking content drop-down menu.

Actual result:

The drop-down is opened in a wrong position.

Expected result:

The drop-down should be opened accordingly under the drop-down button.

Regression range:

Will come back with a regression range ASAP.

Note 1: If the issue is not reproducible on the first try please switch between "Strict" and "Custom" radio buttons and try again to open the drop-downs from the Custom section. (See the video attachment (made on win7) ).
Note 2: The wrong position of the drop-downs apparently is easier to reproduce on windows 7, on win10 the drop-downs position just sometimes is wrong but every switch between standard, strict and custom radio buttons the page behaves like a refresh.(See the second attachment (made on win10) ).
The issue is not reproducible on Release 70 or Beta 71.

Attached video Win10.mp4

This is a pretty awful user experience. We should find the regressor ASAP.

Flags: needinfo?(alin.ilea)

Hi,

I'm working on this but I couldn't find a regression range using mozregression, I cannot reproduce the issue with any build opened from mozregression, but if I download the build from the same date manually I can reproduce it. So, I will try to find manually an approximate regression range finding the first build affected.

Flags: needinfo?(alin.ilea)

You might need to get your mozregression to update - new versions that support the new GCP-backed storage for build artifacts just got released (see bug 1596201 comment 14).

Attached image image.png

The problem happens only in the case when "Reload All Tabs" pane is indicated. See attached screenshot.

STR.

  1. Open any page e.g https://www.wikipedia.org/
  2. Open about:preferences#privacy
  3. Switch to "Standard" if not standard. and then switch to "Strict"
  4. Switch to "Custom"
    --- make sure "Reload All Tabs" pane is indicated. If not, reload the webpage of step 1 and goto step3
  5. Click one dropdown list

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5e6b050c9427da9ae37ca4c7c8000ba5b47ceea8&tochange=1a85c571a4645798ba4d9295ba2504acac149ac8

Regressed by: 1576946

Thanks for the regression hunting, Alice.

I can't reproduce using either mozregression or manually attempting to reproduce (tested on mac, win10 and win7). The steps from comment #6 also did not help me reproduce.

:ntim or :mats, can you take a look?

Flags: needinfo?(ntim.bugs)
Flags: needinfo?(mats)

[Tracking Requested - why for this release]:
Shouldn't ship with this.

It does not happen if clicking slowly on the dropdown(i.e mousedown -> wait a moment -> mouseup).

I am able to reproduce this with the steps outlined by Alice in comment #6.

I unfortunately can't reproduce this on macOS, but the screencast seems to show that the prefs area shifts shortly when clicking on the dropdown, so I wonder if adding a max-width on .main-content would prevent the shifting.

Also, I wonder if this is the same issue as bug 1593060 ? Daniel, what do you think ?

Flags: needinfo?(ntim.bugs) → needinfo?(dholbert)

(In reply to Tim Nguyen :ntim from comment #11)

I unfortunately can't reproduce this on macOS, but the screencast seems to show that the prefs area shifts shortly when clicking on the dropdown, so I wonder if adding a max-width on .main-content would prevent the shifting.

I'm confused why that'd help... The prefs area shifts but it shifts next to the search item at the top. If anything that seems like a layout issue to me.

Also, I wonder if this is the same issue as bug 1593060 ? Daniel, what do you think ?

It can't be, the regression window for this bug points to bug 1576946 which landed in 72 nightly, and the regressor for bug 1593060 landed in 71, ie bug 1593060 first occurred before this bug regressed....

Flags: needinfo?(ntim.bugs)

(In reply to :Gijs (he/him) from comment #12)

(In reply to Tim Nguyen :ntim from comment #11)

I unfortunately can't reproduce this on macOS, but the screencast seems to show that the prefs area shifts shortly when clicking on the dropdown, so I wonder if adding a max-width on .main-content would prevent the shifting.

I'm confused why that'd help... The prefs area shifts but it shifts next to the search item at the top. If anything that seems like a layout issue to me.

It's kind of hard to investigate since I can't reproduce.

Also, I wonder if this is the same issue as bug 1593060 ? Daniel, what do you think ?

It can't be, the regression window for this bug points to bug 1576946 which landed in 72 nightly, and the regressor for bug 1593060 landed in 71, ie bug 1593060 first occurred before this bug regressed....

It could be the same underlying issue, so the fix in bug 1593060 could fix this problem as well.
They're both related to XUL menupopups in CSS grid (<stack> uses CSS grid as of bug 1576946).

Flags: needinfo?(ntim.bugs)

I've just triggered some try builds for bug 1593060:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=7f0c4f0102edd48bc237131db31c91469b27efe0

They should finish building in ~1h30.

Alice0775, could you please check if you can reproduce the issue on that build once it's done ? Thanks :)

Flags: needinfo?(alice0775)
Attached image another issue

if text size bigger 125% in Windows(Select the Start button, then select Settings > Ease of Access > Display. To make just the text on your screen larger, adjust the slider under Make text bigger. )
I noticed another issue. See attached.
When the expander button is clicked, contents shift to the right temporarily.
(this is same regression range)

Flags: needinfo?(alice0775)

And I can also reproduce these issue on Nightly72.0a1 Ubuntu18.04

(In reply to Tim Nguyen :ntim from comment #14)

I've just triggered some try builds for bug 1593060:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=7f0c4f0102edd48bc237131db31c91469b27efe0

They should finish building in ~1h30.

Alice0775, could you please check if you can reproduce the issue on that build once it's done ? Thanks :)

https://hg.mozilla.org/try/rev/7f0c4f0102edd48bc237131db31c91469b27efe0
The try build did not fix these issue. I can still reproduce these issue on Windows10 and Ubuntu18.04.

(By the way, about bug 1593060, the gap is reduced, but still appear(few pixels) on the try build Windows10 and Ubuntu18.04)

Severity: normal → major

What are our options here to get this fixed for 72? (I'm seeing this too on current linux nightly, and it's pretty awful.)

I just managed to reproduce this on a Linux machine.

A workaround I found was setting border: 2px solid transparent on .pane-container. 1px doesn't fix the issue however.

That doesn't sound like a workaround that can be shipped, but it can possibly help for investigation ?

Is this still reproducible in latest Nightly?

(Latest nightly should have bug 1593060's fix, which was updated since comment 17 here to address the parenthetical "gap is reduced but still appears" parenthetical issue that Alice0775 noted at bottom of comment 17)

Flags: needinfo?(dholbert)

(In reply to Daniel Holbert [:dholbert] (blocking needinfo/review, due to AFK on parental leave 12/9 - 1/6) from comment #20)

Is this still reproducible in latest Nightly?

(Latest nightly should have bug 1593060's fix, which was updated since comment 17 here to address the parenthetical "gap is reduced but still appears" parenthetical issue that Alice0775 noted at bottom of comment 17)

I can still reproduce the issue on Nightly (Build ID 20191206093947)

I can also still reproduce the issue on latest Nightly (Build id: 20191208213628) using win 10.

This is ultimately not a frontend bug, so moving to layout to ensure this gets the appropriate triage attention.

Component: Preferences → Layout
Product: Firefox → Core

Can people reproduce it on Linux? I don't seem to be able to repro here.

Priority: -- → P2

I can reproduce the issue with str Comment 6 on Nightly73.0a1 Ubuntu18.04.

Build ID 20191209095039
Update Directory
/home/fuku/Desktop/nightly
Update History
Update Channel nightly
User Agent Mozilla/5.0 (X11; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0

OS: Windows → All

(In reply to Tim Nguyen :ntim from comment #19)

I just managed to reproduce this on a Linux machine.

A workaround I found was setting border: 2px solid transparent on .pane-container. 1px doesn't fix the issue however.

That doesn't sound like a workaround that can be shipped, but it can possibly help for investigation ?

Does re-applying display: -moz-stack also fix this, and if so, can we do that for 72 to buy us some time? It seems everyone is busy and people struggle to reproduce this, and this is glitchy enough that I'd really prefer we didn't ship it.

Flags: needinfo?(ntim.bugs)
Assignee: nobody → ntim.bugs

Urgh, looks like I forgot to change the closing tag in my patch, which meant I couldn't open about:preferences. Here's a new try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b06ed02f5d1b33ee5975b788b758c1a153e8e2e1

I can confirm from the try push that reverting to -moz-stack fixes the problem. I guess we'll go with that for uplifting to beta, and possibly until someone has time to find a proper solution :)

Alice0775, could you double-check that this is no longer reproducible with the try push in comment 30? Thanks!

Flags: needinfo?(ntim.bugs) → needinfo?(alice0775)

(In reply to Tim Nguyen :ntim from comment #31)

I can confirm from the try push that reverting to -moz-stack fixes the problem. I guess we'll go with that for uplifting to beta, and possibly until someone has time to find a proper solution :)

Alice0775, could you double-check that this is no longer reproducible with the try push in comment 30? Thanks!

The try build fix this issue on both Windows10 and Ubuntu18.04. No longer reproduce this problem on the try build.

However, I can still reproduce the issue of STR comment #15 on the try build Windows10.
See screencast: https://youtu.be/9iuTf37gFng

Flags: needinfo?(alice0775)

(In reply to Alice0775 White from comment #32)

The try build fix this issue on both Windows10 and Ubuntu18.04. No longer reproduce this problem on the try build.
Thanks for checking!

However, I can still reproduce the issue of STR comment #15 on the try build Windows10.
See screencast: https://youtu.be/9iuTf37gFng

Is that only on Windows? Also, can you please check if the regression range for the shifting issue is also bug 1576946 ? If not, it might be an unrelated bug.

Flags: needinfo?(alice0775)

(In reply to Tim Nguyen :ntim from comment #33)

(In reply to Alice0775 White from comment #32)

The try build fix this issue on both Windows10 and Ubuntu18.04. No longer reproduce this problem on the try build.
Thanks for checking!

However, I can still reproduce the issue of STR comment #15 on the try build Windows10.
See screencast: https://youtu.be/9iuTf37gFng

Is that only on Windows? Also, can you please check if the regression range for the shifting issue is also bug 1576946 ? If not, it might be an unrelated bug.,

I can also reproduce on Ubuntu18.04, when increase text size through Ubuntu Settings Utility, and turn on Large Text.

  1. Open Wikipedia
  2. Open about:preferences#privacy
  3. Focus Standard
  4. Hit down arrow key and up arrow key and repeat step4

Screencast: https://youtu.be/hjE4gg4pIek

Same regression window, See comment#15

Flags: needinfo?(alice0775)

In addition to the comment #34,
If you use the up/down arrow keys to switch protection modes,
you do not need to increase the text size to reproduce the problem.
I can reproduce with default text size on the try build Windows10 and Ubuntu18.04.
And I can confirm same regression window.

Alice0775, can you reproduce the issue with this try build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3d3da015c6b8fba26b31ac91b98146efa46745e4 ? Thanks!

Flags: needinfo?(alice0775)
Attachment #9115054 - Attachment description: Bug 1599783 - Use display: -moz-stack; for main preferences stack. → Bug 1599783 - Use display: -moz-stack; for about:preferences stacks.

(In reply to Tim Nguyen :ntim from comment #36)

Alice0775, can you reproduce the issue with this try build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3d3da015c6b8fba26b31ac91b98146efa46745e4 ? Thanks!

I can still reproduce the issue Comment 34 on the try Windows10 and Ubuntu18.04 with default text size as well as large text.

However, WAIT!, Sorry,
Your comment #33 is right!.
I can reproduce the issue before landing the offending bug 1576946.
Anyway I will file a separate bug for the issue Comment 34.

I apologize for confusing you.

Flags: needinfo?(alice0775)
Attachment #9115054 - Attachment description: Bug 1599783 - Use display: -moz-stack; for about:preferences stacks. → Bug 1599783 - Use display: -moz-stack; for about:preferences main stack.

No worries, thanks for testing and double checking! :)

Blocks: 1603599

Comment on attachment 9115053 [details]
Bug 1599783 - Backed out changeset 1a85c571a464 to be able to use display: -moz-stack.

Beta/Release Uplift Approval Request

  • User impact if declined: See comment 0
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: See comment 0
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Partial backout of a change.
  • String changes made/needed: none
Attachment #9115053 - Flags: approval-mozilla-beta?
Attachment #9115054 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Hi Julien, would it be possible to uplift those two patches only on Beta for now? I'd like to hold off landing on central at the moment given that we may be able to find a better fix (especially given the new information from bug 1603599).

Flags: needinfo?(jcristau)

Yeah I think that's ok.

Will the other regressions like bug 1601983 also need separate changes to use -moz-stack?

Flags: needinfo?(jcristau)

Comment on attachment 9115053 [details]
Bug 1599783 - Backed out changeset 1a85c571a464 to be able to use display: -moz-stack.

approved for 72.0b7

Attachment #9115053 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9115054 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

(In reply to Julien Cristau [:jcristau] from comment #41)

Yeah I think that's ok.

Thanks!

Will the other regressions like bug 1601983 also need separate changes to use -moz-stack?

Possibly if we run out of time, but emilio or jwatt is already looking into it, so it might be possible to get a proper fix uplifted.

Hi Alice0775, could you please check if the following build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=47ad3a45195a420b7d48ecd3369b6a4f4233642b fixes this bug and bug 1603599 ? Thanks for all your help so far :)

Flags: needinfo?(alice0775)

(In reply to Tim Nguyen :ntim from comment #46)

Hi Alice0775, could you please check if the following build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=47ad3a45195a420b7d48ecd3369b6a4f4233642b fixes this bug and bug 1603599 ? Thanks for all your help so far :)

No longer reproduced. The problems(this bug and bug 1603599) are fixed with the try build on Windows10 and Ubuntu18.04.

Flags: needinfo?(alice0775)

Thanks for confirming!

Pushed by ntim.bugs@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/8bd0989df6b2
Fix shifting of content blocking radiogroup when switching options. r=Gijs
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla73
QA Whiteboard: [qa-triaged]

Verified - Fixed in latest Nightly 73.0a1 (Build id: 20191215094838) and Beta build 72.0b7 (Build id: 20191213132525) using Windows 10 and Ubuntu 18.04.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Component: Layout → Preferences
Product: Core → Firefox
Target Milestone: mozilla73 → ---
Target Milestone: --- → Firefox 73
Flags: needinfo?(mats)
Regressions: 1605619
Blocks: 1605624

Wrong bug, sorry for the noise.

Please specify a root cause for this bug. See :tmaity for more information.

Root Cause: --- → ?
Root Cause: ? → Coding: Logical Error
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: