XHR breakpoint for empty path can not be removed
Categories
(DevTools :: Debugger, defect, P2)
Tracking
(firefox-esr91 wontfix, firefox100 wontfix, firefox101 wontfix, firefox102 wontfix, firefox141 fixed)
People
(Reporter: ontonator, Assigned: ochameau)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0
Steps to reproduce:
- Go to a page that can produce PUT requests
- Open the debugger and create an XHR breakpoint to break on PUT requests with a url of "*"
- Send a PUT request
- Delete the breakpoint
- Send a PUT request
Actual results:
The first PUT request (step 3) may or may not trigger the breakpoint. (The breakpoint is not created consistently, it seems, so even if it is in the list of XHR breakpoints, it does not actually work.)
The second PUT request (step 5) may or may not trigger the breakpoint. (The breakpoint is not removed consistently, it seems, so even if it is not in the list of XHR breakpoints, it still triggers. Even if the breakpoint did not trigger in step 3, it may still trigger in step 5, after it has been removed.)
If the breakpoint is not present in the list but still exists (i.e. it triggers on all PUT requests), then it persists even after restarting Firefox, and it still doesn't appear in the list.
I did manage to successfully remove it by using the Browser Toolbox to manually remove it from the list of breakpoints in the state.
Also note that I could not reproduce this with GET or POST requests, only with PUT.
Expected results:
Step 3 should always trigger the breakpoint, and step 5 should never trigger the breakpoint.
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•4 years ago
|
||
Thanks for filing.
Our XHR breakpoints do not support wildcards. I assume the Debugger happens to break on requests which actually contain a * here.
That's probably why it doesn't consistently trigger the breakpoint.
The alternative would be to use "Pause on any URL" but in that case you can't specify if you are only interested in POST/GET/PUT/...
Regarding the second issue (the fact that you still break sometimes after removing the breakpoint), can you share a specific example (testpage + action to trigger the request) where this happens? We fixed a few issues around breakpoints incorrectly persisted, so this might have been fixed recently.
So I've managed to reproduce it consistently, and I was wrong about * and it being PUT request. I never realised that * didn't work as a wildcard because I had already inadvertently triggered the bug before creating the * breakpoint.
Steps to reproduce:
- Click the + to add an XHR breakpoint.
- Select a method in the combo box other than
ANY. (It can be reproduced withANY, but just enables "Pause on any URL" instead of creating an invisible breakpoint.) - Click in the "Break when URL contains" text box.
- Hit return (without having typed anything).
Actual results:
The breakpoint disappears from the list, but is still present internally as a breakpoint with path set to an empty string. It triggers on any request with the specified method, since all requests contain the empty string, and it cannot be deleted without using the Browser Toolbox. (I deleted it by creating another breakpoint, deleting that and using that to trigger a breakpoint in removeXHRBreakpoint in resource://devtools/client/debugger/src/actions/breakpoints/index.js, changing the index of the breakpoint being removed to that of the unlisted breakpoint, then resuming).
Expected results:
Either:
- no breakpoint is created, since you can't have a breakpoint with an empty path; or
- a breakpoint is created and listed as "Pause on any <method> request" (or something similar).
Also, I reproduced it on macOS this time in Firefox 101.0b6, so I suspect it can occur on any platform with access to the developer tools. Regarding a test page, I was just using https://www.w3schools.com/xml/tryit.asp?filename=tryxml_httprequest and changing the method in the script.
Comment 4•4 years ago
|
||
Thank you so much for the detailed steps to reproduce!
For a clean profile, to reproduce the bug 100% of the time I need to do 2 additional steps, see below.
- open devtools > debugger
- expand XHR breakpoints
- check "Pause on any URL"
- uncheck "Pause on any URL" (after that, back to your steps)
- click the + to add an XHR breakpoint
- Select a method in the combo box other than ANY. (It can be reproduced with ANY, but just enables "Pause on any URL" instead of creating an invisible breakpoint.)
- Click in the "Break when URL contains" text box.
- Hit return (without having typed anything).
If I don't do the check/uncheck, then after the "Hit return" step, the "Pause on any URL" checkbox becomes automatically checked, meaning I can recover and delete that breakpoint.
In any case, that's super helpful and we should try to fix this as soon as possible, because it creates breakpoints you can't recover from.
Not sure if those steps should consistently check "Pause on any URL" (as it seems to do sometimes) or if it should create a real breakpoint, or if it should simply be prevented.
When inspecting the stored XHR breakpoints afterwards I get the following:
[
{"path":"","method":"ANY","disabled":true,"loading":false,"text":"URL contains “”"},
{"path":"","method":"GET","disabled":false,"loading":false,"text":"URL contains “”"}
]
So I guess that in order to trigger the bug, we first need to at least have the "ANY" item added, even if it has "disable: true"
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 5•4 years ago
|
||
Adding some inital thoughts after doing some quick investigation here (so not forgotten)
- When the user does not specify a path in the text area, while having ANY selected, this means that it should "Pause on any URL" so the check box for that is selected, this is OK.
- If the user does not specify a path in the text area, while having any other Http Method (e.g GET) selected, this should mean that it should "Pause on any GET URL" (the same for all the other HTTP methods specified). But we do not handle this scenario, so the breakpoint with the empty path does not show up.
Maybe we can have placeholder text for breakpoints with empty paths where ANY is not selected which can be "Pause on any <HTTP METHOD> URL"?
Comment 6•4 years ago
|
||
The severity field is not set for this bug.
:bomsy, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
| Assignee | ||
Comment 7•1 year ago
|
||
Updated•1 year ago
|
Updated•11 months ago
|
Updated•11 months ago
|
Description
•