Closed Bug 1596089 Opened 5 years ago Closed 5 years ago

Blocking a request from the context menu should enable the URL/pattern if it's already in the list

Categories

(DevTools :: Netmonitor, defect, P3)

defect

Tracking

(firefox71 wontfix, firefox72 wontfix, firefox77 verified)

VERIFIED FIXED
Firefox 77
Tracking Status
firefox71 --- wontfix
firefox72 --- wontfix
firefox77 --- verified

People

(Reporter: cfogel, Assigned: davidwalsh)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Attached image netmonitor_subdomainBlocking.gif (deleted) —

Affected versions

  • 71.0b9, 72.0a1 (2019-11-12)

Affected platforms

  • Windows 10, macOS 10.15, Ubuntu 18.04;

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

  1. Launch Firefox, enable DevTools - Netmonitor - Blocking tab;
  2. Access https://twitter.com/
  3. Right Click and block the GET method for the html document (1st in the list);
  4. Right Click and block the POST metod (2nd from the list);
  5. Refresh the page;
  6. Unblock the request at step 4;
  7. Refresh the page.

Expected result

  • Request is unblocked;

Actual result

  • 1st request status does not get updated anymore;

Regression range

  • page refresh should reset-show the blocking status which is not being updated;
  • not a regression, issue encountered on nightly build from 2019-04-21 date as well (1151368 - initial implementation of feature)

Additional notes

  • attached recording with the issue.
Summary: Unblocking requests from subdomain paths breaks and doesn't allow the update the blocking status from the context menus → Unblocking requests from sub-paths breaks and doesn't allow the update the blocking status from the context menus

Just to make sure I understand the report.

Are the following STRs showing the same issue?

  1. Launch Firefox, enable DevTools - Netmonitor - Blocking tab;
  2. Access https://twitter.com/
  3. Right Click and block the GET method for the html document (1st in the list);
  4. Uncheck the checkbox of the create entry in the Blocking panel
  5. Right Click and block the GET method for the html document again. Nothing happens in the Blocking side panel -> BUG

Honza

Flags: needinfo?(cristian.fogel)

No, the ones you've noted are not causing any issue. The behavior there would be pretty much expected with the current implementation.
What jumped to eye, was the fact that after the whole block/unblock scenario; the page refresh did not appear to reset the status of the 1st request keeping it as is.

However, really good point there.
In an attempt to reproduce it with your STR, I've noticed that adding a refresh between the block/uncheck causes the issue to manifest again.
The summary might need to be adjusted as well or it might be another issue, this part might need confirmation from you as well.

So, the STR for your scenario would be:

  1. Launch Firefox, enable DevTools - Netmonitor - Blocking tab;
  2. Access https://twitter.com/
  3. Right Click and block the GET method for the html document (1st in the list);
  4. Refresh the page;
  5. Uncheck the checkbox of the create entry in the Blocking panel
  6. Right Click and block the GET method for the html document again. Nothing happens in the Blocking side panel -> BUG
Flags: needinfo?(cristian.fogel)

From offline discussion, the STRs for this bug report are in comment #1

Honza

Summary: Unblocking requests from sub-paths breaks and doesn't allow the update the blocking status from the context menus → Bocking a request from the context menu should enable the URL/pattern if it's already in the list
Summary: Bocking a request from the context menu should enable the URL/pattern if it's already in the list → Blocking a request from the context menu should enable the URL/pattern if it's already in the list
Assignee: nobody → dwalsh
Status: NEW → ASSIGNED
Pushed by dwalsh@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/460e55d9860f Re-enable blocked items when the user blocks them from the context menu r=Honza
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 77

Fix verified with 77.0b2.

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

Attachment

General

Created:
Updated:
Size: