Element picker can be covered by native <dialog> / [popover] pop-ups

[krystian3w]

Prerequisites

• I verified that this is not a filter issue (MUST be reported at filter issue tracker)
• This is not a support issue or a question
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
• The issue is not present after wholly disabling uBlock Origin ("uBO") in the browser
• I checked the documentation to understand that the issue I report is not a normal behavior

I tried to reproduce the issue when...

• uBO is the only extension
• uBO with default lists/settings
• using a new, unmodified browser profile

Description

New native dialog pop-ups is rendered higher than element picker iframe, so if element is selected then no possible click in "create" button. Similar to #1098, #987

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog
https://developer.mozilla.org/en-US/docs/Web/CSS/::backdrop
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/popover

---

AdGuard freeware Addon have similar limitation as long use iframe #adguard-assistant-dialog.

A specific URL where the issue occurs

https://gistcdn.githack.com/krystian3w/4ebb7b77634d94a9b2f7238dcee32947/raw/index.html or https://gistcdn.githack.com/krystian3w/4ebb7b77634d94a9b2f7238dcee32947/raw/index2.html

real world cases:

• https://www.blogmojo.de/chatgpt-alternative/

• indagare.com

• computerbase.de

• https://en-us.topographic-map.com/map-vx51/San-Francisco/?center=37.90303%2C-121.83254&zoom=12

• https://www.warzywapolowe.pl/

Steps to Reproduce

1. try open demo page - credits: CSS-Tricks team
2. click in blue open button
3. try block opened dialog by element picker
4. try save created proposition form element picker interface

Expected behavior

• element picker should be rendered higher than native dialog pop-ups (native dialog pop-ups use z-index: auto so I cannot found method)
• almost always possible select these opened dialogs - in that slow demo I can not select: https://htmlpreview.github.io/?https://gist.githubusercontent.com/krystian3w/4ebb7b77634d94a9b2f7238dcee32947/raw/index.html
• Maybe new keyboard shortcuts allow save filter like last closed Keyboard shortcut to toggle cosmetic filtering #2000

Actual behavior

• dialog pop-ups is often untouchable with slow demos like: https://htmlpreview.github.io/?https://gist.githubusercontent.com/krystian3w/4ebb7b77634d94a9b2f7238dcee32947/raw/index.html
• element picker are rendered under dialog pop-ups with recommended demo

uBlock Origin version

1.58.1b12

Browser name and version

Firefox 128.0

Operating System and version

Windows 11 Pro 23H2

[u-RraaLL]

Doesn't gorhill decline issues based just on proof on concept instead or real cases?

[krystian3w]

Maybe but what happens when these pop-ups start cover 99% of Internet or start used to disable use element picker (small ads in sidebar without backdrop).

[krystian3w]

Pages started use dialogs:

uBlockOrigin/uAssets@0196844

[gorhill]

@u-RraaLL See https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement, and specifically https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement/showModal.

[u-RraaLL]

My bad. I was still on FF 97.0.2 and wasn't affected.

[peace2000]

If I understood this issue correctly, the same behavior can be seen on this link:

https://en-us.topographic-map.com/map-vx51/San-Francisco/?center=37.90303%2C-121.83254&zoom=12

The picker won't become visible. Caused by GDPR dialog.

[pajot]

I see similar behaviour with a consent dialog at https://computerbase.de.

My workaround is to manually enter a filter rule that blocks dialogs, like so:

! computerbase is using dialog elements to prevent element picker from working
computerbase.de##dialog

The funny thing about this is that using a dialog element makes blocking the whole consent mechanism much cleaner and easier. But it would be nice if the element picker could handle it.

(Of course, blocking all dialog elements is an extreme solution and not an option if the site uses dialogs for anything that's actually useful to the user, but the filter can be made more granular with class designators.)

[krystian3w]

but the filter can be made more granular with class designators

Worse as they will drive us into a corner when the attribute name is not stable and the value is - not everyone has yet learned to use :matches-attr and not everyone reads the wiki.

[u-RraaLL]

Another case: https://www.reddit.com/r/uBlockOrigin/comments/1d5wpjl/cant_use_ublock_on_a_website/

[krystian3w]

Popover also is danger:

• https://www.w3schools.com/tags/att_popover.asp
• https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/popover

test: https://gistcdn.githack.com/krystian3w/4ebb7b77634d94a9b2f7238dcee32947/raw/index2.html

(On the plus side of the attribution is the requirement for a genuine click (only someone needs to check that they detect fake clicks in JS - if there is no detection of whether the user has clicked, I would equate it with the dialogue tag))

[eternal-sorrow]

If the dialog is modal (shown with .showModal()), then blocking it with uBlock doesn't help. The dialog doesn't show up, but the page becomes non-interactive. You can scroll, but cannot interact with it, and certainly cannot use the element picker.

[peace2000]

@dftf-stu Concerning that matter, please open a separate discussion thread here: https://github.com/uBlockOrigin/uBlock-issues/discussions