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

Status: NEW

(DevTools :: Netmonitor, defect, P3)

Description

[Cristian Fogel [:cfogel]]

Attachment: netblocking_ListClearAfterBlockNSearch.gif

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;

Comment 1

[Catalin Sasca, Desktop Test Engineering [:csasca]]

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

Comment 2

[Patrick Brosset <:pbro>]

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

Comment 3

[:Harald Kirschner :digitarald]

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