A way to stall automatic popups that vanish after a while to inspect them

[codepo8]

I just got this as a question in my talk at Goto Copenhagen. When you have an information popup that vanishes after a while in a page and you want to inspect that, there is no way to do so at the moment.

I thought starting a debugging session would do the trick as it halts the main JS thread, but as window.timeout is async, the debugging session does not stop this functionality from executing.

If people use CSS animations with delay it would not work either. Which brings us to another feature of pausing animations.

I suppose one way would be to find the code that shows and hides the popup and set a breakpoint, or to use overrides to copy the script locally and remove the code that hides the overlay. But all of this is too complex.

AB#41735877

[captainbrosset]

Thanks for bringing this request here Chris.

I'm wondering if this could also be solved by using a DOM breakpoint. This way you wouldn't have to find the code, but instead find the DOM element of the popup.

There are many ways to implement this vanishing popup, do you have any more details about how the person at that conference has implemented it exactly?

[codepo8]

Sadly, no, but if you boil this down, it would come to:

• Implement a way to intercept setTimeout/setInterval
• Halt CSS animation delays / pause CSS animations

[hxlnt]

Pausing, replaying, tweaking, and scrubbing through CSS animations at various playback speeds is a feature in the Animation tab. This tab also provides links back to the relevant divs in Elements.

[codepo8]

Pausing, replaying, tweaking, and scrubbing through CSS animations at various playback speeds is a feature in the Animation tab. This tab also provides links back to the relevant divs in Elements.

would be interesting to see if that applies to this use case. I was just adding animations as that is one way to achieve that. I assume that 99% of timed popups use setTimeout instead, though.

[hxlnt]

The screenshot above is debugging a timed popup that is animated via CSS but triggered by setInterval(), which I imagine is a pretty common scenario for this kind of thing, along with just a regular old CSS animation-delay.

If the whole deal in animated in Javascript, then maybe breakpoint step-through is the way to go anyway.

One thing that would be really nice debugging something like a CSS-animated pop-up, though, is better real-time updates of computed values. Currently, it appears that only some animated properties update live in the Computed panel in Elements. (For example, animating background-image updates in real time but animating bottom does not.) It would be hugely helpful to be able to open Animations and Elements side by side, scrub through the animation timeline, and see the all values in Computed update in real time. I will investigate and see if this is a bug or by design.

[pankajparashar]

While browsing through the Firefox Source Docs, I came across the "Debugging Popups" section, which describes a setting in Firefox that disables popups from auto-hiding during debugging.

Is there an equivalent feature like this in Edge/Chrome?
If not then would the addition of this feature solve the use-case described by @codepo8?
Can this setting be extended to work for the timed popups?

[captainbrosset]

I don't think anything like this exists for Chromium-based browsers unfortunately.

However, my recollection is that this Firefox feature only applies to browser popups, e.g. right-click contextual menus that appear in the browser UI.
I don't think it works for "pseudo" popups that web developers create using HTML and CSS in their webpages.

Let me ping @juliandescottes to confirm the above.

It would be interesting to see if something like this could be applied to CSS top-layer elements. <dialog> elements, and (soon) elements with the popover attribute are displayed by the browser in the top-layer. It might be useful to add a feature that forces elements in the top-layer to remain visible. This would only work if developers use these special dialog and popover elements, but maybe it's a useful start, and might push more web developers to make use of them instead of re-creating div-based popups with z-index hacks.

[pankajparashar]

That explanation makes sense. The idea of applying this to the #top-layer is sensible, otherwise the browser wouldn't know what's a popup and what's not. Hopefully, this should also encourage devs to start using these new top-layer elements.

[juliandescottes]

I don't think it works for "pseudo" popups that web developers create using HTML and CSS in their webpages.

This is correct, only applies to browser popups.