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

Throwing on detached buffers is not correct #29

Open
domenic opened this issue Apr 18, 2020 · 1 comment
Open

Throwing on detached buffers is not correct #29

domenic opened this issue Apr 18, 2020 · 1 comment

Comments

@domenic
Copy link
Member

domenic commented Apr 18, 2020

647d873 added throwing on detached buffers, but this is not correct. See whatwg/webidl#352 and whatwg/webidl#151 .

Sigh. I guess I just implemented that from memory.

@domenic
Copy link
Member Author

domenic commented Apr 18, 2020

I'm not sure the best way to handle this. I see a few options:

  1. Return a new empty array buffer (or corresponding view) when the incoming array buffer is detached. This is a bit tricky since then 99% of the time a non-throwing conversion returns the input, but sometimes it doesn't.

  2. Revert to having no special detached handling. This is similar to returning a new empty buffer in practice, since V8 treats detached buffers as zero-length buffers in most parts of the API.

  3. Implement the full " getting a reference to" / "getting a copy of" algorithms. This is not so great because specs generally don't use these algorithms yet and there's planned work to change them in https://www.w3.org/Bugs/Public/show_bug.cgi?id=28798.

  4. Try to implement https://www.w3.org/Bugs/Public/show_bug.cgi?id=28798. This seems kind of reasonable. However, any implementation that actually performs a copy would add a performance hit to jsdom. And I'm not sure that's really necessary given that we're single-threaded anyway?

I'm leaning toward (2), and potentially reassessing if we run into an API where this actually matters.

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

No branches or pull requests

1 participant