Consider throwing for showModal() and showPopover() in non-fully-active documents

[domenic]

What is the issue with the HTML Standard?

As a followup to #10634, it doesn't really make sense that you can call showModal() or showPopover() on elements which are inside of synthetic documents, of the type created by document.implementation.createHTMLDocument(). Example: https://jsbin.com/cubafoputo/1/edit?html,js,output

I think we should have these throw exceptions, similar to the exceptions we already throw for disconnected elements.

I suspect this change is web-compatible, especially for popover but even for dialog. These synthetic documents are super rare.

@smaug---- @keithamus @josepharhar @nt1m do you agree? Are you willing to take the potential compat risk or the trouble of adding use counters?

[keithamus]

Sounds reasonable to me (non-implementer, userland consumer). They already throw for a handful of exceptional cases (calling showModal() twice for example) which are much more likely to occur.

[lukewarlow]

Given how new popover is, how most uses of popover are probably based on user input, and how niche this type of document is, my instinct is also that this would be web compatible. Likewise for dialogs, they're relatively new too.

Should this apply to dialog.show() too?

[domenic]

I'm unsure about show(). If we were to ever fix #5802 and make show() roughly equivalent to adding open="", then it would not make much sense to throw, I think.

[smaug----]

Throwing sounds good to me.

[annevk]

Is the idea here that nothing should be in the top layer when a document is no longer fully active? Will we also empty it when a document becomes inactive?

[domenic]

Is the idea here that nothing should be in the top layer when a document is no longer fully active? Will we also empty it when a document becomes inactive?

No, I think the idea is that nothing should be in the top layer for synthetic documents. "Normal" documents that get bfcached can have a top layer without an issue, IMO.

[annevk]

Wouldn't a browsing context check be more appropriate then? I guess either way could work, but the former is a more exact match of what you're after.

[domenic]

Indeed, they're equivalent in this case. Fully active is just more conventional.

[annevk]

Well, doesn't a bfcache'd document still hold onto its browsing context?

[domenic]

Yes, but you cannot call showModal() on a <dialog> in a bfcached document, because you cannot have a scripting relationship to such documents.

[mfreed7]

This sounds reasonable, and likely to be web compatible, at least to me. It seems very corner-case to create a document, put a popover in it, and call showPopover() expecting things to happen. There's always the chance that there's a use case, but I can't think of one. I suppose it's possible that people do that and then move those elements to a rendered document and expect things to be "still open", but that's not what happens today, other than an open non-modal dialog because of the open attribute.

I'd be relatively happy to take the risk of compat shipping this change, if there's consensus.

[domenic]

Thanks all. I think that's explicit support from 2/3 implementations and some level of implicit agreement from @annevk, so I'll take this off of agenda+ and proceed with a spec PR asynchronously.