Closed Bug 1200896 Opened 9 years ago Closed 4 years ago

Make the document blocked by the topmost element in the top layer

Categories

(Core :: DOM: Core & HTML, defect, P5)

defect

Tracking

()

RESOLVED FIXED
81 Branch
Tracking Status
firefox43 --- wontfix
firefox81 --- fixed

People

(Reporter: xidorn, Assigned: sefeng)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

We have resolved that, if there is anything in the top layer, we should mark the document blocked by the topmost element in the top layer.

This behavior hasn't been speced yet, but it would be speced in the HTML spec and have a pointer from the Fullscreen API spec. [1]

The HTML spec has defined a "blocked by modal dialog" concept [2], which would be extended to also cover fullscreen.


[1] https://github.com/whatwg/fullscreen/issues/15
[2] https://html.spec.whatwg.org/multipage/interaction.html#blocked-by-a-modal-dialog
Assignee: nobody → ntim.bugs
Blocks: 1322939
Unassigning to reflect real status.
Assignee: ntim.bugs → nobody
Priority: -- → P5

hmm, I don't think this is a blocker of modal dialog.

The blocked by modal dialog piece is used by cancelling the dialog, and we got it handled in bug 1322947.

I think we probably want to move this bug as part of the inert implementation?

Talked with Tim on Riot: this bug should be about the concept of "inert subtrees" which should probably first be used in the top layer/modal dialog case.

Blocks: 921504
No longer blocks: 1322939

(In reply to Sean Feng [:sefeng] from comment #3)

hmm, I don't think this is a blocker of modal dialog.

The blocked by modal dialog piece is used by cancelling the dialog, and we got it handled in bug 1322947.

Currently, you can tab out of a modal dialog. I'd argue that's a blocker of modal dialog. Is that covered by this bug or should I file that separately?

You mean to use Tab to move the focus out of modal dialog?

This is where inert element comes to play, to prevent this kind of behaviour. This bug is already a blocker of inert element, and I don't think we need to file one separately.

(In reply to Sean Feng [:sefeng] from comment #6)

You mean to use Tab to move the focus out of modal dialog?

I'm saying tab shouldn't be able to move focus out of a modal dialog, yes.

This is where inert element comes to play, to prevent this kind of behaviour. This bug is already a blocker of inert element, and I don't think we need to file one separately.

Okay, but I'm saying this (or at least inert) should block shipping modal dialog, which I don't think it does currently. Bug 921504 (inert) depends on dialog-element, since the idea was to implement this as an enhancement on top of dialog, but that doesn't make it clear that inert subtrees should block dialog shipping.

The concept of inert subtrees must be used for all elements that are not the topmost top layer item (which can be a modal dialog or a full screen item).

So I agree with James, inert subtrees are necessary to ship modal dialogs.

Blocks: 1322939

Okay, agreed!

fredw, asurkov, would you be interested in implementing the inertness for modal dialog?

For modal dialog, we don't need the entire inert attribute support, we just need the inertness. If we can support the usage for modal dialog first, that would be great.

Flags: needinfo?(surkov.alexander)
Flags: needinfo?(fred.wang)

(In reply to Sean Feng [:sefeng] from comment #9)

Okay, agreed!

fredw, asurkov, would you be interested in implementing the inertness for modal dialog?

For modal dialog, we don't need the entire inert attribute support, we just need the inertness. If we can support the usage for modal dialog first, that would be great.

Agreed, that would make a good start. I'm in.

Flags: needinfo?(surkov.alexander)
Flags: needinfo?(fred.wang)

After bug 921504 is landed (-moz-inert CSS property), apparently there's no blockers on this one. Sean, is it something you are on?

Flags: needinfo?(sefeng)

Thanks for landing -moz-inert, I'll do the work for this one.

Thanks Alex!

Assignee: nobody → sefeng
Flags: needinfo?(sefeng)
See Also: → 1657163

TopLayerPush has always been returning true, so returning it as a
boolean is incorrect.

Attachment #9168842 - Attachment is obsolete: true
Attachment #9168842 - Attachment is obsolete: false
Pushed by sefeng@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8b57f059e63e
Make TopLayerPush to return void r=emilio
https://hg.mozilla.org/integration/autoland/rev/c7ae88fd1bd7
Make the document blocked by the topmost element in the top layer r=emilio
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/24939 for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot

When a modal dialog is cancelled, the inertness for other elements
is reverted. However, in order to have the new state (non-inert)
effective, Firefox needs to do a frame flush. This flush is taken
place when it's really needed.

In browser_pioneer_us.js, we have some usage of some buttons when
the flush hasn't taken place yet, so the test fails because the
buttons are not clickable. To fix the test, we add a
getBoundingClientRect() call to force frame flushes to the
corresponding buttons.

Pushed by sefeng@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7f016de8d52f
Make TopLayerPush to return void r=emilio
https://hg.mozilla.org/integration/autoland/rev/5d9e9bd12cd2
Make the document blocked by the topmost element in the top layer r=emilio
https://hg.mozilla.org/integration/autoland/rev/17df14f0b129
Force frame flushes when needed to fix browser pioneer test r=rhelmer
Regressions: 1659042
Pushed by sefeng@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b70a32173d7c
Make TopLayerPush to return void r=emilio
https://hg.mozilla.org/integration/autoland/rev/f0487d823d74
Make the document blocked by the topmost element in the top layer r=emilio
https://hg.mozilla.org/integration/autoland/rev/b0add3579bcc
Force frame flushes when needed to fix browser pioneer test r=rhelmer
Flags: needinfo?(sefeng)
No longer blocks: 921504
Depends on: 921504
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: