Safari: ArrayBuffers are sometimes not instanceof ArrayBuffer

[jvilk]

Summary

I'm storing and retrieving ArrayBuffer objects from IndexedDB, and I noticed that in my test environment, the ArrayBuffer objects are not always instanceof ArrayBuffer in Safari. As a result, the Buffer package throws the following exception:

TypeError: First argument must be a string, Buffer, ArrayBuffer, Array,or array-like object.

This behavior does not occur in any other web browser.

Detailed Explanation

The test environment is that of the Karma test runner, which uses an iframe to isolate test code from the runner's code. As a result, the ArrayBuffer constructor object in the code's context is not referentially equivalent to the ArrayBuffer constructor object in the main window context. This is similar to the age-old Array problem, where arrays from other contexts are not necessarily instanceof Array, necessitating the use of Array.isArray.

Safari chooses the main window's constructor for the ArrayBuffer object retrieved from IndexedDB, so it is not an instanceof ArrayBuffer in the test code's context.

Here's a screenshot, just so you know I'm not totally mad here. This is evaluated at a breakpoint in the stack frame that throws the TypeError:

I do not have a good solution to the problem without resorting to some hack (e.g., is the byteLength property present?).

[feross]

Interesting... instanceof is really quite terrible, isn't it?

Please see this PR with a potential solution: #170 Let me know if that works for you. If so, I'll merge it and do a new release.

[jvilk]

Interesting... instanceof is really quite terrible, isn't it?

I want to agree with you, but I can't really blame JavaScript on this one! instanceof is only intended to check if the object was constructed by a particular function, which is totally reasonable. I'd blame the unnecessarily complex native interface between JavaScript code and the web browser, which makes it possible to have multiple constructors for the same type of object! Really, browsers should have a special type of handoff between contexts that appropriately adjusts native objects like this one to use the appropriate constructor object. (Sharing constructors is a no-go for security reasons -- e.g., monkey-patching and such.)

With that said, it seems like the other browsers do not have this issue; perhaps they already use the appropriate constructor object from the context in which programs invoke native APIs that create ArrayBuffer objects. (That sentence is a mouthful...)

Please see this PR with a potential solution: #170 Let me know if that works for you.

I just ran my test suite against it, and it appears to work wonderfully!

Safari 10.1.2 (Mac OS X 10.12.6): Executed 667 of 667 SUCCESS (24.15 secs / 20.861 secs)

Thanks for fixing this!

[feross]

Released as 5.0.7

[maximerety]

Hi!

I found this bug report while investigating a similar issue (not using the buffer library) and wanted to add two things:

• Thank you very much for saving me a lot of time!
• I've filed an issue on Webkit Bugzilla: https://bugs.webkit.org/show_bug.cgi?id=185906, so that it might be fixed some day.

Best regards,

[feross]

@maximerety Thanks for sharing. Hope it gets fixed one day so we can remove this hack!

[jvilk]

@maximerety Thanks for reminding me of this issue! I just added a minimal complete test case to that bug report.