How do you select elements that are not there?

Did it ever happen to you that you have an element, a pop up, a dialog, a pop up on a page that dissapears before you can actually used the inspector on it? If it has how did you solve this? If it did not and you want to know how you can select this invisible elements take a look at the article below.


Nice ideas!

My solution often is to use a recorder. Starting the recorder before the last action which triggers the temporary shown element.
In the recording mode I also select error message.

This might need a correct setup of the recorder to the get correct format of the selector.
And it produces sometimes crap as a good selector is so demanding that just a human is capable of creating it, but not the algorithm of the recorder.

Do you mind giving the solutions concrete names?
It would improving relating to them easier.
E.g. Pause by DevTools, Change Element Type

1 Like

Thank you very much for the comment. I updated the article a bit.

1 Like

ok - so you are describing how to test/find an element that’s not “invisible”, but is really temporary? That’s a different thing, or do you really mean hidden? I think you are really meaning fleeting or temporarily, and in that case do not test this, not even with a barge pole, step away from it. An app that (And android and IOS) is especially bad for this, with big screens. That has the user using their big ass tablet and then show a notification related to an action, but the “pop” comes at the bottom of the screen, while the user is still focused on the top of a 20" screen, yeah, that’s not great UX. And even if it was right next to the focus, someone who speaks a different language or is a slow reader, will try to provoke the error message again.

As for test automation, the only reliable thing there is to grab the console log, or ask the devs to make the pop stay up for longer - which becomes a hack. So, generally , steer away from this is my personal advice, it’s very fragile and very implementation-specific. Also means you end up testing the behavior, not the user experience.


I meant temporary you are right.

1 Like

I’ve had a lot of pain on android with “toasts” and I just tell the devs, I’m not going to test that. Unless the notification comes with an actual application state change that matters, (as in enables or disables a user workflow step) it’s not functionality worth testing.

Oh I do like the question and the answer though, very good learning to be had there.

1 Like

A short update on this with Cypress

1 Like