Don't throw when popover/dialog is in requested state

[josepharhar]

This patch makes the following changes:

• Don't throw exceptions when showPopover or hidePopover is called and the popover is already in the requested state.
• Don't throw exceptions when dialog.showModal, dialog.show, or dialog.close is called and the dialog is already in the requested state.
• Throw exceptions when trying to switch between modal and non-modal dialog modes via dialog.showModal or dialog.show.

Fixes #9045

• At least two implementers are interested (and none opposed):
  • Chrome
  • WebKit
• Tests are written and can be reviewed and commented upon at:
  • Don't throw when popovers and dialogs are in requested state web-platform-tests/wpt#39781
• Implementation bugs are filed:
  • Chromium: https://chromium-review.googlesource.com/c/chromium/src/+/4494823
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1830737
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=256167
• MDN issue is filed: n/a

(See WHATWG Working Mode: Changes for more details.)

---

/interactive-elements.html ( diff )
/popover.html ( diff )

[annevk]

Looks good editorially.

[annevk]

This is a new exception, how certain are we that this is web compatible?

[annevk]

Tim convinced me that it's unlikely this will break anything.

[annevk]

Once this has tests and impl bugs this should be good to go. Thanks @josepharhar!

[josepharhar]

Once this has tests and impl bugs this should be good to go.

Done

[josepharhar]

@mfreed7 suggested that we should throw when hidePopover is called on a disconnected popover. This PR currently makes disconnected popovers stop throwing when hidePopover is called on them.

Does anyone have thoughts on this? If not I'll make that case start throwing again.

[mfreed7]

@mfreed7 suggested that we should throw when hidePopover is called on a disconnected popover. This PR currently makes disconnected popovers stop throwing when hidePopover is called on them.

Does anyone have thoughts on this? If not I'll make that case start throwing again.

...my rationale was simply that this is a different case than calling showPopover when it's already showing. Calling showPopover/hidePopover in "invalid" cases should still throw. These include elements not containing the popover attribute, disconnected elements, etc.

[annevk]

I don't care strongly, though I suspect it'll be easier for people to use when there are less cases that throw, including what one might think of as erroneous cases. I'm wondering what web developers would do when they encounter the exception. Add a conditional or solve their ordering problem? If they would usually do the former, they are better served by us not throwing.

Either way, this will need some rebasing.

[josepharhar]

I resolved the conflicts, which included the current document vs expected document check, which I included in the list of conditions after the no-exception early out.

[mfreed7]

I don't care strongly, though I suspect it'll be easier for people to use when there are less cases that throw, including what one might think of as erroneous cases. I'm wondering what web developers would do when they encounter the exception. Add a conditional or solve their ordering problem? If they would usually do the former, they are better served by us not throwing.

One quick data point: nobody evaluating the popover API that I worked with encountered this issue, or at least never relayed it to me, so hopefully it's fairly corner case.

My intuition is that we'll most help them by throwing. If you call showPopover() while the element is disconnected, it won't do anything. So calling attention to this seems like the right thing to do, rather than silently succeeding and doing nothing. If the problem was an ordering problem, e.g. popover.showPopover(); document.body.appendChild(popover); then the only fix is to solve the ordering problem. If the problem was a state problem, e.g. function justTryShowing() {popover.showPopover} then the only fix is a conditional. But without a signal like an exception, it'll be very frustrating to try to figure out why the popover isn't showing. (I've encountered this frustration - it's real.)

[mbrodesser-Igalia]

@mfreed7 suggested that we should throw when hidePopover is called on a disconnected popover. This PR currently makes disconnected popovers stop throwing when hidePopover is called on them.
Does anyone have thoughts on this? If not I'll make that case start throwing again.

Assuming this is an edge-case, with unclear developer benefit, consistency with showPopover() and togglePopover() seems preferable. An argument against the current inconsistency is, that it must propagate through the spec down to the calls of https://html.spec.whatwg.org/#check-popover-validity. Let's please make this consistent.

@emilio: what's your view on this?

CC @mfreed7

...my rationale was simply that this is a different case than calling showPopover when it's already showing. Calling showPopover/hidePopover in "invalid" cases should still throw. These include elements not containing the popover attribute, disconnected elements, etc.

[mbrodesser-Igalia]

CC @josepharhar

[josepharhar]

Assuming this is an edge-case, with unclear developer benefit

Let's please make this consistent.

What exactly are you proposing?

consistency with showPopover() and togglePopover() seems preferable

On a disconnected popover:

• showPopover will throw
• togglePopover will throw after Make togglePopover throw more exceptions #9451
• hidePopover does not throw after this PR

[mbrodesser-Igalia]

Assuming this is an edge-case, with unclear developer benefit

Let's please make this consistent.

What exactly are you proposing?

To let hidePopover throw on a disconnected popover.

consistency with showPopover() and togglePopover() seems preferable

On a disconnected popover:

* showPopover will throw

* togglePopover will throw after [Make togglePopover throw more exceptions #9451](https://github.com/whatwg/html/pull/9451)

* hidePopover does not throw after this PR

Then those three methods all throw, hence, are consistent.

[josepharhar]

Ok, yeah I suppose that making hidePopover throw on a disconnected popover doesnt necessarily go against the original motivation of the issue that this PR fixed, so I'm ok with making it throw again

[nt1m]

The current setup is consistent with dialog fwiw, HTMLDialogElement::close() does not throw, but HTMLDialogElement::showModal() does.

[annevk]

Yeah, there's a difference between not being able to show and hiding no-opping. This was discussed in one of the many issues.

[mbrodesser-Igalia]

The current setup is consistent with dialog fwiw, HTMLDialogElement::close() does not throw, but HTMLDialogElement::showModal() does.

Thanks for pointing that out.

Be aware that hidePopover() called on an element without the popover attribute does throw. See https://html.spec.whatwg.org/#dom-hidepopover. That differs from https://html.spec.whatwg.org/#close-the-dialog.

Consistency within the popover API seems preferable, or?

[nt1m]

Be aware that hidePopover() called on an element without the popover attribute does throw. See https://html.spec.whatwg.org/#dom-hidepopover. That differs from https://html.spec.whatwg.org/#close-the-dialog.

You can't really change the tagname for <dialog>, so there isn't a parallel here I think.

[mbrodesser-Igalia]

You can't really change the tagname for <dialog>

True.

, so there isn't a parallel here I think.

[mbrodesser-Igalia]

Yeah, there's a difference between not being able to show and hiding no-opping. This was discussed in one of the many issues.

Presumably you mean #9142 (comment) and previous comments.

I lack the experience of what web-developers actually prefer. As there are arguments for both behaviors, throwing and not throwing, let's leave the API in the current state.