azure-sdk-for-js: Core-http and potentially storage-blob do not work from web worker

Package Name: core-http and possibly storage-blob
Package Version: @azure/core-http@1.1.7, @azure/storage-blob@12.2.0-preview.1
Operating system: macOS 10.15.6
nodejs
- version:
browser
- name/version: Chrome 85.0.4183.83
typescript
- version:
Is the bug related to documentation in
- README.md
- source code documentation
- SDK API docs on https://docs.microsoft.com

Describe the bug Unable to use @azure/storage-blob package in a context of web worker. Attempting to load it fails with error

Uncaught ReferenceError: document is not defined
    at Module../node_modules/@azure/core-http/es/src/util/xml.browser.js (xml.browser.ts:5)
    at __webpack_require__ (bootstrap:19)
    at Module../node_modules/@azure/core-http/es/src/policies/deserializationPolicy.js (deserializationPolicy.ts:1)
    at __webpack_require__ (bootstrap:19)
    at Module../node_modules/@azure/core-http/es/src/serviceClient.js (serviceClient.ts:1)
    at __webpack_require__ (bootstrap:19)
    at Module../node_modules/@azure/core-http/es/src/coreHttp.js (coreHttp.ts:1)
    at __webpack_require__ (bootstrap:19)
    at Module../node_modules/@azure/storage-blob/dist-esm/storage-blob/src/index.browser.js (index.browser.ts:1)
    at __webpack_require__ (bootstrap:19)

The cause of the issue is that document is not available inside WebWorkers.

To Reproduce

Steps to reproduce the behavior: I created a sample repo showcasing the issue https://github.com/Obi-Dann/azure-storage-blob-worker-issue based on Create React App

Clone the repository locally
Run yarn install
Run yarn start which will open a web browser eventually
Open browser devtools and observe the error

Expected behavior I should be able to use @azure/storage-blob package running it inside a web worker context.

Additional context I have a web worker process compressing images in background and then uploading them to Azure storage blob. I can only think of sending messages with file buffers/links to the main app from the worker in order to get the files uploaded, but that does not seem very maintainable in my case because the worker needs to do more work once the file is uploaded.

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 5
Comments: 18 (12 by maintainers)

Commits related to this issue

[Linter] Add a linter rule to prevent usage of `window` (#13873) ## What - Adds a rule to prevent usage of `window` and prefer `self` instead ## Why - This came up recently in a few cases: #... — committed to Azure/azure-sdk-for-js by maorleger 3 years ago
Add sample for using storage-blob in web workers (#14809) ## What - Adds a helpful error message about missing global DOM APIs when using core-xml / core-http in web workers - Adds a sample and ... — committed to Azure/azure-sdk-for-js by maorleger 3 years ago
Add sample for using storage-blob in web workers (#14809) ## What - Adds a helpful error message about missing global DOM APIs when using core-xml / core-http in web workers - Adds a sample and ... — committed to jay-most/azure-sdk-for-js by maorleger 3 years ago

Most upvoted comments

Thanks @salqueng! There’s also an issue with https://github.com/Azure/azure-sdk-for-js/blob/99f531906125f2d22a613957571a32ca792d009d/sdk/core/core-http/src/policies/msRestUserAgentPolicy.browser.ts#L21 which should be quite easy to fix by replacing window.navigator with self.navigator

Obi-Dann on Sep 8, 2020

A workaround is below here. Import or place this code at the top of your web worker code. The idea is using 3rd party DOM parser library(xmldom), which is compatible with browser APIs, and mocking document and window.

import { DOMParser, DOMImplementation, XMLSerializer } from "xmldom";

self.DOMParser = DOMParser;
self.XMLSerializer = XMLSerializer;

self.document = {
  implementation: new DOMImplementation(),
};

self.window = {
  navigator,
};

There is a workaround, but I want to use @azure/storage-blob without any strange mocking and 3rd party library.

salqueng on Sep 8, 2020

@WillemDuPlessis Thanks for sharing the repro code. It feels that our storage module got loaded before the polyfill. I am not familiar with comlink-loader. We will investigate more.

jeremymeng on Jan 27, 2021

@WillemDuPlessis could you please share what issues you are having when trying the workaround?

jeremymeng on Jan 26, 2021

We should replace window.navigator with self.navigator, agree with @Obi-Dann there.

I worry about adding yet another required dependency in the browser, but a way to plug in xml2js when you need it seems like a good idea, possibly in addition to making missing xml a late error when you use functionality that depends on it. @jeremymeng is this late error a possibility, or is XML used in too many core scenarios for it to be worth it?

bterlson on Sep 22, 2020

We already pull in xml2js for the node case, presumably we may be able to leverage this for the browser case as well (in exchange for bundle expansion, of course.)

xirzec on Sep 21, 2020