962491 - Add ability to freeze the state of an element with in Developer Tools

Status: NEW

(DevTools :: Inspector, enhancement, P3)

Description

[Mike Low]

Currently the dev tools inspector lets you lock the :hover, :active and :link pseudo-classes for a selected element. This is great, but it would be really useful to also be able to do the same kind of thing for the JS events mouseover, mousedown, mouseup, touchstart, touchend etc too. 

CSS styling is often changed by these events, and at the moment there's no easy way of debugging them that I'm aware of.

Comment 1

[Brian Grinstead [:bgrins]]

(In reply to Mike from comment #0)
> Currently the dev tools inspector lets you lock the :hover, :active and
> :link pseudo-classes for a selected element. This is great, but it would be
> really useful to also be able to do the same kind of thing for the JS events
> mouseover, mousedown, mouseup, touchstart, touchend etc too. 
> 
> CSS styling is often changed by these events, and at the moment there's no
> easy way of debugging them that I'm aware of.

The tricky part is when the styling is being changed by a JS handler there isn't an easy state to reference or lock on to, as we have with the pseudo classes.  If I understand correctly, you are talking about adding a way to trigger a JS event from the tools so that the changesin the DOM as a result of the change can be observed.  Can you clarify a bit what this could provide over just triggering the events through the normal mechanism (mousing over, clicking on it, etc)?

Comment 2

[Mike Low]

Thanks for responding :) It's not so much triggering the events, but being able to lock the styles changed by the event the same way you can with CSS pseudo-classes that would be useful.

I put an example at http://jsfiddle.net/Lp7zk/1/ . With the CSS one, you can lock hover and debug from there. With the JS one, you can manually trigger the event but as soon as you mouseout from the element the style disappears which makes any debugging hard. Dropdown menus frequently are built this way, so I think it's quite a common use case. What I'm hoping for is a e.g. "lock mouseover" option when selecting a node which will make debugging this easier.

Comment 3

[Brian Grinstead [:bgrins]]

(In reply to Mike from comment #2)
> Thanks for responding :) It's not so much triggering the events, but being
> able to lock the styles changed by the event the same way you can with CSS
> pseudo-classes that would be useful.
> 
> I put an example at http://jsfiddle.net/Lp7zk/1/ . With the CSS one, you can
> lock hover and debug from there. With the JS one, you can manually trigger
> the event but as soon as you mouseout from the element the style disappears
> which makes any debugging hard. Dropdown menus frequently are built this
> way, so I think it's quite a common use case. What I'm hoping for is a e.g.
> "lock mouseover" option when selecting a node which will make debugging this
> easier.

Yeah, I feel your pain - I've often had to go in and modify scripts to not remove classes on mouseout, remove a conditional in some callback, etc in order to get things in the state just as I want them to for inspection.  In your case you could always use the markup view to force things how you want them (add the 'hover' class to the js element, or whatever), but I know that doesn't solve the more complicated problem.

To take just the mouseover / mouseout example, what could tooling provide to make this easier?  Suppose there was an item on the dropdown to force a mouseover.  I can think of a bunch of weird cases that could happen in this case -  what would the coords on the mouse event come through as?  What if you move your mouse up into the rest of the page content, would a mouseout have to fire immediately on the element as it entered a different element?  What if the process of getting to your state is more complicated than firing single event, etc.

This does get me thinking though, it would be interesting if there was some keyboard shortcut to 'freeze' the DOM from receiving any more events, kind of like taking a screenshot.  Then you could go through whatever your arbitrary steps that are needed to get to the state you want to inspect, freeze it, and do your inspection.

Comment 4

[Mike Low]

I hadn't thought of that, but now you mention it I like the idea of being able to 'freeze' the DOM and lock-in the current state for inspection. It would seem to have less potential for weird edge cases too. If that's possible, I think it would be a good solution to this problem.

Comment 5

[Joe Walker [:jwalker]]

(In reply to Brian Grinstead [:bgrins] from comment #3)
> ...
> This does get me thinking though, it would be interesting if there was some
> keyboard shortcut to 'freeze' the DOM from receiving any more events, kind
> of like taking a screenshot.  Then you could go through whatever your
> arbitrary steps that are needed to get to the state you want to inspect,
> freeze it, and do your inspection.

If you hit a breakpoint then I think you're roughly in this state. I don't see CSS 'events' like :hover happening while debugging.

Comment 6

[Brian Grinstead [:bgrins]]

(In reply to Joe Walker [:jwalker] from comment #5)
> (In reply to Brian Grinstead [:bgrins] from comment #3)
> > ...
> > This does get me thinking though, it would be interesting if there was some
> > keyboard shortcut to 'freeze' the DOM from receiving any more events, kind
> > of like taking a screenshot.  Then you could go through whatever your
> > arbitrary steps that are needed to get to the state you want to inspect,
> > freeze it, and do your inspection.
> 
> If you hit a breakpoint then I think you're roughly in this state. I don't
> see CSS 'events' like :hover happening while debugging.

Good point.  I noticed on the demo page: http://fiddle.jshell.net/Lp7zk/1/show/, that if I open inspector tab then debugger tab, hover the mouse over the JS Mouseover object, press F8 to pause, then press ctrl+shift+c to flip to inspector, it *almost* gets into the desired state, but for some reason the mouseout event still fires as the mouse leaves.  Subsequent mouseover/out don't fire, just the first one.

The only other issue with being paused is that 'click to select' highlighter selection doesn't work, so getting to the DOM node you care about in the markup view could be a bit of work, but it would at least be possible.

Comment 7

[Mike Low]

(In reply to Brian Grinstead [:bgrins] from comment #6)
> 
> Good point.  I noticed on the demo page:
> http://fiddle.jshell.net/Lp7zk/1/show/, that if I open inspector tab then
> debugger tab, hover the mouse over the JS Mouseover object, press F8 to
> pause, then press ctrl+shift+c to flip to inspector, it *almost* gets into
> the desired state, but for some reason the mouseout event still fires as the
> mouse leaves.  Subsequent mouseover/out don't fire, just the first one.
> 
> The only other issue with being paused is that 'click to select' highlighter
> selection doesn't work, so getting to the DOM node you care about in the
> markup view could be a bit of work, but it would at least be possible.

Also it can take work to find where to put a breakpoint, especially if you're debugging a large codebase you didn't write. Locking CSS pseudoclasses is substantially easier by comparison, and it would nice if there was a solution for this that works in a similarly easy fashion (e.g. keyboard shortcut/right-click menu option on the relevant node.)

Comment 8

[Brian Grinstead [:bgrins]]

(In reply to Mike from comment #7)
> (In reply to Brian Grinstead [:bgrins] from comment #6)
> > 
> > Good point.  I noticed on the demo page:
> > http://fiddle.jshell.net/Lp7zk/1/show/, that if I open inspector tab then
> > debugger tab, hover the mouse over the JS Mouseover object, press F8 to
> > pause, then press ctrl+shift+c to flip to inspector, it *almost* gets into
> > the desired state, but for some reason the mouseout event still fires as the
> > mouse leaves.  Subsequent mouseover/out don't fire, just the first one.
> > 
> > The only other issue with being paused is that 'click to select' highlighter
> > selection doesn't work, so getting to the DOM node you care about in the
> > markup view could be a bit of work, but it would at least be possible.
> 
> Also it can take work to find where to put a breakpoint, especially if
> you're debugging a large codebase you didn't write. Locking CSS
> pseudoclasses is substantially easier by comparison, and it would nice if
> there was a solution for this that works in a similarly easy fashion (e.g.
> keyboard shortcut/right-click menu option on the relevant node.)

Yes, I would imagine that we could wire up F8 to pause the debugger even when on the inspector tab.  In this case it would be possible to have a button to allow resuming either overlaid on the page content or somewhere else.

Comment 9

[Alex Bell]

+1 for a "DOM freeze" button. Manually adding a hover class is one thing, but when things get hairy it can be very hard to tell what's going on, especially in other people's code, and with multiple nested handlers interacting. As noted, this is more than just pausing the debugger--it would be great if all mouse/touch events could be prevented relative to the DOM. Sort of like a "super-pause". How about Ctrl/Cmmnd-F8?

Comment 10

[Panos Astithas (he/him) [:past] (please ni?)]

Pausing the debugger suspends all events and timeouts in the page and spawns a nested event loop. You can try it out today in any page you like. The keyboard shortcut is F8, but you must be in the debugger panel first. If there is something that you feel is missing from your "super-pause" notion, I would be interested to know more.

Comment 11

[Brian Grinstead [:bgrins]]

(In reply to Panos Astithas [:past] from comment #10)
> Pausing the debugger suspends all events and timeouts in the page and spawns
> a nested event loop. You can try it out today in any page you like. The
> keyboard shortcut is F8, but you must be in the debugger panel first. If
> there is something that you feel is missing from your "super-pause" notion,
> I would be interested to know more.

A few notes about what would help make pausing work for this particular use case:

1) It seems a mouseout event seems to fire on the currently hovered element after pressing F8 and moving the mouse back onto the devtools panel.  See this demo page: http://fiddle.jshell.net/Lp7zk/1/show/.
If you open up the debugger, hover the "JS Mouseover" element, then press F8.  Now you can move your mouse around the window as expected without the background changing, but once the mouse moves into the devtools window, the element's background becomes yellow again (triggered by a mouseout).  Code for this case is here: http://jsfiddle.net/bgrins/Lp7zk/.

2) When the debugger is paused, the "click to select element" feature no longer works.  Though someone could find an element in the tree after following the steps from 1, it would be much easier to use the normal click to select features.  Is there any way that this would be able to work?

3) We would want a global shortcut (maybe f8) to pause script execution even when not on the debugger panel.  We would have to catch this key at the browser level as well, because often in order to get the page into the state you need it requires clicking on the page (and refocusing devtools would cause the state to go away).

Comment 12

[Patrick Brosset <:pbro>]

Inspector bug triage (filter on CLIMBING SHOES).

Comment 15

[Robin Stocker]

This is one of the things that I still need to go to Chrome for. There, F8 pauses the debugger even when the focus is on the page itself. In Firefox, I need to click into the Debugger panel which means the DOM loses the state.

Comment 16

[tero gusto]

Are there any workarounds for this by now, or maybe it has become supported in Firefox?

Comment 17

[rehit.it]

(In reply to tero gusto from comment #16)

Are there any workarounds for this by now, or maybe it has become supported in Firefox?

As a work-around this can be achieved by invoking the debugger on a time delay
Personally I paste this into the console to achieve this but I would prefer some built in functionality

setTimeout(() => { debugger; }, 5000)