The hierarchy from the specs are not respected when the doorhangers are displayed.
Categories
(Firefox :: Protections UI, defect)
Tracking
()
People
(Reporter: obotisan, Assigned: xeonchen)
References
Details
Attachments
(1 file)
Affected versions
- Firefox 71.0a1
Affected platforms
- Windows 10 x64
- Ubuntu 18.04 x64
- macOS 10.14
Steps to reproduce
- Start Firefox with a clean profile.
- Open this site in 4 different tabs.
Expected result
- The Cryptominers doorhanger is triggered.
Actual result
- The Fingerprinters doorhanger is triggered.
Regression range
- This is not a regression. I can reproduce the issue on Nightly from 2019-09-11 when the feature was implemented.
- You can check the hierarchy by following this site: https://mozilla.invisionapp.com/share/R5S6LMLZ26A#/screens/374869580
Additional notes
- On a site the order in which the doorhangers are displayed is the one from the Privacy Panel. In this case, the first on the list are Fingerprinters, so the doorhanger displayed is for Fingerprinters.
Reporter | ||
Comment 1•5 years ago
•
|
||
Hi, Gary. We consider this bug as a blocker for this feature. Can you please take a look at it as soon as you have time?
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
cfr doorhangers supports priority field, but it doen't work if we receive content blocking event separtely.
Therefore we should fire an event contains all events and let cfr priority decides the order.
Pushed by xeonchen@gmail.com: https://hg.mozilla.org/integration/autoland/rev/9fbcda0c9722 merge content blocking events and set doorhanger priority; r=johannh
Comment 4•4 years ago
|
||
bugherder |
Reporter | ||
Comment 5•4 years ago
|
||
I verified the fix using latest Nightly 72.0a1 on Windows 10 x64 and got three different results:
- If I copied and paste the link in the URL bar -> the bug is not reproducing.
- If I open a new tab and in each tab I dragged and drop the link -> the issue is still reproducing.
- If I dragged and dropped the link in the browser 4 times and then opened the tab -> the issue is not reproducing.
Reporter | ||
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
(In reply to Oana Botisan, Desktop Release QA from comment #5)
I verified the fix using latest Nightly 72.0a1 on Windows 10 x64 and got three different results:
- If I open a new tab and in each tab I dragged and drop the link -> the issue is still reproducing.
Could you tell me more about the steps? I don't quite understand how to reproduce this.
You opened only a new tab? And "still producing " means it shows the fingerprinters one?
Reporter | ||
Comment 7•4 years ago
|
||
To clarify I will write some STR:
- Open a new tab.
- Drag and drop the link in the url bar.
- Repeat step 1 and 2 three more times.
or
- Drag and drop the link in browser.
- Click on the tab that the link is loaded on.
- Repeat steps 1 and 2, three more times.
And yes... the issue that is reproducing is that the fingerprinter doorhanger is the one that is displayed.
I hope this info helps more.
Assignee | ||
Comment 8•4 years ago
|
||
OK, it's weird that the config value on remote-settings doesn't contain the priority value.
Need further check.
Assignee | ||
Comment 9•4 years ago
|
||
The settings are updated, would you please verify again? Thanks!
Reporter | ||
Comment 10•4 years ago
|
||
I tried in two different days, just so I am sure about the answer.
If I follow the steps from comment 7 the issue is not reproducing.
However, when I use the copy/paste (using the mouse or keyboards) method sometimes the issue is still reproducing. I think it's intermittent, but pretty frequent. This issue I managed to reproduce only on Windows 10 and Ubuntu. macOS doesn't seem affected.
Assignee | ||
Comment 11•4 years ago
•
|
||
(In reply to Oana Botisan, Desktop Release QA from comment #10)
I tried in two different days, just so I am sure about the answer.
If I follow the steps from comment 7 the issue is not reproducing.
Thanks for confirming this.
However, when I use the copy/paste (using the mouse or keyboards) method sometimes the issue is still reproducing. I think it's intermittent, but pretty frequent. This issue I managed to reproduce only on Windows 10 and Ubuntu. macOS doesn't seem affected.
This part is mysterious, but I don't think this intermittent failure is very important, right?
Reporter | ||
Comment 12•4 years ago
|
||
The bug happens pretty frequent. On my station is reproducing more often than not. I would say that is quite important.
Comment 13•4 years ago
|
||
(In reply to Oana Botisan, Desktop Release QA from comment #12)
The bug happens pretty frequent. On my station is reproducing more often than not. I would say that is quite important.
Gary,
Could you please connect with Oana, we're still able to reproduce this and doesn't look like its FIXED
Assignee | ||
Comment 14•4 years ago
|
||
(In reply to Tania Maity (:tmaity) from comment #13)
(In reply to Oana Botisan, Desktop Release QA from comment #12)
The bug happens pretty frequent. On my station is reproducing more often than not. I would say that is quite important.
Gary,
Could you please connect with Oana, we're still able to reproduce this and doesn't look like its FIXED
Just trying to reproduce this on my Linux platform, it does happen.
The patch landed in this bug is trying to collect tracking events and keep them until the page is loaded.
After page is loaded, we don't keep any event but notify directly.
In this case where Linux is reproducible because the tracking events are received AFTER the page is loaded, therefore we don't have any possibility to fix under this scenario unless our anti-tracking backend changes the order, which is impossible because they can't (and should not) read any information about the priority of doorhangers.
I'd say this is a WONTFIX situation, and we can have more discussion if you think this is improper. Thanks.
Reporter | ||
Comment 15•4 years ago
|
||
Thanks for the explanations, Gary!
I’m afraid that there’s not much I can do from a QA perspective other than file an enhancement for the remaining scenario, if you think that there’s a change in the future to fix this.
Some of the questions I cannot answer are how important is for Product to respect the provided specs regarding the hierarchy, or if the RelMan is OK with shipping this feature in 71 as it is.
Assignee | ||
Comment 16•4 years ago
|
||
(In reply to Oana Botisan, Desktop Release QA from comment #15)
Thanks for the explanations, Gary!
I’m afraid that there’s not much I can do from a QA perspective other than file an enhancement for the remaining scenario, if you think that there’s a change in the future to fix this.
Some of the questions I cannot answer are how important is for Product to respect the provided specs regarding the hierarchy, or if the RelMan is OK with shipping this feature in 71 as it is.
Hi Eric, can you help check this?
Comment 17•4 years ago
|
||
If there isn't a clear solution to this I'm okay with leaving as is and showing the fingerprinter notification before the cryptomining notification. We can mark as WONTFIX. Thanks Gary for checking in!
Updated•4 years ago
|
Reporter | ||
Comment 18•3 years ago
|
||
Verified the fix using latest Nightly 86.0a1 and Firefox 85.0b1 on Windows 10 x64, Ubuntu 18.04 x64 and macOS 10.13. The issue is not reproducing anymore.
Description
•