Nightly dialog element implementation incompatible with Chrome in our PWA
Categories
(Firefox :: Untriaged, defect)
Tracking
()
People
(Reporter: ashley, Unassigned)
References
(Blocks 1 open bug, )
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0
Steps to reproduce:
Firefox 81 has the <dialog> element enabled by default (see issue 840640), but it breaks our PWA because the implementation is incompatible. Steps to observe the issue:
- Visit our PWA at https://editor.construct.net/
- Click the 'New project' button
- Hover the mouse over the bottom-right border of the dialog that appears
Actual results:
Unwanted scrollbars appear in the dialog. The mouse cursor does not change.
The problem appears to be caused by an element <div class="docCursorOverlayElem"> that we insert to the dialog element to control the cursor. (We have to do this for various reasons, but mainly to work around a Chrome bug involving changing the mouse cursor.) If you add the style background-color: rgba(255, 0, 0, 0.5), you can see the element. In Firefox it does not layer on top of the dialog, and its size causes the dialog element to overflow.
Expected results:
No scrollbars appear, and the mouse cursor change to a resize cursor. This is what it does in Chrome.
If the element is made visible, you can also see the docCursorOverlayElem element layers on top of the dialog. Presumably this is why the cursor is able to change as well.
I did try to reproduce this in a fresh minimal repro using the same pattern and styles as our PWA, but I couldn't get anywhere doing that. There must be something specific about our PWA that causes this issue in Firefox.
|
||
Comment 1•4 years ago
|
||
So this is because in Firefox the dialog is overflow: auto, for reasons (see all the discussion in https://github.com/w3c/csswg-drafts/issues/4645 as for why and the different trade-offs involved here, it seems likely that Chrome will change to such a model too).
These are the relevant UA styles currently, which you can see if you use the "show browser styles" setting in devtools.
You can fix this on your side by setting overflow: visible on it for now, sorry for not having a more satisfactory answer just yet, but dialog positioning in Chrome is a total hack and we were hoping not having to reverse-engineer / copy their hack.
|
|
||
Updated•4 years ago
|
Thanks for getting back so quickly! That makes sense, and is a reassuringly simple workaround. I've added a style to make all our dialog elements use overflow: visible, and now it's consistent between Chrome and Firefox again. This should make sure nothing breaks in our PWA when Firefox ships the dialog element. I'm happy for this issue to be closed if the underlying default overflow style issue is tracked somewhere else.
|
|
||
Comment 3•4 years ago
|
||
Yeah, this is tracked in https://github.com/w3c/csswg-drafts/issues/4645, so let's close this for now.
If more instances of this get reported we probably need to go back to the CSS Working Group and figure out a solution (maybe we can just leave the dialog with overflow: visible and hope that people don't write dialogs higher than the viewport height, but that's not amazing I think).
Thanks a lot for filing this!
Description
•