Closed Bug 1588706 Opened 5 years ago Closed 4 years ago

The hierarchy from the specs are not respected when the doorhangers are displayed.

Categories

(Firefox :: Protections UI, defect)

71 Branch
defect
Not set
blocker

Tracking

()

VERIFIED FIXED
Firefox 72
Tracking Status
firefox-esr60 --- disabled
firefox-esr68 --- disabled
firefox69 --- disabled
firefox70 --- disabled
firefox71 --- wontfix
firefox72 --- fixed
firefox85 --- verified
firefox86 --- verified

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

  1. Start Firefox with a clean profile.
  2. Open this site in 4 different tabs.

Expected result

  • The Cryptominers doorhanger is triggered.

Actual result

  • The Fingerprinters doorhanger is triggered.

Regression range

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.

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?

Flags: needinfo?(xeonchen)
Assignee: nobody → xeonchen
Status: NEW → ASSIGNED
Flags: needinfo?(xeonchen)

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.

Depends on: 1590442
Pushed by xeonchen@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/9fbcda0c9722
merge content blocking events and set doorhanger priority; r=johannh
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 72

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.
Flags: needinfo?(xeonchen)

(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?

Flags: needinfo?(xeonchen) → needinfo?(oana.botisan)

To clarify I will write some STR:

  1. Open a new tab.
  2. Drag and drop the link in the url bar.
  3. Repeat step 1 and 2 three more times.

or

  1. Drag and drop the link in browser.
  2. Click on the tab that the link is loaded on.
  3. 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.

Flags: needinfo?(oana.botisan)

OK, it's weird that the config value on remote-settings doesn't contain the priority value.
Need further check.

Flags: needinfo?(xeonchen)

The settings are updated, would you please verify again? Thanks!

Flags: needinfo?(xeonchen) → needinfo?(oana.botisan)

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.

Flags: needinfo?(oana.botisan) → needinfo?(xeonchen)

(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?

Flags: needinfo?(xeonchen)

The bug happens pretty frequent. On my station is reproducing more often than not. I would say that is quite important.

(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

Flags: needinfo?(xeonchen)

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

Flags: needinfo?(xeonchen) → needinfo?(oana.botisan)

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.

Flags: needinfo?(oana.botisan) → needinfo?(xeonchen)

(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?

Flags: needinfo?(xeonchen) → needinfo?(epang)

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!

Flags: needinfo?(epang)

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.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.