better iframe handling

while #265 is super out of scope, what isn’t is considering a way to help users get to those iframes in isolation. i personally open the devtools and then open the iframe url in a new window. sounds right up visbug’s alley doesnt it?

ux:

• hover over an iframe
• get a metatip
• cmd + click to open iframe in a new tab
• visbug intercepts and uses js to complete the action

todo: (stubbed dev workflow)

• make an iframe.js feature
• iframe feature sets up listeners for hover and click on iframes
• hover handler creates a metatip.element with instruction text
• click handler uses window object to make a new tab with e.target src
• import that feature from selectable.js? or visbug.element?

[argyleink]

Thanks for this comment and check-in! Here’s some of my thoughts and feedback 🙂

• i should have remembered that clicks on iframes wasn’t going to be a thing we could leverage, it’s one of the reasons visbug can’t operate on an iframe to begin with. sorry for not alerting you earlier, i was also oblivious to it when i write the prelim idea on how to tackle this. thanks for calling it out explicitly.
• good news is that the hover event can currently see iframes and could definitely delegate the creation of a click stealing overlay to an iframe capture handler. that’s a great idea. perhaps the tooltip is replaced by a meaningful overlay? so we put the messaging into the overlay, and if they click while the overlay is showing, we send them to the iframe destination?

that would update the flow to this:

• hover over an iframe
• create an overlay (if not already created) with a message about what happens with they click
• click opens the iframe in a new tab
• hover out, set created overlay opacity to display none (or whatever works best here, tbd). maybe since an iframe wont have a hoverout we leverage clearHover()?

this is still a great addition to visbug!

[adhrinae]

Yes, Overlay! I completely forgot that term. Thanks for the advice. I’ll try to approach this problem from creating overlay.