Closed ioanarusiczki closed 3 years ago
I'll see if I can reproduce and if I can track down the issue.
It looks like it's a problem coming from the base64url
package. I'll check if we've updated that recently.
We didn't update it directly, but its lockfile entry was changed via the Webpack upgrade (https://github.com/mozilla/addons-frontend/commit/f40fe6262dfb61789e319c1e859e67df5254f5fa).
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.
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)
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?
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
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?
I think we should use something like: https://github.com/blakeembrey/universal-base64url
I think we should use something like: blakeembrey/universal-base64url
I can try that.
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.
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. 😛
Note: I think the problem occurs on non-FF browsers because the base64 lib is used for the RTAMO feature.
That fixes it. I'll make a patch.
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?
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:
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.
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.
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.