1457487 - [32bit] Firefox starts with one blank page after migrating from any browser

Status: RESOLVED WORKSFORME

(Firefox :: Migration, defect)

Description

[Catalin Sasca, Desktop QA [:csasca]]

[Affected versions]:
Firefox 61.0a1 nightly 
Firefox 60.0b16 beta
Firefox 59.0.2 release

[Affected platforms]:
Windows 8.1 (x86), Windows 10 (x64) with x86 build.

[Steps to reproduce]:
1.Start firefox with "firefox -no-remote -migration".
2.Select import from any other browser.
3.See the behavior of the browser.

[Expected result]:
Firefox starts correctly and loads start pages.

[Actual result]:
Firefox starts with one blank page. Also, it seems that a blank page is displayed at every 2-3 newly opened tabs.

[Regression range]:
It seems to be an old regression. I couldn't reproduce it on Firefox 57.0.4. I will follow up with a regression range asap.

Comment 1

[Matthew N. [:MattN]]

(In reply to Sasca Catalin, QA [:csasca] from comment #0)
> [Regression range]:
> It seems to be an old regression. I couldn't reproduce it on Firefox 57.0.4.
> I will follow up with a regression range asap.

Output from the Browser Console may be useful. I don't yet know if this will be a migration bug or unrelated to migration.

Comment 2

[Catalin Sasca, Desktop QA [:csasca]]

Attachment: Browser Console Output

Hi Matthew. Here's an attachment with the output from the Browser Console. If you need anything else, please let me know.

Comment 3

[Matthew N. [:MattN]]

(In reply to Sasca Catalin, QA [:csasca] from comment #2)
> Hi Matthew. Here's an attachment with the output from the Browser Console.
> If you need anything else, please let me know.

Awesome! Thanks! There are some potential causes there:

> Uncaught exception: Error opening input stream (invalid filename?): chrome://browser/content/ext-c-browser.js

Hmm… I don't understand what this file is for and why it wouldn't be found…

> NS_ERROR_FACTORY_NOT_REGISTERED … [nsIWebNavigation.loadURIWithOptions] browser-child.js:359
https://dxr.mozilla.org/mozilla-release/rev/3bfc82b371ecec483e3336944c3e0f33e7d94397/toolkit/content/browser-child.js#359-360

Would you be able to repeat this test with a debug build so I can see if there are any Warnings in the terminal to help narrow down what service is having problems loading.

This is for Fx60 which matches your screenshot: https://queue.taskcluster.net/v1/task/FkX6sQQdSzeJo8CoqLYo1Q/runs/0/artifacts/public/build/install/sea/target.installer.exe

I think you will see a terminal window automatically open when you run this build. Please attach the output from that window.

Thanks

Comment 4

[Matthew N. [:MattN]]

Oops, above was the 64-bit link as I forgot this was 32-bit only. Here is the 32-bit debug installer: https://queue.taskcluster.net/v1/task/bhsjr4UuS7WkusjIXpk_9Q/runs/0/artifacts/public/build/install/sea/target.installer.exe

Comment 5

[Catalin Sasca, Desktop QA [:csasca]]

Attachment: test crash.gif

Hi Matthew. I've tested with the x32 debug installer that you attached link to, and the behavior can be seen in the screencast that I attached. Actually, if not recording the screen, firefox doesn't crash nor launch, and it stays at the latest commands which can be seen in powershell(where the crash occurs).

Comment 6

[Matthew N. [:MattN]]

Hi, unfortunately the gif doesn't include the full output from the terminal window… it looks like there is a stack trace when the crash UI shows up but the most important part (the top of the stack) is scrolled off-screen. Can you please copy the output of the terminal window as text to an attachment on the bug, not just the visible part of the terminal. Thanks.

Comment 7

[Catalin Sasca, Desktop QA [:csasca]]

Attachment: terminal output.txt

Hi Matthew. Here's an attachment with the terminal output. I hope this will help you. Let me know if you do need anything else.

Comment 8

[Matthew N. [:MattN]]

Any update on the regression range? Is this still happening?

Comment 9

[Catalin Sasca, Desktop QA [:csasca]]

I tried reproducing the issue on Windows 10 (x64) and Windows 8.1 (x86) with x86 builds of the Firefox Beta 66.0b4 and latest Nightly 67.0a1 (2019-02-04) and is it not reproducing anymore.

However, after following the STR and closing Firefox from the X button, the browser doesn't shut down completely, as the processes remain open in task manager and they need to be closed by ending them. This is not happening if the browser is closed from the menu.

Comment 10

[Matthew N. [:MattN]]

(In reply to Catalin Sasca, QA [:csasca] from comment #9)

I tried reproducing the issue on Windows 10 (x64) and Windows 8.1 (x86) with x86 builds of the Firefox Beta 66.0b4 and latest Nightly 67.0a1 (2019-02-04) and is it not reproducing anymore.

Great, I'll close this then.

However, after following the STR and closing Firefox from the X button, the browser doesn't shut down completely, as the processes remain open in task manager and they need to be closed by ending them. This is not happening if the browser is closed from the menu.

That's bug 1495010 and as far as we can tell only happens when the --migration command line argument is used.