Drop-down displayed in wrong position from Privacy & Security -> Enhanced Tracking Protection
Categories
(Firefox :: Settings UI, defect, P2)
Tracking
()
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)
1.47 MB,
video/mp4
|
Details | |
480.30 KB,
video/mp4
|
Details | |
78.45 KB,
image/png
|
Details | |
87.20 KB,
image/png
|
Details | |
47 bytes,
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details | Review |
47 bytes,
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details | Review |
47 bytes,
text/x-phabricator-request
|
Details | Review |
Affected versions:
Nightly 72.0a1 (2019-11-27).
Affected platforms:
Windows 7, Windows 10.
Steps:
- Launch Firefox with a clean profile.
- Access the "about:preferences#privacy" page.
- From the Enhanced Tracking Protection section, click on the "Strict" radio button, then on the "Custom radio button".
- 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.
Reporter | ||
Comment 1•4 years ago
|
||
Comment 2•4 years ago
|
||
This is a pretty awful user experience. We should find the regressor ASAP.
Reporter | ||
Comment 3•4 years ago
|
||
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.
Comment 4•4 years ago
|
||
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).
Comment 6•4 years ago
•
|
||
The problem happens only in the case when "Reload All Tabs" pane is indicated. See attached screenshot.
STR.
- Open any page e.g https://www.wikipedia.org/
- Open about:preferences#privacy
- Switch to "Standard" if not standard. and then switch to "Strict"
- Switch to "Custom"
--- make sure "Reload All Tabs" pane is indicated. If not, reload the webpage of step 1 and goto step3 - Click one dropdown list
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5e6b050c9427da9ae37ca4c7c8000ba5b47ceea8&tochange=1a85c571a4645798ba4d9295ba2504acac149ac8
Updated•4 years ago
|
Comment 7•4 years ago
|
||
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?
Comment 8•4 years ago
|
||
[Tracking Requested - why for this release]:
Shouldn't ship with this.
Comment 9•4 years ago
|
||
It does not happen if clicking slowly on the dropdown(i.e mousedown -> wait a moment -> mouseup).
Comment 10•4 years ago
|
||
I am able to reproduce this with the steps outlined by Alice in comment #6.
Assignee | ||
Comment 11•4 years ago
|
||
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 ?
Comment 12•4 years ago
|
||
(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....
Assignee | ||
Comment 13•4 years ago
|
||
(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).
Assignee | ||
Comment 14•4 years ago
|
||
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 :)
Comment 15•4 years ago
•
|
||
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)
Comment 16•4 years ago
|
||
And I can also reproduce these issue on Nightly72.0a1 Ubuntu18.04
Comment 17•4 years ago
|
||
(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=7f0c4f0102edd48bc237131db31c91469b27efe0They 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)
Updated•4 years ago
|
Updated•4 years ago
|
Comment 18•4 years ago
|
||
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.)
Assignee | ||
Comment 19•4 years ago
|
||
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 ?
Comment 20•4 years ago
|
||
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)
Comment 21•4 years ago
|
||
(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)
Reporter | ||
Comment 22•4 years ago
|
||
I can also still reproduce the issue on latest Nightly (Build id: 20191208213628) using win 10.
Comment 23•4 years ago
|
||
This is ultimately not a frontend bug, so moving to layout to ensure this gets the appropriate triage attention.
Comment 24•4 years ago
|
||
Can people reproduce it on Linux? I don't seem to be able to repro here.
Updated•4 years ago
|
Comment 25•4 years ago
•
|
||
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
Comment 26•4 years ago
|
||
(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.
Assignee | ||
Comment 27•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 28•4 years ago
|
||
Depends on D56658
Comment hidden (obsolete) |
Assignee | ||
Comment 30•4 years ago
|
||
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
Assignee | ||
Comment 31•4 years ago
|
||
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!
Comment 32•4 years ago
|
||
(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
Assignee | ||
Comment 33•4 years ago
|
||
(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.
Comment 34•4 years ago
|
||
(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/9iuTf37gFngIs 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.
- Open Wikipedia
- Open about:preferences#privacy
- Focus Standard
- Hit down arrow key and up arrow key and repeat step4
Screencast: https://youtu.be/hjE4gg4pIek
Same regression window, See comment#15
Comment 35•4 years ago
|
||
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.
Assignee | ||
Comment 36•4 years ago
|
||
Alice0775, can you reproduce the issue with this try build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3d3da015c6b8fba26b31ac91b98146efa46745e4 ? Thanks!
Updated•4 years ago
|
Comment 37•4 years ago
|
||
(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.
Updated•4 years ago
|
Assignee | ||
Comment 38•4 years ago
|
||
No worries, thanks for testing and double checking! :)
Assignee | ||
Comment 39•4 years ago
|
||
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
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 40•4 years ago
|
||
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).
Comment 41•4 years ago
|
||
Yeah I think that's ok.
Will the other regressions like bug 1601983 also need separate changes to use -moz-stack?
Comment 42•4 years ago
|
||
Comment on attachment 9115053 [details]
Bug 1599783 - Backed out changeset 1a85c571a464 to be able to use display: -moz-stack.
approved for 72.0b7
Updated•4 years ago
|
Assignee | ||
Comment 43•4 years ago
•
|
||
(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.
Comment 44•4 years ago
|
||
bugherder uplift |
Assignee | ||
Comment 45•4 years ago
|
||
Assignee | ||
Comment 46•4 years ago
|
||
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 :)
Comment 47•4 years ago
|
||
(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.
Assignee | ||
Comment 48•4 years ago
|
||
Thanks for confirming!
Comment 49•4 years ago
|
||
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
Comment 50•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Reporter | ||
Comment 51•4 years ago
|
||
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.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Comment 53•4 years ago
|
||
Please specify a root cause for this bug. See :tmaity for more information.
Updated•4 years ago
|
Updated•2 years ago
|
Description
•