500 server error on the detail pages with Chrome/Edge

ioanarusiczki commented 3 years ago

Visit a detail page on AMO dev or AMO stage with Chrome/Edge. I used the latest builds from their settings : Version 89.0.774.48 (Official build) (64-bit) Microsoft Edge Version 89.0.4389.82 (Official Build) (64-bit) Chrome

Expected result: The pages load without errors

Actual result: 500 server error

I did not reproduce it on AMO prod. Also reproducible on 32-bit Windows.

detail pages

bobsilverberg commented 3 years ago

I'll see if I can reproduce and if I can track down the issue.

bobsilverberg commented 3 years ago

It looks like it's a problem coming from the base64url package. I'll check if we've updated that recently.

bobsilverberg commented 3 years ago

We didn't update it directly, but its lockfile entry was changed via the Webpack upgrade (https://github.com/mozilla/addons-frontend/commit/f40fe6262dfb61789e319c1e859e67df5254f5fa).

willdurand commented 3 years ago

It looks like it's a problem coming from the base64url package. I'll check if we've updated that recently.

This looks like a node-only package.

bobsilverberg commented 3 years ago

Here's the error from the console:

base64url.js:6 Uncaught ReferenceError: Buffer is not defined
    at Function.encode (base64url.js:6)
    at GetFirefoxButtonBase (index.js:83)
    at renderWithHooks (react-dom.development.js:14938)
    at mountIndeterminateComponent (react-dom.development.js:17617)
    at beginWork (react-dom.development.js:18731)
    at HTMLUnknownElement.callCallback (react-dom.development.js:182)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:231)
    at invokeGuardedCallback (react-dom.development.js:286)
    at beginWork$1 (react-dom.development.js:23338)
    at performUnitOfWork (react-dom.development.js:22292)

bobsilverberg commented 3 years ago

It looks like it's a problem coming from the base64url package. I'll check if we've updated that recently.

This looks like a node-only package.

Why would this be causing a problem now? The problem is absent on prod. Is it related to Webpack?

willdurand commented 3 years ago

Why would this be causing a problem now? The problem is absent on prod. Is it related to Webpack?

probably because the browserslist update removed a node polyfill that was working in the browser

bobsilverberg commented 3 years ago

I notice the stack trace includes react-dom.development.js. Is it that we are using that in dev and stage but not in prod? I wonder if possibly this problem has been around for more that just this release?

willdurand commented 3 years ago

I think we should use something like: https://github.com/blakeembrey/universal-base64url

bobsilverberg commented 3 years ago

I think we should use something like: blakeembrey/universal-base64url

I can try that.

willdurand commented 3 years ago

I notice the stack trace includes react-dom.development.js. Is it that we are using that in dev and stage but not in prod? I wonder if possibly this problem has been around for more that just this release?

That is.. weird.

Edit: is this the stack from -dev? I am seeing the production lib on -dev with Chrome, which is expected.

bobsilverberg commented 3 years ago

I notice the stack trace includes react-dom.development.js. Is it that we are using that in dev and stage but not in prod? I wonder if possibly this problem has been around for more that just this release?

That is.. weird.

Edit: is this the stack from -dev? I am seeing the production lib on -dev with Chrome, which is expected.

Sorry, that's locally. So just ignore me. 😛

willdurand commented 3 years ago

Note: I think the problem occurs on non-FF browsers because the base64 lib is used for the RTAMO feature.

bobsilverberg commented 3 years ago

That fixes it. I'll make a patch.

willdurand commented 3 years ago

Note: I think the problem occurs on non-FF browsers because the base64 lib is used for the RTAMO feature.

@ioanarusiczki could you please test the rtamo feature if that's possible?

ioanarusiczki commented 3 years ago

the detail pages are displayed without errors with Edge and Chrome on -dev and -stage testing servers.
I tested rtamo on -dev and - stage with the following steps using Windows Sandbox:
1. Opened Windows Sandbox and using the Edge browser I opened a detailed page on -dev and -stage -> the addon is recommended
2. I tapped on “Only with Firefox - Get Firefox Now” and installed FF release from the page opened
3. I closed the tabs for the installed firefox and downloaded a nightly/unbranded FF86 version
4. in the first tab with about:config I changed the pref: "extensions.getAddons.get.url" to point to dev/stage
5. into another tab I wrote manually: about:welcome and I checked the page

Result: The recommended add-on was displayed I could install the add-on with FF86 Unbranded and checked that it's also present into the about:addons - extension tab.

dev cu nightly

Note: Testing with -dev and -stage require workarounds, I wrote the about:welcome manually into a tab for the nightly/unbranded versions, it's also been tested with AMO prod - release version and an issue was found and filed here by @acornestean -> https://bugzilla.mozilla.org/show_bug.cgi?id=1697793. (which is not reproducible for AMO prod with nightly, beta and unbranded ff versions).

I think this issue can be marked verified because it proves that base64 lib works for RTAMO.

mozilla / addons

500 server error on the detail pages with Chrome/Edge #14010