The implication of this change is that the other "check popover validity" checks (dialog, fullscreen, disconnected) would run in the cases I mentioned in the title: https://html.spec.whatwg.org/multipage/popover.html#check-popover-validity

So the following code would result in a call to check popover validity and possibly throw exceptions?
const div = document.createElement('div');
div.setAttribute('popover', 'auto');
// don't connect to document or show
div.togglePopover(/*force=*/false); // try to force close
We decided to not throw in certain cases. Did we decide to not throw for cases where state does not match up? It looks to me like showPopover() still throws for this condition so togglePopover() should as well.

So the above code I wrote should throw an exception then?

@josepharhar Since hidePopover() wouldn't throw in this case, I would say it shouldn't (and in fact it wouldn't with the suggested change, since the check popover validity algorithm wouldn't in this case).

But:

const div = document.createElement('div');
// don't set popover attribute
// don't connect to document or show
div.togglePopover(/*force=*/false); // try to force close

would start throwing, unlike the current algorithm.

Stuff in step 3. of the check popover validity would also start throwing.

togglePopover() algorithm does not check popover validity when force == false and when the popover visibility state is hidden #8999

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions