Chrome Extension: window is not defined for background scripts

[subzero10]

Looks like window is not available in background scripts.

Bug first reported here.

[joshuap]

Hmmm. I would love to avoid a situation where we have to guard access to window in the browser client. 🤔

That said, something similar came up w/ someone who was trying to integrate with a Cloudflare worker (which is also on my integration wishlist).

[christianopaets]

Instead of window we can use self. I have tried to to use smth like global.window = self and the error disapeared. But there is another problem)) document also doesn't exists.

And service worker uses only fetch API

[christianopaets]

@subzero10 any updates on this?

[subzero10]

Hey @christianopaets, I haven't looked into this since January. It's in my todo list, I will try to bump it up.

[lbaron-ut]

It would be really useful when working with a Browser extension as manifest v3 is becoming the norm...

[zhanfengh]

Hello, we run a popular Chrome extension. And Honeybadger is an essential component of error reporting for us.

Google Chrome has mandated all Chrome extensions to be migrated to Manifest V3 and one of the notable changes of MV3 is that it replaces background pages with service workers. The DOM and XMLHttpRequest() are not available in service workers, which makes Honeybadger to error out.

We tried to fork and patch the library to make it compatible with service workers by replacing window with self when it's possible and XMLHTTPRequest() with fetch(). But we kept running into issues with a lot of different window/document calls within the library and couldn't figure out a clean way to fix them all.

It would be nice if you can look into this issue and make Honeybadger compatible with Manifest V3 soon as Google Chrome will not accept any extensions without MV3 after June 2023 and will actively remove them after Jan 2024. https://developer.chrome.com/blog/more-mv2-transition/

[subzero10]

Hey @zhanfengh, thank you for your insights and feedback. Then, I guess I should look into this before the EOY!
cc @joshuap

[guest271314]

You can alternatively substitute globalThis for self console.assert(globalThis === self).

It looks like XMLHttpRequest is referenced in /src/browser/transport.ts, src/browser/integrations/breadcrumbs.ts, and test.js.

For transport.ts you can do something like this, substituting arrayBuffer() for text(), json(), blob(), or formData() where appropriate

    return new Promise(async (resolve, reject) => {
      try {
        const headers = new Headers();
        if (Object.keys(options.headers || []).length) {
          for (const i in options.headers) {
            if (typeof options.headers[i] !== 'undefined') {
              headers.set(i, String(options.headers[i]))
            }
          }
        }
        const x = await fetch(options.endpoint, {
          method: options.method, 
          body: payload ? JSON.stringify(sanitize(payload, options.maxObjectDepth)) : ''
          headers
        });
        resolve({ statusCode: x.status, body: await x.text() })
      } catch (err) {
        reject(err)
      }
    })

[subzero10]

Thanks @guest271314, I will try this out!

[KonnorRogers]

Alright, theres a ton of calls beyond the transport.ts file mentioned, thats probably just the first code path that gets hit. we make a lot of calls to window objects and XMLHTTPRequest, I'm gonna keep plugging through it, but heres an initial PR for what the transport.ts would be refactored to, PR is WIP as it'll be a fairly large refactor.

#958

[subzero10]

Hey all, we just released v4.8.0 which should support running honeybadger in non-dom environments (chrome extension, background workers)!
I'm closing this ticket, but don't hesitate to open again if you find issues.