DataCloneError in Safari/WebKit

[xollaborator]

Unfortunately, this library doesn't work with WebKit. Maybe current implementation will work once this old bug is fixed but it is already years old: https://bugs.webkit.org/show_bug.cgi?id=215485

In our investigation with @czarsbenemoriendi we found that the root cause is in creation of FileHandle in main thread and then using postMessage to pass it to worker which WebKit cannot serialize. We checked a simple fix and moved FileHandle creation to worker and that was enough to solved the issue. But of course it has impact on the performance in the benchmark that is part of this repo.

We do not want to decide how to approach the issue according to the vision of opfs-tools but the rough solution might be verified here: Dev-Familia/opfs-tools@599f65f

Would be nice to know what solution will be pursed for this issue. Let us know if we could help here more. Thanks.

[hughfenghen]

opfs-tools will strive to be compatible with Safari.

We checked a simple fix and moved FileHandle creation to worker and that was enough to solved the issue. But of course it has impact on the performance in the benchmark that is part of this repo.

This is the correct solution. In most cases, the 'register' operation is not executed frequently, so it should not have a significant impact on performance.

[hughfenghen]

Fixed in v0.3.2

[xollaborator]

@hughfenghen thanks, I can confirm this solution is working in Safari. However, the sourcemap for worker is triggering a console issue in Safari (screenshot below) and Firefox is not able to find it. This is only a minor discomfort during local development and from my perspective sourcemaps might be not generated.

Since the main problem is solved I would normally close the issue but I leave it to you to decide in case you would like to ask me to verify something.

Have a great day :)

[hughfenghen]

vitejs/vite#5417

One tricky edge case is the scenario where non-inline sourcemaps are being used with inline workers. In this case, the embedded comment has to use the full path (basepath + fileName) instead of simply using the file name. The tests don't address this case, partly because querying the inlined worker code would be pretty messy and it is something where manually running the playground catches the issue pretty easily.

Indeed, it is a tricky problem and I don't have a good way to solve it. The SourceMap file for the Worker is located here.