1915026 - Add the ability break on location changes

Status: NEW

(DevTools :: Debugger, enhancement, P3)

Description

[Jeff Muizelaar [:jrmuizel]]

It would be helpful when debugging webcompat issues to be able to break when window.location is modified.

For example, https://app.clipchamp.com/login will redirect to https://clipchamp.com/en/unsupported-browser/ even why I try to spoof the Chrome user agent. I'd like to be able to see and debug the code that's doing the browser detection.

Comment 1

[Alexandre Poirot [:ochameau]]

The redirect is being done by https://app.clipchamp.com/browser-guard.972b3c6845906f5d0868.js

Thanks to the JS Tracer, you can easily see that the https://app.clipchamp.com/login parse the Browser UA:

————————[interpreter]—> ^[]8;;https://app.clipchamp.com/browser-guard.972b3c6845906f5d0868.js:1:6343^[\https://app.clipchamp.com/browser-guard.972b3c6845906f5d0868.js:1:6343^[]8;;^[\ - λ 643/90/e.getParser
—————————[interpreter]—> ^[]8;;https://app.clipchamp.com/browser-guard.972b3c6845906f5d0868.js:1:7013^[\https://app.clipchamp.com/browser-guard.972b3c6845906f5d0868.js:1:7013^[]8;;^[\ - λ e
——————————[interpreter]—> ^[]8;;https://app.clipchamp.com/browser-guard.972b3c6845906f5d0868.js:1:9760^[\https://app.clipchamp.com/browser-guard.972b3c6845906f5d0868.js:1:9760^[]8;;^[\ - λ 643/91/t.parse
———————————[interpreter]—> ^[]8;;https://app.clipchamp.com/browser-guard.972b3c6845906f5d0868.js:1:7292^[\https://app.clipchamp.com/browser-guard.972b3c6845906f5d0868.js:1:7292^[]8;;^[\ - λ 643/91/t.parseBrowser
————————————[interpreter]—> ^[]8;;https://app.clipchamp.com/browser-guard.972b3c6845906f5d0868.js:1:3212^[\https://app.clipchamp.com/browser-guard.972b3c6845906f5d0868.js:1:3212^[]8;;^[\ - λ 643/17/e.find
—————————————[interpreter]—> ^[]8;;https://app.clipchamp.com/browser-guard.972b3c6845906f5d0868.js:1:7373^[\https://app.clipchamp.com/browser-guard.972b3c6845906f5d0868.js:1:7373^[]8;;^[\ - λ 643/91/t.parseBrowser/t<
——————————————[interpreter]—> ^[]8;;https://app.clipchamp.com/browser-guard.972b3c6845906f5d0868.js:1:7475^[\https://app.clipchamp.com/browser-guard.972b3c6845906f5d0868.js:1:7475^[]8;;^[\ - λ 643/91/t.parseBrowser/t</<

But you have to use the stdout output.
The Debugger Sidebar output doesn't work across navigations. It only works against the current WindowGlobal/document. Some specific work would be required to be able to see multiple WindowGlobal traces.
Similar limitation also applies to the profiler output, but bug 1911021 may help improve this.

Otherwise the DOM Event breakpoints are brittle.
I see that it would be able to catch pagehide (but we don't surface it in the UI),
but the native code related to event breakpoints doesn't convey the beforeunload, readystatechange and unload events.
It could be a way to pause just before the location changes... but DOM Event breakpoints break in the first DOM Event listener.
It means that if there is no listener, it wouldn't break, and it wouldn't help highlight the code triggering the event.
I'm wondering if we could have an option for DOM Event breakpoints to try to break in possible JS causing a DOM event to be fired.
Sounds complex, but we might be able to do something by rewinding the current paused stack. If the JS code triggering the event is still on the stack.

For now, we don't have any platform mechanism in place to implement such breakpoint.
The DOM Event breakpoints are typically used like this to flag some JS code about to be called with an event name.
This doesn't seem to be a pattern we could use here.

Last but not least, the Tracer should also record calls to DOM methods (here, location.href setter) which should help track many similary WebCompat issues. To me, it sounds like a much more versatile option, which wouldn't require having to put some manual hooking code here and there to track a few key native methods. We would rather work on the Tracer UI in order to be able to efficiently show, filter and find the relevant instructions.

Comment 2

[Julian Descottes [:jdescottes]]

We should file a bug to break on pagehide, but it might not directly help you find the plce where location is updated.
In the meantime, the best is to use the tracer with either stdout or console output to identify where the webpage is modifying location, and then break on this.

Watchpoints could also be a way to achieve this, but the feature is in a weird state.
Nicolas, can you check the status of the feature and check if it would help here?