Thanks to visit codestin.com
Credit goes to phabricator.services.mozilla.com

Page MenuHomePhabricator

Bug 1878708 - Dialogs HideAllPopoversUntil nearest popover, not document. r=smaug
ClosedPublic

Authored by keithamus on Feb 5 2024, 5:23 PM.
Referenced Files
Unknown Object (File)
Nov 13 2025, 1:23 PM
Unknown Object (File)
Nov 13 2025, 1:23 PM
Unknown Object (File)
Nov 13 2025, 1:23 PM
Unknown Object (File)
Nov 7 2025, 8:04 AM
Unknown Object (File)
Aug 6 2025, 1:01 AM
Unknown Object (File)
Aug 6 2025, 1:01 AM
Unknown Object (File)
Aug 6 2025, 1:01 AM
Unknown Object (File)
Aug 5 2025, 12:38 PM
Subscribers

Details

Summary

Given some markup like:

<div id=popover popover>
  <button id="openDialog">Open Dialog</button>
  <dialog id=dialog>
    I'm a dialog!
  </dialog>
</div>
<button id="openPopover">Open Popover</button>
<button>I do nothing!</button>

With some JS like

openDialog.onclick = () => {
  dialog.showModal();
}

openPopover.onclick = () => {
  popover.showPopover();
}

Clicking the "Open Popover" button followed by the "Open Dialog" button results in both the Dialog and Popover being hidden, however the dialog will still be open as modal, rendering the whole page inert, nothing is clickable and there seems to be no way to undo this (unless you use a CloseWatcher gesture such as the Esc key - if you have one available on your device).

It is expected that the popover should not close the dialog, as it causes the invisible Modal Dialog to make the whole page inert, and it is very difficult for users (and developers) to discover how to undo this action (pressing escape).

This was reported in https://github.com/whatwg/html/issues/9998, and WhatWG resolved to fix this, which in https://github.com/whatwg/html/pull/10116.

Event Timeline

phab-bot published this revision for review.Feb 5 2024, 5:24 PM
phab-bot changed the visibility from "Custom Policy" to "Public (No Login Required)".
phab-bot changed the edit policy from "Custom Policy" to "Restricted Project (Project)".
phab-bot removed a project: secure-revision.

Code analysis found 4 defects in diff 818310:

  • 4 build errors found by clang-tidy
IMPORTANT: Found 4 defects (error level) that must be fixed before landing.

You can run this analysis locally with:

  • ./mach static-analysis check --outgoing (C/C++)

If you see a problem in this automated review, please report it here.

You can view these defects in the Diff Detail section of Phabricator diff 818310.

smaug requested changes to this revision.Feb 5 2024, 9:20 PM
smaug added inline comments.
dom/html/HTMLDialogElement.cpp
68

Could you fix the build errors.

140

here too

This revision now requires changes to proceed.Feb 5 2024, 9:20 PM
dom/html/HTMLDialogElement.cpp
68

I guess Show() needs to be marked as MOZ_CAN_RUN_SCRIPT and hideUntil should be RefPtr<Element>

72

Are there tests which move focus in a toggle event listener (fired for the popover) and then focus moves to dialog here?

keithamus updated this revision to Diff 818528.
keithamus marked 3 inline comments as done and an inline comment as not done.Feb 5 2024, 10:09 PM
keithamus added inline comments.
dom/html/HTMLDialogElement.cpp
72

I don't think so. Could you please help me understand why such a test might be needed for this change? I'm not following.

smaug added a project: testing-approved.
smaug added inline comments.
dom/html/HTMLDialogElement.cpp
72

It might not need to, but this is the type of case where implementations easily do something wrong - native method triggering random events inside the algorithm and then expecting certain behavior at the end.
But I guess SetOpen() triggers already similar case through mutation events.

This revision is now accepted and ready to land.Feb 5 2024, 11:00 PM
dom/html/HTMLDialogElement.cpp
72

That makes sense, thanks, I'll look following with tests especially when adding dialog beforetoggle/toggle events.