dpapad@ - thoughts? Is this WAI?

It's surprising to me that this is CrOS only.

Hmm, on Linux I am unable to scroll the page with a mousewheel while the menu is open, whereas on Chrome OS I am, so I suspect that is the difference. Not sure whether that is desired / expected or not.

This is not WAI. The action menu is implemented as a modal <dialog> which has guaranteed us (so far) that this is not possible. Did anyone try bisecting (I don't know if bisect-builds tool works for ChromeOS)?

The issue says it's in 59, 60, and 61, so bisecting from 58 would be challenging.

This does happen on Linux with target_os = "chromeos", so it should at least be fairly easy to reproduce and debug.

FWIW, I can't reproduce this with a Bluetooth dialog on top of the Bluetooth subpage in a small window that scrolls.

I am able to reproduce this. Making the title more generic to better reflect the issue. Still trying to figure out what is going on.

+falken
See attached screencast. So, it seems that on ChromeOS a <dialog> that has a transparent ::backdrop element is treated (erroneously) as non-modal. Adding a 0.01 opacity value makes the dialog behave as modal again. This sounds like a Blink bug to me, although have not been able to create a minimal repro yet.

Deleted: dialog_bug.mp4 1.2 MB

	dialog_bug.mp4 1.2 MB View Download

#c8: Yes it sounds like a Blink bug. In the video it looks like when opacity is 0.01 you can't scroll and when 0.0000001 you can scroll, which is surprising to me. I guess it has something to do with layering (what used to be called RenderLayer) and compositing as done on Chrome OS vs other platforms. The 0.000001 opacity allowed the layer to escape the inertness imposed by a modal <dialog>.

+aboxhall who may be interested in inertness.

Thanks for the quick reply. Also just to clarify, in WebUI we actually specify a transparent ::backdrop, see [1]. I used values 0.01 and 0.0000001 for illustration purposes only.

[1] https://cs.chromium.org/chromium/src/ui/webui/resources/cr_elements/cr_action_menu/cr_action_menu.html?l=20

@falken: Can you help forward this to on appropriate Blink person?

From my side, I can experiment with a workaround for ChromeOS, by adding a backdrop of 0.01 opacity, but this feels brittle. The different behavior between ChromeOS and Desktop in this case seems like a definite bug that should be addressed within Blink. It also breaks the <dialog> spec AFAIU. A dialog shown with showModal() should be modal regardless of how its backdrop is styled.

I'd recommend spinning off a new bug that you are Assigned to for the workaround, and marking this one as Untriaged with the sole component Blink>HTML>Dialog. Untriaged bugs in Blink get a lot of attention.

I think this would fall onto DOM/HTML team's plate.

In hopes that someone knows about layering/scrolling/compositing and could have a good guess about why Chrome OS would be different than all other platforms, adding +pdr, +enne.

I was able to reproduce this on a Mac too. Removing UI>Settings and marking as Untriaged per #13. Can someone from the Blink team please take a look? See comment#8 for current findings.

This is not painting. This actually looks to me like some change to event handling or filtering for scrolling.

Our bisect-builds.py script claims to handle chromeos as a bisect target on linux.

flackr@ do you know if there is a bit in the compositor knowing that this layer is a modal layer and consumes all events? I can't immediately find that.

flackr@ any update on this?