Closed SoftVision-CosminMuntean closed 5 years ago
We will follow up with ops and the add-ons team about how to handle signing (which is the underlying problem here). Maybe we could build signed versions with a different addon ID? The autograph-edge project by secops might be helpful here.
One fix for the mozillaAddons errors would be to install as a temporary addon:
This fixes the mozillaAddons permission error for me.
I'll add more on the other error in a moment.
@aswan Has embedded webextension startup changed recently? Seeing some weird errors (see traceback in description) when QA tests out Screenshots.
In the startup function for Screenshots, we do something like:
const webExtension = LegacyExtensionsUtils.getEmbeddedExtensionFor(...);
webExtension.startup(reason, data)
.then((api) => { // continue startup... })
When the above error is observed, webExtension.startup()
is now returning null, instead of a promise. It looks like this.startupPromise
is null at this line: https://dxr.mozilla.org/mozilla-central/source/toolkit/components/extensions/LegacyExtensionsUtils.jsm#204 . What's strange is that I've set breakpoints at all the spots inside that file where this.startupPromise
is set to null, and those lines aren't getting executed.
This error is reproducible by downloading the dev addon (right-click the ‘Install” link here: https://screenshots.dev.mozaws.net/homepage/install-test-local.html) then installing as a temporary addon via about:debugging.
Any thoughts on what we might be doing wrong here?
Is this a recent regression? More motivation to work on https://bugzilla.mozilla.org/show_bug.cgi?id=1422437 ? :)
@SoftVision-CosminMuntean Could you try to find a regression window? This looks like an upstream bug. I just built Firefox from today's mozilla-central (head hg commit a9dc5dc8e2) and, on startup, I'm seeing the same traceback in the browser console, but it's thrown by the webcompat legacy addon:
@6a68 indeed, it seems that both errors are regressions. I have found a regression window for both errors. Here are the results:
Last good revision: 6646425c8cd10440f2ce38cd594be0c84a7c21fa First bad revision: f6c89ca4944b0233e08463ce4825812c1b08373c Pushlog: https://goo.gl/P3avTW
It seems that bug 1369841 introduced this error.
Last good revision: 0514c55fb1d15577f4c4ab7e98a69b01b1aab139 First bad revision: d48657228a0b84cf3a37a35227ca3b3d0bd2a017 Pushlog: https://goo.gl/92PF19
From the obtained pushlog looks like bug 1431533 introduced this.
@SoftVision-CosminMuntean The addon built on dev should now be signed. Could you verify that, following the updated instructions on the install-test-local page (there's an additional pref), the 'stripping mozillaAddons permission' error is not shown? This will also be fixed on stage next time we do a stage release.
I have verified this issue using latest Screenshots 34.0.0 de version and the "stripping mozillaAddons permission" error is no longer displayed in browser console. Also now Screenshots works on PDF pages and Mozilla pages with the dev signed version. Tested on Windows 7 x64, Mac 10.13 and Arch Linux 4.12.
Thanks for fixing this!
[Affected versions]:
[Affected Platforms]:
[Prerequisites]:
[Steps to reproduce]:
[Expected result]:
[Actual results]:
[Notes]:
Here is a screenshots with browser console errors:![errors after installing the addon](https://user-images.githubusercontent.com/19226534/42102108-a78219fc-7bcd-11e8-9a0f-f8f2bb73564b.png)
Here is a screen recording with the issue:![errors after installing the addon](https://user-images.githubusercontent.com/19226534/42102095-9d849b32-7bcd-11e8-810e-9eabcd098e93.gif)