Open Bug 1590386 Opened 5 years ago Updated 1 year ago

Netmonitor Blocking - Blocking pages becomes listed in the next_accessed page causing requests list to get flushed

Categories

(DevTools :: Netmonitor, defect, P3)

71 Branch
defect

Tracking

(firefox70 unaffected, firefox71 fix-optional)

Tracking Status
firefox70 --- unaffected
firefox71 --- fix-optional

People

(Reporter: cfogel, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file)

Notes

  • noticed issue with :csasca, it presented under several variations;
  • in some cases there was only the flickering mentioned bellow, in others the list became blank instantly;

Affected versions

  • 71.0a1 (2019-10-21);

Affected platforms

  • Windows 10, macOS 10.15;

Steps to reproduce
devtools.netmonitor.features.requestBlocking set on true

  1. Launch Firefox, access https://www.facebook.com/
  2. Open Netmonitor - blocking tab;
  3. Add as blocking patterns https://www.facebook.com/
  4. Refresh page;
  5. Access any other page ex https://www.google.com/;

Expected result

  • requests remain displayed for the new page;

Actual result

  • list becomes empty;
  • beacons from address at step 1 get passed to the website from step 5 requests list;

Regression range

  • Builds up until changeset: c67e0b10b52fc8e6b17591b77fee324cac2fc38d downloaded via mozregression appear to be Ok;
  • First bad build appears to be 71.0a1 (2019-10-21);

Additional notes

  • attached recording with the issue, navigation on any other page with other filters has same effect as in it;

  • macOS has a slightly different behavior:

  • oddly enough with 10.13(the beacon is blocked & passed to the next page but the page refreshes);
  • 10.15(page requests are empty after step 4) as reported by :csasca;

Here's the attachment with the issue, on macOS 10.15.

For info devtools.netmonitor.features.requestBlocking is off by default, so no real need to fix this in Firefox 71. Updating the flags accordingly.

Seems an edge case we should investigate but that shouldn't block release, so putting as P3.

Just fyi pbro, We plan to enable the feature across all channels in bug 1580544. But since this is lowe priority, the fix-optional works

Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.