1594749 - Requests blocking - Blocked elements get reset if internal about: pages are accessed

Status: NEW

(DevTools :: Netmonitor, defect, P3)

Description

[Cristian Fogel [:cfogel]]

Attachment: netblocking_resetonAboutS.gif

Affected versions

• 68.2.0esr, 70.0.1, 71.0b7, 2.0a1 (2019-11-06)

Affected platforms

• Windows 10, macOS 10.13, Ubuntu 18.04.

Steps to reproduce

1. Launch Firefox, enable DevTools - Netmonitor;
2. Access any page and block any request, add blocking patterns;
3. Access any of the pages listed in about:about;
4. Return to the previous page

Expected result

• requests are still blocked;

Actual result

• requests are not blocked, patterns are not kept anymore;

Enhancement suggestion
With the current Request blocking panel:

• request blocking can be disabled on the about: pages and get re-enabled when returning to the previous page;
• a "hard disable" without the possibility for the user to toggle the Enable checkbox;

Regression range

• not a regression;
• appeared with implementation of feature - pushlog URL;

Additional notes

• attached recording with the main issue.

Comment 2

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thanks for the report!

Honza

Comment 3

[Julian Descottes [:jdescottes]]

about: pages often live in the parent process while regular web pages run in content processes.
By default devtools will close and reopen, unless you have target switching enabled (devtools.target-switching.enabled).

Since the blocked URLs seem to be erased when closing the toolbox, there won't be an easy fix for this.

Honza: I quickly looked at the bugs linked to https://bugzilla.mozilla.org/show_bug.cgi?id=1583111 but I didn't see anything about storing the blocked patterns. Is it intentional that they are removed when closing the toolbox? If that's the case I think we should block this on https://bugzilla.mozilla.org/show_bug.cgi?id=1592575

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Julian Descottes [:jdescottes] from comment #3)

about: pages often live in the parent process while regular web pages run in content processes.
By default devtools will close and reopen, unless you have target switching enabled (devtools.target-switching.enabled).
Since the blocked URLs seem to be erased when closing the toolbox, there won't be an easy fix for this.

Ah, I see. Thanks for the analysis Julian!

Honza: I quickly looked at the bugs linked to https://bugzilla.mozilla.org/show_bug.cgi?id=1583111 but I didn't see anything about storing the blocked patterns. Is it intentional that they are removed when closing the toolbox?

Yes, that's intentional

If that's the case I think we should block this on https://bugzilla.mozilla.org/show_bug.cgi?id=1592575

Agreed & done.

Honza

Comment 5

[Alexandre Poirot [:ochameau]]

bomsy, I still reproduce this issue. It sounds like request blocking fails to reapply when navigating between two processes.
Here this bug is when navigating to about: pages, like about:robots which loads in the parent process.
But I also reproduce with fission enabled and navigating between two distinct origins.

Is that a duplicate of another existing bug?