Skip to content

Handle documents not being fully active #218

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

Closed
marcoscaceres opened this issue Sep 2, 2021 · 8 comments · Fixed by #219
Closed

Handle documents not being fully active #218

marcoscaceres opened this issue Sep 2, 2021 · 8 comments · Fixed by #219

Comments

@marcoscaceres
Copy link
Member

Given a nested content (iframe), it's possible to capture a click event, have the click event remove the iframe, and then call one of the methods.

https://github.com/marcoscaceres/playground/blob/83a28912a59b6f87cec4627536450eaf1a5db8a5/share-parent.html#L6-L18

Accessible from:
https://marcoscaceres.github.io/playground/share-parent.html

In Safari, .share() rejects with a TypeError.
in Firefox, .share() rejects with a NS_ERROR_UNEXPECTED (Gecko code).
In Chrome, share() rejects with NotAllowedError: "Must be handling a user gesture to perform a share request."

Not sure why Chrome thinks that the click handler is not happening inside a user gesture (technically, not incorrect as the iframe has been removed, but still a weird).

I think we should align align with Safari here and just reject with a TypeError. @saschanaz, wdyt?

@saschanaz
Copy link
Member

Is TypeError conventional for this kind of failure? Something like InvalidStateError makes more sense to me 🤔

@marcoscaceres
Copy link
Member Author

When it comes to exceptions related to this, it's a bit all over the place to be honest... and having multiple exception types gets unnecessarily messy/complicated, IMO.

Safari actually does the check during share data validation, which is why it results with a TypeError. It might be a good place to do the check in the spec too. This kind of error is a super edge case.

@marcoscaceres
Copy link
Member Author

Actually, I forgot that we already use a bunch of different exception types in this spec.

@saschanaz
Copy link
Member

saschanaz commented Sep 2, 2021

Safari actually does the check during share data validation, which is why it results with a TypeError. It might be a good place to do the check in the spec too. This kind of error is a super edge case.

That means canShare would fail on non-fully-active documents, I'm not sure it's a good idea.

Edit: What does Chrome do for canShare?

@marcoscaceres
Copy link
Member Author

Edit: What does Chrome do for canShare?

returns true.

Screen Shot 2021-09-03 at 11 39 38 am

@marcoscaceres
Copy link
Member Author

That means canShare would fail on non-fully-active documents, I'm not sure it's a good idea.

What use case where you thinking whereby someone would call .canShare() on a non-fully active document?

@saschanaz
Copy link
Member

saschanaz commented Sep 3, 2021

On a second thought, I agree that following WebKit and making canShare fail (return false) makes the most sense since share() will anyway fail.

@marcoscaceres
Copy link
Member Author

Spoke to some folks over on the webkit side and they also suggested we use InvalidStateError. I've updated the PR to match.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants