Open Bug 1724864 Opened 3 years ago Updated 3 years ago

Feature to ignore the URL parameters when setting breakpoints

Categories

(DevTools :: Debugger, enhancement)

Firefox 92
enhancement

Tracking

(Not tracked)

People

(Reporter: karlcow, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

I was in the process of diagnosing https://github.com/webcompat/web-bugs/issues/82605

There is a dependency in the code on this URL
https://s.yimg.jp/images/yvpub/player/js/player.js
but the URL comes with a parameter.

https://s.yimg.jp/images/yvpub/player/js/player.js?v=1628578063801
https://s.yimg.jp/images/yvpub/player/js/player.js?v=1628578616434
https://s.yimg.jp/images/yvpub/player/js/player.js?v=1628578698956

Basically the parameter is an epoch time in milliseconds. It is incremented at each individual request.

  1. Set a breakpoint in a similar document with a changing URL because of parameters
  2. Reload the page

Actual:
Breakpoint is lost

Expected:
Breakpoint is triggered.

So this one is tricky because, sometimes the parameters are meaningful. But in this case it is not.

So probably it would be cool to have a preference to make it possible to either:

  • ignore the parameter
  • use a cached copy of the script (see Bug 1014940 )

Maybe another way to be able to work around this would be able to call the debugger for a specific URI pattern.

So if we could set things like this:

if (document.currentScript.src.includes('player.js') {
    debugger;
}

and then do a reload

Attached image image.png (deleted) —

The debugger is allowing to "Break when URL contains" specific keyword. See the attached screenshot. Is this what are you looking for?

Also note that in order to break on URL, it needs to be triggered from JS (i.e. there must be JS stack frames to show)

Honza

Flags: needinfo?(kdubost)

In this specific case the URL is generated dynamically inside the HTML

<script src="https://s.yimg.jp/images/yvpub/player/js/player.js?v=1629082577165"></script>

So this would not work as it is not an XHR request.

The network panel has a blocking request feature on keywords too, but that would block the request and not stop the execution at the loading stage.

Flags: needinfo?(kdubost)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: