User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Issue was observed on https://www.theguardian.com/world/2021/aug/31/israel-registers-record-daily-coronavirus-cases when triggering the blue accept cookie dialog.

Select the first paragraph "When we make the Guardian available to you online..."
in the inspector and copy the xpath (My xpath was: "/html/body/div/div[2]/div[2]/div/div[2]/div[1]/p").

Then search for that element in the console using $x("<xpath>").

Actual results:

An empty array was returned

Expected results:

The element should have been found. As it is the case when pasting the very same xpath into chrome.

The Bugbug bot thinks this bug should belong to the 'DevTools::Inspector' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

The issue comes from the fact that the element is in an iframe. CSS Selectors, xpath selectors etc... are always relative to the owner of the node.
If you switch to the iframe corresponding to the element via the iframe selector, then $x will return the expected element.

Chrome's console behaves interestingly here. All global selector shortcuts seem to perform queries across all frames in the document.

Technically we could probably do something similar. The question of how to show the current context of the console is a frequent issue. I'm going to block the meta Bug 1605153, which is about context selection issue.

But the approach of making some helpers work cross frames is definitely interesting.

Will be triaged and assigned priority / severity in next triage meeting.

EDIT: I was wrong about chrome's behavior, see next comment

Chrome's console behaves interestingly here. All global selector shortcuts seem to perform queries across all frames in the document.

I was wrong there, it's just that chrome updates the context based on your selection.

Their selectors are still per document. If you load the guardian page in chrome and simply run $x("/html/body/div/div[2]/div[2]/div/div[2]/div[1]/p"), you will get an empty array. It only works because using copy xpath first triggers the context to change. You can see it on top of Chrome's console.

So this will be improved by two things:

• when Fission is enabled the context will also automatically switch in Firefox for remote frames
• when we start creating targets for same process frames, this will work for all frames (this is Bug 1685500)

Note that the frame from the STRs is a same process frame. So this should be blocked on Bug 1685500, and potentially repurposed to add a test?

However it's still interesting in terms of UX to see if automated context selection can be confusing. In this case I - and I assume the reporter? - really didn't notice anything in Chrome while trying to reproduce the STRs

In the end I am going to close this as duplicate of Bug 1685500, because it should lead to the same behavior as Chrome.
The UX improvements should be discussed in this bug rather than being scattered across several bugs, so let's consolidate everything in Bug 1685500.