Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
domenic opened this issue Sep 30, 2024 · 10 comments
Labels
agenda+ To be discussed at a triage meeting normative change topic: dialog The <dialog> element. topic: popover The popover attribute and friends

Comments

@domenic
Copy link
Member

domenic commented Sep 30, 2024

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?

@domenic domenic added normative change topic: dialog The <dialog> element. topic: popover The popover attribute and friends labels Sep 30, 2024
domenic added a commit that referenced this issue Sep 30, 2024
@keithamus
Copy link
Contributor

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
Copy link
Member

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
Copy link
Member Author

domenic commented Oct 1, 2024

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.

@domenic domenic added the agenda+ To be discussed at a triage meeting label Oct 1, 2024
@smaug----
Copy link

Throwing sounds good to me.

@annevk
Copy link
Member

annevk commented Oct 1, 2024

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
Copy link
Member Author

domenic commented Oct 2, 2024

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
Copy link
Member

annevk commented Oct 2, 2024

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
Copy link
Member Author

domenic commented Oct 2, 2024

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

@annevk
Copy link
Member

annevk commented Oct 2, 2024

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

@domenic
Copy link
Member Author

domenic commented Oct 2, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
agenda+ To be discussed at a triage meeting normative change topic: dialog The <dialog> element. topic: popover The popover attribute and friends
Development

No branches or pull requests

5 participants