1518863 - Blank new tab page displayed on start when an add-on controls the new tab page (due to race between page load and extension startup)

Status: VERIFIED FIXED

(WebExtensions :: General, defect, P1)

Description

[Carlos R. Colon]

Attachment: blank _page.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

On Firefox Beta 65.0b6 and Nightly 66.0a1, completed the following steps:

1. Installed Web extension that takes over new tab.
2. Verified New tab page is displayed after successful install.
3. Closed browser using X button on top right.
4. Re-opened browser and verified page is blank.

Actual results:

After browser restart blank page is displayed due to browser JS error.

Error Message:
Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIWebNavigation.loadURIWithOptions]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: resource://gre/actors/WebNavigationChild.jsm :: loadURI/< :: line 114" data: no]

Error Stack:
loadURI resource://gre/actors/WebNavigationChild.jsm:114 _wrapURIChangeCall resource://gre/actors/WebNavigationChild.jsm:63 loadURI resource://gre/actors/WebNavigationChild.jsm:113 receiveMessage resource://gre/actors/WebNavigationChild.jsm:43 receiveMessage resource://gre/modules/ActorManagerChild.jsm:160

Expected results:

After browser restart default new tab should be displayed.

Comment 1

[Matthias Versen [:Matti]]

It would help if you could provide an example of an webextension that is required for this test ?

Comment 2

[Carlos R. Colon]

Attachment: Video demonstrating issue

Attached video illustrating issue.

Comment 3

[Carlos R. Colon]

Attachment: fromdoctopdf web extension for testing

Comment 4

[Matthias Versen [:Matti]]

I can confirm the bug with Firefox 65beta and Firefox66 while it works in Firefox64.

Finding a regression range is difficult because a browser restart is required after installing the extension and you have to always test with a clean profile.
The restart button in about:profiles will restart but with a default profile.

moving to async tooling where WebNavigationChild.jsm lives but this very likely incorrect but I have no clue how to proceed.

Comment 5

[Alice0775 White]

str:

1. Install the test addon
2. Exit browser.
3. Restart browser
4. Repeat step 2 and 3 for a couple of times(at least 2 times)

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=26598a115edd552ce42fe28561d7b71158f06298&tochange=d05c6310d573658af4a4f2cee332bb01732fcabf

Suspect: d05c6310d573 Gijs Kruitbosch — Bug 1509906 - use the window's initial url to determine what remoteType the initial browser should have, r=dao,mconley

Comment 6

[Matthias Versen [:Matti]]

Thank you very much Alice !

Comment 7

[:Gijs (he/him)]

[Tracking Requested - why for this release]:
Regression in browser startup behavior; unclear how many users this will affect.

Comment 8

[:Gijs (he/him)]

It doesn't help that this add-on can't be unzipped on macOS...

Comment 9

[Carlos R. Colon]

We were able to upzip web extension on macOS using Keka. This bug affects both windows and mac users.

Comment 10

[:Gijs (he/him)]

We seem to be losing some kind of race against webextension startup here. I don't understand what and I don't really see how to debug. I see the same problem but without the exception in the console if I run with --disable-e10s .

I don't see a big difference between this and bug 1490260. bug 1509906 clearly made it more likely that we lose whatever race it is. Backing it out would help a little, but the fundamental bug would still exist.

Mike, are we shipping the privileged content process on beta/release? If not, I guess we could consider backing out bug 1509906 only on beta...

Comment 11

[Mike Conley (:mconley) (:⚙️)]

(In reply to :Gijs (he/him) from comment #10)

Mike, are we shipping the privileged content process on beta/release? If not, I guess we could consider backing out bug 1509906 only on beta...

The privileged content process is stuck to Nightly for now - so yeah, I think it's reasonable to investigate backing out bug 1509906.

Comment 12

[:Gijs (he/him)]

(In reply to :Gijs (he/him) from comment #10)

We seem to be losing some kind of race against webextension startup here. I don't understand what and I don't really see how to debug. I see the same problem but without the exception in the console if I run with --disable-e10s .

OK, so the issue is that we try to load the URI, we end up trying to resolve the URI because it's a moz-extension URI, and we end up at https://searchfox.org/mozilla-central/rev/b29663c6c9c61b0bf29e8add490cbd6bad293a67/netwerk/protocol/res/SubstitutingProtocolHandler.cpp#235 which returns NS_ERROR_NOT_AVAILBLE because the host for the moz-extension URI hasn't been registered yet. To properly fix this, we would need to make the code that tries to load tabs/URLs here wait for this registration to have happened (or somehow force it to happen immediately at the point where we try to load the URI). But AFAICT the webextension code doesn't expose this. Andrew/Kris, did I miss something? Is this exposed somewhere today, and if not, what would be the most straightforward way of doing so? Browser code can probably send a list of moz-extension URIs it cares about if that helps.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Bug 1509906 has been backed out from Beta for 65.0b11+ at Gijs' request.

https://hg.mozilla.org/releases/mozilla-beta/rev/8f38ca46fb44

Comment 14

[Andrew Swan [:aswan]]

The moz-extension handler resolves URL swith this method which relies on a WebExtensionPolicy object having been created:
https://searchfox.org/mozilla-central/rev/b29663c6c9c61b0bf29e8add490cbd6bad293a67/dom/chrome-webidl/WebExtensionPolicy.webidl#183

In the parent process, we create a stub policy object early in extension startup:
https://searchfox.org/mozilla-central/rev/b29663c6c9c61b0bf29e8add490cbd6bad293a67/toolkit/components/extensions/Extension.jsm#1815

This works during browser startup since the addon manager starts up quite early we're able to get into this statup code before any asynchronous operations. Things are a little more complicated for child processes, the actual policy object is created from ExtensionProcessScript.jsm, based on either a list of extensions kept in sharedData for a new process, or the Extension:Startup message for an already-running process. But setting up sharedData and sending the startup message both happen in Extension.runManifest(), and there are asynchronous I/O operations that have to complete before that runs.

That certainly leaves time for a child process to try to load a moz-extension URL before the policy object is created in the child process. It looks like before bug 1509906, extension pages began loading in a web content process and the time it took to switch to the extension process gave time to get a policy set up. And post bug 1509906, the load starts out in the extension process but now frequently starts before the policy is set up.

Off the top of my head, it seems like we could solve this in the parent process or the child process. To solve it in the parent process we would hold LoadURI messages for moz-extension: urls if the corresponding extension isn't yet fully started (we should have a policy object in the parent process for all active extensions, even those that are still starting up, and each Extension instance has a startupPromise that we could wait on, but we'll probably need to do some plumbing to expose it). That feels ad hoc and hacky though. We could also create a stub policy object early on in the child process to mirror what we do in the parent process, Kris just reacted negatively to that on IRC though.

Leaving the ni? for Kris for him to weigh in before we proceed...

Comment 15

[:Gijs (he/him)]

Just to make sure this is on record somewhere, https://searchfox.org/mozilla-central/rev/b29663c6c9c61b0bf29e8add490cbd6bad293a67/toolkit/components/extensions/Extension.jsm#1818 is the wrong URI to pass as baseURL, we really want this.resourceURL. However, that alone gets you a non-functioning page in non-e10s (due to bug 1490260) and doesn't really fix the problem for e10s either.

Per discussion on IRC, it's likely we want to make moz-extension channels effectively wait for add-on initialization in AsyncOpen. This would make moz-extension loads more transparently wait for add-on startup than trying to catch this case on the caller's side (and playing whack-a-mole with callers), but it requires some changes to the moz-extension internal code and potentially how we get info to the extension process. Kris said he'd take a look at this after he finishes some other stuff he's working on.

Comment 16

[:Gijs (he/him)]

I'll take a stab at this later this week unless kmag beats me to it.

Comment 17

[:Gijs (he/him)]

Talked to kmag as I wasn't getting very far with this; he's going to take this on.

Comment 18

[Sergey Martynov]

the bug is reproduced pm 66.0b3 Beta

Comment 19

[Tim Spurway [:tspurway]]

Kris, any progress on this one? Any chance we'd have something for 66?

Comment 21

[Trishul]

Thanks @aswan for pointing this bug.
I got this bug on Firefox released version 65.0

Demo video - https://drive.google.com/file/d/1qmpWReCkd53V56wqbwaRD2Lq4RegKbAW/view?usp=sharing

Comment 22

[Sergey Martynov]

Kris, any update on the fix or changes revert?
66.0b9 beta have this bug.

Comment 23

[Liz Henry (:lizzard) (relman/hg->git project)]

Is there anyone other than kmag who can fix this for 66?

Comment 24

[Liz Henry (:lizzard) (relman/hg->git project)]

Depending on how common we think this is for users, we may want to declare this a release blocker for 66. Since we have at least 3 users reporting this in beta, I am concerned this might be a widespread problem on release, and since we did a backout for this in late 65 beta, this will be a new regression in 66.

Comment 25

[Dão Gottwald [:dao]]

aswan maybe?

Comment 26

[Dão Gottwald [:dao]]

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #24)

Depending on how common we think this is for users, we may want to declare this a release blocker for 66. Since we have at least 3 users reporting this in beta, I am concerned this might be a widespread problem on release, and since we did a backout for this in late 65 beta, this will be a new regression in 66.

Looks like you set the flag for the wrong release.

Comment 27

[Andrew Swan [:aswan]]

It would be a stretch for me to do this at all. I'm certain I couldn't do it in time for 66. Regardless of who ends up doing it, I think the proposed implementation would not be a good beta uplift candidate in any case (its going to be a large-ish patch)

Comment 28

[Kris Maglione [:kmag]]

Attachment: Bug 1518863: Part 0 - Minor extension protocol handler cleanup. r=aswan

These are trivial issues that I'd rather keep out of the main patch.

Comment 29

[Kris Maglione [:kmag]]

Attachment: Bug 1518863: Part 1 - Add ready promise to WebExtensionPolicy. r=aswan

This adds a promise member to the stub WebExtensionPolicy objects that we
create early during extension initialization which resolves when the real
extension instance is ready to load content. This promise will be used by the
extension protocol handler to delay loads until the framework is ready to
handle them.

Comment 30

[Kris Maglione [:kmag]]

Attachment: Bug 1518863: Part 2 - Delay extension protocol requests until extension is ready. r=aswan

We don't want extension protocol load requests to begin loading until the
extension is far enough initialized to run code. If we load it before then,
the extension framework will either fail to recognize the extension entirely,
or may begin running its scripts in an incomplete environment.

This patch adds a slow path which adds a promise handler and creats a stub
channel only in the case when the extension is not ready. In the normal,
already-initialized case, we take the more direct path.

Comment 31

[Kris Maglione [:kmag]]

Attachment: Bug 1518863: Part 3 - Initialize stub extension policies in child during startup. r=aswan

We already create early stub policy objects in the parent process during
extension startup, so that early load attempts and policy queries can succeed
during startup and extension installation. This patch does the same for child
processes, which likewise may be asked to load extension URLs early during
startup when they override the homepage or have pages loaded from session
restore.

Comment 32

[Kris Maglione [:kmag]]

Attachment: Bug 1518863: Part 4 - Add tests. r=aswan

Comment 33

[Kris Maglione [:kmag]]

Attachment: Bug 1518863: Part 5 - More extension protocol handler cleanup. r=aswan

This is not strictly related to the rest of the patches, but it was annoying
me while I wrote them.

Comment 34

[Kris Maglione [:kmag]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/00c8f747679c38145ed1f4f8eb11253dea0ba068
Bug 1518863: Part 0 - Minor extension protocol handler cleanup. r=aswan

https://hg.mozilla.org/integration/mozilla-inbound/rev/1ea765143cded7a55ff89ba5302db2bb63aac068
Bug 1518863: Part 1 - Add ready promise to WebExtensionPolicy. r=aswan

https://hg.mozilla.org/integration/mozilla-inbound/rev/606364d19a36c4f6598b707bdd8fbc646ce88075
Bug 1518863: Part 2 - Delay extension protocol requests until extension is ready. r=aswan

https://hg.mozilla.org/integration/mozilla-inbound/rev/e75922833e757d0012dfa3b01779091bd28fbdb9
Bug 1518863: Part 3 - Initialize stub extension policies in child during startup. r=aswan

https://hg.mozilla.org/integration/mozilla-inbound/rev/05528e4ad2fed74be18afd20be32375c8a8ea42e
Bug 1518863: Part 4 - Add tests. r=aswan

https://hg.mozilla.org/integration/mozilla-inbound/rev/5b59b3bf72d880c4b3e05156ef329854075b24f8
Bug 1518863: Part 5 - More extension protocol handler cleanup. r=aswan

Comment 35

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/mozilla-central/rev/00c8f747679c
https://hg.mozilla.org/mozilla-central/rev/1ea765143cde
https://hg.mozilla.org/mozilla-central/rev/606364d19a36
https://hg.mozilla.org/mozilla-central/rev/e75922833e75
https://hg.mozilla.org/mozilla-central/rev/05528e4ad2fe
https://hg.mozilla.org/mozilla-central/rev/5b59b3bf72d8

Comment 37

[Florin Strugariu [:Bebe]]

Small perf regrsion in 1532224

Comment 38

[Liz Henry (:lizzard) (relman/hg->git project)]

Here we have a choice of shipping with this in 66 (we disabled it in 65 I believe) or trying for uplift in the beta 14 build. I'll discuss with the product team.

Comment 39

[Liz Henry (:lizzard) (relman/hg->git project)]

After discussion and looking at bug 1509906 I think our best option is to bring this to the RC build.
Kris, can you request uplift? Thanks.

Comment 40

[Kris Maglione [:kmag]]

Comment on attachment 9047205 [details]
Bug 1518863: Part 4 - Add tests. r=aswan

Beta/Release Uplift Approval Request

• Feature/Bug causing the regression: Bug 1509906
• User impact if declined: Users with home pages provided by extensions will generally see a blank page at startup. In some cases, pages from the extension will fail to work for the rest of the browser session.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Should be described in earlier comments
• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): The patch is relatively complex, but in practice should only impact users who are already seeing this bug. Extension page loads that happen after extension startup is complete should still use the behavior.
• String changes made/needed:

Comment 41

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 9047205 [details]
Bug 1518863: Part 4 - Add tests. r=aswan

Fix for issue with extensions that modify the home/new tab page.
Let's uplift for the RC build.

Comment 42

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 9047204 [details]
Bug 1518863: Part 3 - Initialize stub extension policies in child during startup. r=aswan

Uplift parts 0-4, leaving part 5 to ride with 67.

Comment 43

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/releases/mozilla-beta/rev/0379572257905b9f89f87c8efdb5e0b96dad6d2c
https://hg.mozilla.org/releases/mozilla-beta/rev/b7e78201e26c6bcfc297f63b89454cde29a09bce
https://hg.mozilla.org/releases/mozilla-beta/rev/4d96aa8bbf572eba63bc7d0d6ccfee494869702b
https://hg.mozilla.org/releases/mozilla-beta/rev/d94de0e08f52bbfb54a140462b0a4d2fb5e84477
https://hg.mozilla.org/releases/mozilla-beta/rev/11506a4e0fd8088f20b70a27e96e9b3170c9d5fb

Comment 44

[Bogdan Tara[:bogdan_tara | bogdant]]

Backed out 5 changesets (Bug 1518863) For ES Lint failure

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta&revision=11506a4e0fd8088f20b70a27e96e9b3170c9d5fb&selectedJob=232832538

Backout link: https://hg.mozilla.org/releases/mozilla-beta/rev/e1652912e1d567f8ea49246ed6ee550920afe616

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=232832538&repo=mozilla-beta&lineNumber=272

[vcs 2019-03-09T01:23:20.621Z] 270085 files updated, 0 files merged, 0 files removed, 0 files unresolved
[vcs 2019-03-09T01:23:20.987Z] updated to 11506a4e0fd8088f20b70a27e96e9b3170c9d5fb
[vcs 2019-03-09T01:23:21.011Z] PERFHERDER_DATA: {"framework": {"name": "vcs"}, "suites": [{"extraOptions": ["c3.xlarge"], "lowerIsBetter": true, "name": "clone", "shouldAlert": false, "subtests": [], "value": 128.79081392288208}, {"extraOptions": ["c3.xlarge"], "lowerIsBetter": true, "name": "update", "shouldAlert": false, "subtests": [], "value": 113.2223949432373}, {"extraOptions": ["c3.xlarge"], "lowerIsBetter": true, "name": "overall", "shouldAlert": false, "subtests": [], "value": 242.40666818618774}, {"extraOptions": ["c3.xlarge"], "lowerIsBetter": true, "name": "overall_clone", "shouldAlert": false, "subtests": [], "value": 242.40666818618774}, {"extraOptions": ["c3.xlarge"], "lowerIsBetter": true, "name": "overall_clone_fullcheckout", "shouldAlert": false, "subtests": [], "value": 242.40666818618774}]}
[vcs 2019-03-09T01:23:21.332Z] TinderboxPrint:<a href=https://hg.mozilla.org/releases/mozilla-beta/rev/11506a4e0fd8088f20b70a27e96e9b3170c9d5fb title='Built from mozilla-beta revision 11506a4e0fd8088f20b70a27e96e9b3170c9d5fb'>11506a4e0fd8088f20b70a27e96e9b3170c9d5fb</a>
[task 2019-03-09T01:23:21.333Z] executing ['bash', '-cx', 'cd /builds/worker/checkouts/gecko/ && cp -r /build/node_modules_eslint node_modules && ln -s ../tools/lint/eslint/eslint-plugin-mozilla node_modules && ln -s ../tools/lint/eslint/eslint-plugin-spidermonkey-js node_modules && ./mach lint -l eslint -f treeherder --quiet\n']
[task 2019-03-09T01:23:21.344Z] + cd /builds/worker/checkouts/gecko/
[task 2019-03-09T01:23:21.344Z] + cp -r /build/node_modules_eslint node_modules
[task 2019-03-09T01:23:22.535Z] + ln -s ../tools/lint/eslint/eslint-plugin-mozilla node_modules
[task 2019-03-09T01:23:22.537Z] + ln -s ../tools/lint/eslint/eslint-plugin-spidermonkey-js node_modules
[task 2019-03-09T01:23:22.537Z] + ./mach lint -l eslint -f treeherder --quiet
[task 2019-03-09T01:23:23.324Z] New python executable in /builds/worker/checkouts/gecko/obj-x86_64-pc-linux-gnu/_virtualenvs/init/bin/python2.7
[task 2019-03-09T01:23:23.324Z] Also creating executable in /builds/worker/checkouts/gecko/obj-x86_64-pc-linux-gnu/_virtualenvs/init/bin/python
[task 2019-03-09T01:23:24.941Z] Installing setuptools, pip, wheel...done.
[task 2019-03-09T01:23:26.048Z] running build_ext
[task 2019-03-09T01:23:26.048Z] building 'psutil._psutil_linux' extension
[task 2019-03-09T01:23:26.048Z] creating build
[task 2019-03-09T01:23:26.048Z] creating build/temp.linux-x86_64-2.7
[task 2019-03-09T01:23:26.048Z] creating build/temp.linux-x86_64-2.7/psutil
[task 2019-03-09T01:23:26.048Z] x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -DPSUTIL_POSIX=1 -DPSUTIL_VERSION=543 -DPSUTIL_LINUX=1 -I/usr/include/python2.7 -c psutil/_psutil_common.c -o build/temp.linux-x86_64-2.7/psutil/_psutil_common.o
[task 2019-03-09T01:23:26.048Z] x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -DPSUTIL_POSIX=1 -DPSUTIL_VERSION=543 -DPSUTIL_LINUX=1 -I/usr/include/python2.7 -c psutil/_psutil_posix.c -o build/temp.linux-x86_64-2.7/psutil/_psutil_posix.o
[task 2019-03-09T01:23:26.048Z] x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -DPSUTIL_POSIX=1 -DPSUTIL_VERSION=543 -DPSUTIL_LINUX=1 -I/usr/include/python2.7 -c psutil/_psutil_linux.c -o build/temp.linux-x86_64-2.7/psutil/_psutil_linux.o
[task 2019-03-09T01:23:26.048Z] creating build/lib.linux-x86_64-2.7
[task 2019-03-09T01:23:26.048Z] creating build/lib.linux-x86_64-2.7/psutil
[task 2019-03-09T01:23:26.048Z] x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wl,-Bsymbolic-functions -Wl,-z,relro -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security build/temp.linux-x86_64-2.7/psutil/_psutil_common.o build/temp.linux-x86_64-2.7/psutil/_psutil_posix.o build/temp.linux-x86_64-2.7/psutil/_psutil_linux.o -o build/lib.linux-x86_64-2.7/psutil/_psutil_linux.so
[task 2019-03-09T01:23:26.048Z] building 'psutil._psutil_posix' extension
[task 2019-03-09T01:23:26.048Z] x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -DPSUTIL_POSIX=1 -DPSUTIL_VERSION=543 -DPSUTIL_LINUX=1 -I/usr/include/python2.7 -c psutil/_psutil_common.c -o build/temp.linux-x86_64-2.7/psutil/_psutil_common.o
[task 2019-03-09T01:23:26.048Z] x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -DPSUTIL_POSIX=1 -DPSUTIL_VERSION=543 -DPSUTIL_LINUX=1 -I/usr/include/python2.7 -c psutil/_psutil_posix.c -o build/temp.linux-x86_64-2.7/psutil/_psutil_posix.o
[task 2019-03-09T01:23:26.048Z] x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wl,-Bsymbolic-functions -Wl,-z,relro -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security build/temp.linux-x86_64-2.7/psutil/_psutil_common.o build/temp.linux-x86_64-2.7/psutil/_psutil_posix.o -o build/lib.linux-x86_64-2.7/psutil/_psutil_posix.so
[task 2019-03-09T01:23:26.048Z] copying build/lib.linux-x86_64-2.7/psutil/_psutil_linux.so -> psutil
[task 2019-03-09T01:23:26.048Z] copying build/lib.linux-x86_64-2.7/psutil/_psutil_posix.so -> psutil
[task 2019-03-09T01:23:26.048Z]
[task 2019-03-09T01:23:26.048Z] Error processing command. Ignoring because optional. (optional:packages.txt:comm/build/virtualenv_packages.txt)
[task 2019-03-09T01:28:54.637Z] TEST-UNEXPECTED-ERROR | /builds/worker/checkouts/gecko/toolkit/components/extensions/test/xpcshell/test_ext_startup_request_handler.js:10:21 | Cu.import imports into variables and into global scope. (mozilla/no-import-into-var-and-global)
[taskcluster 2019-03-09 01:28:55.200Z] === Task Finished ===
[taskcluster 2019-03-09 01:28:55.200Z] Unsuccessful task run with exit code: 1 completed in 634.248 seconds

Comment 45

[Liz Henry (:lizzard) (relman/hg->git project)]

Re-landed by kmag, https://hg.mozilla.org/releases/mozilla-beta/rev/6719bb90ce8a

Comment 46

[Peter deHaan [:pdehaan]]

This worked for me on macOS Mojave (10.14.3) on Firefox 66.0 (64-bit) using the attached "fromdoctopdf" add-on in a new profile.
In a clean profile my default new tab page was activity stream. After installing the fromdoctopdf add-on, my homepage changed. After closing and reopening my browser (with the same profile) the custom fromdoctopdf homepage takeover persisted (tested by closing and reopening browsers a few time and spamming the new tab button). After uninstalling the fromdoctopdf add-on, my homepage cleanly reverted back to the default activity stream new tab page, as expected.

Comment 47

[krupa raj [:krupa--use this to needinfo]]

awaiting additional testing by Cosmin or Vlad before this bug is marked as verified.

Comment 48

[Vlad Jiman]

We've ran tests on FF 67.0a1, 66.0 and using Windows 10 x64, Mac OSX 10.14.1 and Ubuntu 18.04.1 LTS with the attached extension.
New profiles were used with multiple browser restarts and new tabs open and also by disabling/enabling/uninstalling the test extension in order to cover all flows. The described error is not showing in the browser console and neither is a blank page instead of the extension's new tab on these Fx versions.

Note: We were unable to reproduce in Firefox 65.0.2

Comment 50

[Thomas Werner]

For me the fix is working too but not for "debugging" (but not really important just FYI):

Steps to reproduce:

1. Install an extension from AMO which controls the new tab and homepage where you own the source code for development
2. Extension is working (after several restarts too)
3. Debug "same" extension by adding local source
4. Restart Firefox that temporary addon is removed
5. New Tab Page of AMO extension is still working but "Homepage" is broken. I need to reinstall the extension or just disable and re-enable it.

If you could fix it too it would make me as developer happy. Because after developing/testing my extension i do no need anymore always to fix my extension from AMO or switch between Firefox and Firefox Dev. I have the AMO version running because in Firefox its not possible to have a temporary/local addon persistent as in Chrome. Its a bit frustrating....

Comment 51

[Firefox Bug Husbandry Bot]

Please specify a root cause for this bug. See :tmaity for more information.