Open Bug 1594749 Opened 4 years ago Updated 1 year ago

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

Categories

(DevTools :: Netmonitor, defect, P3)

defect

Tracking

(firefox-esr68 affected, firefox70 affected, firefox71 affected, firefox72 affected)

Tracking Status
firefox-esr68 --- affected
firefox70 --- affected
firefox71 --- affected
firefox72 --- affected

People

(Reporter: cfogel, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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.

Thanks for the report!

Honza

Priority: -- → P3

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

Flags: needinfo?(odvarko)

(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

Depends on: 1592575
Flags: needinfo?(odvarko)

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?

Blocks: dt-fission-network-monitor
No longer blocks: 1583111
Flags: needinfo?(hmanilla)
Flags: needinfo?(hmanilla)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.