Closed Bug 1421796 Opened 7 years ago Closed 1 year ago

Firefox periodically opens to a broken new tab, blank tab

Categories

(External Software Affecting Firefox :: Other, defect, P3)

x86_64
Windows 10

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: rjhansen075, Unassigned)

References

()

Details

(Whiteboard: inj+)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20171112125346 Steps to reproduce: Started Firefox with all extensions disabled, new profile. Tracking protection is set to "Always" and using the strict block list. Home page is Firefox default, new tab page. Machine is very fast, uses an SSD. Windows 10 x64, 16299.64. Firefox 57 x64. Actual results: Periodically, the initial tab is blank. The page is white. Trying to navigate to any site with this tab results in a hung navigation (throbber cycles endlessly) and a blank page. Workaround: You press the new tab button, and the new tab works. Then you close the initial broken tab. Expected results: Firefox should always open to a working tab with home page content.
While posting this bug, I just had the problem occur with a new tab I opened in the current browser session. The tab is blank, navigation to any page results in an endless throbber and stays blank. Closed it. Pressed new tab again. This tab works. Sometimes, Firefox is initializing dead tabs on my system. I have extensions installed, but they are all disabled, and I am working in a brand new profile to track other bugs with extensions.
Component: Untriaged → Session Restore
If you open the browser console (ctrl-shift-j) after a startup, are there any errors in the console that aren't there on startups that do work correctly?
Flags: needinfo?(rjhansen075)
Priority: -- → P3
I haven't had the issue in several days. When (if) I do, I'll open up a console.
Heck. I just disabled all my extensions again and turned tracking protection back on and got a dead tab with the following in the console: Key event not available on some keyboard layouts: key=“r” modifiers=“accel,alt” id=“key_toggleReaderMode” browser.xul Key event not available on some keyboard layouts: key=“i” modifiers=“accel,alt,shift” id=“key_browserToolbox” With the extensions enabled, native tracking protection off, it seems to work better.
Flags: needinfo?(rjhansen075)
(In reply to R. Hansen from comment #0) > Tracking protection is set to "Always" and using the strict block list. (In reply to R. Hansen from comment #4) > Heck. I just disabled all my extensions again and turned tracking protection > back on and got a dead tab [...] > With the extensions enabled, native tracking protection off, it seems to > work better. Ed, is it possible the strict block list somehow interferes with about:newtab?
Component: Session Restore → Activity Streams: Newtab
Flags: needinfo?(edilee)
I haven't been able to reproduce the issue with Tracking Protection set to Always with the strict block list in 57 on mac. The new tab page shows top sites with rich icons and screenshots as well as pocket stories with images and highlights with images, so the page itself is loading fine, and I'm able to navigate to top sites, stories, and highlights without problem as well as typing in a url in the address bar. Pretty sure we have not heard of tracking protecting affecting activity stream from any other bugs either.
Flags: needinfo?(edilee)
I just had this error occur with all my extensions enabled. In addition to there being a blank tab that can't navigate to anything at startup, none of the installed extensions initialized. I have "Country Flags & IP WHOIS," "VideoDownloadHelper," and "Ghostery" installed. The Ghostery icon remained grey. When I have had this problem with extensions not starting, Firefox takes an extended amount of time to shut down. 4-8 seconds instead of nearly instantaneous. Should I submit a second report for extensions failing to initialize?
I have refreshed the browser to see if there's some stray setting in prefs.js that is causing this.
Okay, so I reset the browser. Everything seemed to be working well. Several startups without difficulty. Then I installed all my extensions, and *disabled* all of them, and I had a dead tab error occur. This should not be happening with extensions disabled, right? The four extensions are: Ghostery, Country Flags & IP WHOIS, VideoDownloadHelper, and InvisibleHand. Failure started after I installed the extensions, but the extensions are disabled. Any suggestions?
Speculation: One of the extensions created a problem in the profile when it ran, that persists across a restart, and doesn't have anything to do with the enabled/disabled state of the extension. Once the extension misbehaves, even if you disable it afterwards in the active session, there is a tab failure on restart. I think this bug is extension related, but may be a problem with WebExtensions in Firefox, as I'm having all the extensions not initializing sometimes as well. I think the failure to initialize extensions and the dead tab error are related. To reproduce, try adding those extensions, then immediately disable them, then restart. You should eventually get a dead tab. I'll try to narrow down which extension by adding them one at a time to a test profile.
The misbehaving extension appears to be "Ghostery." I'm using the native blocklist right now, with the other extensions installed, without trouble. I will open a ticket with the folks at Ghostery.
(In reply to R. Hansen from comment #11) > The misbehaving extension appears to be "Ghostery." I'm using the native > blocklist right now, with the other extensions installed, without trouble. > > I will open a ticket with the folks at Ghostery. Interesting, thanks for debugging this so far! In the webextensions world, I wonder if there's an API thing that we're not doing quite right. I expect the ghostery folks will have more ideas about that. Can you link to the report on their tracker on here?
Component: Activity Streams: Newtab → WebExtensions: Untriaged
Flags: needinfo?(rjhansen075)
Product: Firefox → Toolkit
Priority: P3 → --
I have noted two other behaviors that appear to be linked to a Ghostery install. 1. Firefox fails to start entirely. Instead of launching the GUI, nothing comes up on screen. In the Task Manager, there is a Firefox process with about a 12MB private working set doing nothing. Firefox will not launch until this process is killed from TM. Then Firefox will start normally. 2. All addons fail to start. Ghostery icon remains grey and does not block scripts. In addition, all the other addons fail to start. Shutting down Firefox and restarting works to resolve this, but it takes 4-10 seconds for Firefox to shut down all its processes. If you restart while those processes are shutting down, then you get the stub process as per issue #1. If you watch in task manager and wait for all the Firefox processes to finally shut down, then restart, it usually resolves the issue. I am in dialogue with Ghostery tech support, and have requested a link to their issue page. I will post that link if they are able to give it to me.
Component: WebExtensions: Untriaged → WebExtensions: General
Priority: -- → P5
Working with Firefox 58; I have noticed considerable improvement in browser stability. When Firefox is started with the Firefox shortcut, so far, it has always initialized with add-ons starting properly. I had one "stub process" start-up this morning, but that may have been due to shutting down and restarting too quickly. It happens far less frequently with Firefox 58. There are still problems when Firefox is launched by selecting an item from the jump list or clicking on a .URL link. The only behavior I have seen is limited to Firefox starting up to a dead tab and then becoming unresponsive (This application is not responding, hard lock), requiring shutdown of Firefox from task manager. This only happens when launching from a web link, however. I have not had any dead tab errors when starting directly from the Firefox shortcut. (As a side note, I did have Firefox just completely lock up (This application is not responding) while filling in this web form to update the report for Firefox 58. Firefox occasionally does this and I am considering putting out a report on it. I believe it to be a separate issue.) Overall, 58 seems to be a lot more stable, and I suspect the problem is with the new add-on framework, particularly with initialization on launch, and not Ghostery. The regression occurred on my system when I installed Firefox 56. Ghostery is probably a more complicated add-on, and triggers the problems with add-on framework initialization. It is likely that any large add-on would cause the problems. I have not tested other add-ons (such as AdBlock). In summary: If there's a dead tab, the entire application just crashes on startup. No dead tabs so far on new tab activation. No problems with add-ons not starting, and the resulting lengthy shut-down process. Still a possible problem with "stub process" start up, which I will continue to monitor. I am clearing the current "needinfo" because Ghostery staff is aware of this bug report. I have directed them to this page, but to my knowledge they haven't participated. I am not experiencing any of these issues on my Toshiba laptop, which has the same add-ons installed.
Flags: needinfo?(rjhansen075)
I looked into the crash reporter in about:support and found a long list of crashes. Almost all of them involve snxhk64.dll, which is a component of Avast! antivirus. Another set of crashes involved both snxhk64.dll in one call and nvldumdx.dll in several calls. I believe that's part of the nVidia graphics drivers. All of the crashes bear the signature "IPCError-browser | ShutDownKill," which I think is me killing the thread from Task Manager. So maybe Avast is the problem? I should have checked crash reports in the first place.
I should note that the Toshiba laptop also has Avast installed and is not experiencing these issues.
(In reply to R. Hansen from comment #16) > I should note that the Toshiba laptop also has Avast installed and is not > experiencing these issues. Does it have different settings, or maybe different updates applied? What versions of Avast are both machines running? If Avast is reliably causing crashes we may be able to either block Avast from interfering with Firefox and/or get them to fix things.
Flags: needinfo?(rjhansen075)
The Toshiba laptop has an identical program version and settings, so I'm not sure why the Avast module appears to be crashing on one and not the other, which puts me squarely in the realm of speculation. I'm going to go through the crash logs on the Toshiba today to see if there isn't something happening in the background there. Honestly, I'm a little out of my depth here re: the Mozilla project. I'm not sure I'm reading the crash reports right. Is there an easy way to send them to you? Is there a training page where I can get up to speed? This is getting beyond my dilettante knowledge of Firefox. I'm convinced this needs deeper investigation, and it sounds like the error is not easily repeatable on others' systems and perhaps I'm the only one who can really investigate it. I'm good at QA, I've got years of experience troubleshooting software solutions, but I'm not read in to all the schemas and work processes involved, and I'm not sure I'm interpreting them correctly. I've got time to volunteer, and I'm guessing if it's failing on my system, it's failing on someone else's system *somewhere*. If an average user runs into this problem, they're just going to think Firefox is unreliable and switch to something else. Worse, it appears that complicated addons exacerbate the situation and the new WebExtensions API is supposed to be a selling point for Firefox Quantum. As I said, this all started when I upgraded to Firefox 56, and it's getting better, but it's not fully resolved. I'm supportive of Mozilla's mission and believe that an independent, privacy-minded browser like Firefox provides unique value to an open web with clear standards. I have a lot of motivation here. I want this bug squished. So please email me if you can help me out here. If you don't have the time for such an apparently obscure issue, I understand. If someone has the time to get in touch directly, I would appreciate it.
Flags: needinfo?(rjhansen075)
Since yesterday, I have had additional "stub process" startup errors. When it happens, there are now consistently three Firefox processes in the Task Manager, one of which is the 12MB working set process I initially described. It happens both when I launch from a .URL link (shell integration) or launch Firefox directly.
I discovered today that the process that is causing the "stub start" (no startup, three processes, and no indication that Firefox is running when you tell it to run again) is the extensions process. If I kill the extensions process and not the main process in Task Manager, it unhangs and Firefox launches properly, but without extensions. So that particular issue is definitely related to the extensions API. It's hanging on startup for some reason.
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
The regression version is Firefox 56. That's when the issue began.
I double-checked the crash reporter (still learning) and all the crashes involving the antivirus module are from Firefox 57.0.4. I've had new crashes in 58 that do not involve the module, so the subset of issues I am experiencing with Firefox 58 are not related to antivirus software.
Is this issue reproducible, or do I have a problem with the specific system it occurs on? I am still having the problem, but only on the one machine, and I don't know what is different about it. I'm concerned it might be malware.
Flags: needinfo?(ddurst)
I would still like to hear back from Ghostery, unless it's apparent that this can happen a) without any enabled add-ons, but b) more importantly, if it can reliably happen with Ghostery. That gives us somewhere to start. Are these crashes submitted? Because you could send us the crash IDs (preferably not the ones that are you killing the dead tab), across 57 and 58, and we could maybe find someone to look into those in the reports themselves. One last question: you've cleaned up the profile (you said you did a reset) and I assume you upgraded to 58. I'd be curious to see what happens with a new *install* (and new, separate profile), to completely rule out the previous config and incriminate something else on the computer. [Not that I'm assuming there is no issue with extensions, just that this is still the only issue like this we've heard of. Perhaps the crash reports will tell a different story.]
Flags: needinfo?(rjhansen075)
Okay, I just completely uninstalled Firefox, but its defaults are still showing up in the default apps section, so I'm going to have to scrub the registry. This will likely take a while.
Okay, I've done the following. Uninstall Firefox. Remove all registry entries pertaining to Firefox. Reinstall. Start new profile. Use Sync to get my user environment back. Disabled all the extensions in that environment. We'll see if Firefox behaves that way. Then I'll enable Ghostery and see if I get errors.
Okay. I just had a stub start with a brand new profile, with only my bookmarks and their favicons (places.sqlite and favicons.sqlite) transferred from the old profile. 9734e279-83cd-47bb-98f2-5565b0180210 is the crash ID. About four or five firefox.exe processes popped up, but they all disappeared except the 12MB one after a few seconds. So I launched the browser from a .url link on my desktop. Nothing came up on the screen. A number of processes launched then disappeared, and Firefox left a 12MB process that had to be killed from Task Manager to be able to launch again. No Ghostery. I'll see if the other sorts of errors happen. I'm going to work with the browser for about a week. This is difficult because the machine is in my production environment, so I'm going to have to switch profiles back and forth, but for the most part I can browse with the clean profile. After I've pounded away at it for a while, I'll report the results.
My apologies. My conclusion that the problem was Ghostery was wrong. It must have just been coincidence that it started crashing when I installed Ghostery. Perhaps having complicated add-ons installed exacerbates the issue, but it isn't the cause. I had another "stub-start:" Crash report #6d2378b7-2bd9-4853-97e3-4ea330180210 snxhk64.dll keeps showing up as a red flag for modules in the crash reports. This would seem to indicate Avast again, but my Toshiba laptop has Avast installed with the same settings and it doesn't have Firefox issues. The browser is suffering failures with a profile that has never had an extension installed. The browser suffers failures more often when I use the shell instead of the application icon to launch Firefox. I can make it fail more often by double-clicking on a .url link on the desktop or launching a link from the jump list. I'm starting from square-one on this. It's very difficult to isolate.
Flags: needinfo?(rjhansen075)
Reviewing the crash logs, and seeing that they again involved snxhk64.dll as the faulting module, I took the plunge and uninstalled Avast antivirus. Using Windows Defender instead, I was unable to make Firefox crash, generate dead tabs, or have the start-up issues. So, at long last, I think I have isolated the problem to Avast. It must be something specific to this computer, because I have two other computers running Avast and Firefox that do not have issues. Perhaps there is an application installed on this system that isn't on the others. I am on the Avast forums now with the problem trying to work out what the issue might be. I will continue to post notes here as I have more information.
Whiteboard: inj?
Well, it's been a week running Windows Defender for my antivirus, and I've not had a single crash. Avast is causing multiple Firefox issues on my (single) machine. It is not causing a problem with 2 others. I have not received any responses in the forums.
I tested by installing Firefox 55.0.3 today. I had no problems with that version and Avast.
Component: WebExtensions: General → Other
Priority: P5 → --
Product: Toolkit → External Software Affecting Firefox
Version: 57 Branch → unspecified
Clearing ddurst's needinfo, as it's no longer relevant. If anyone reproduces this behavior, please notify.
Flags: needinfo?(ddurst)
Tried the Avast 18.2.2328 update today. It didn't resolve the issue.
Priority: -- → P3
Whiteboard: inj? → inj+
Updated to Firefox 59 today. Same problems.
Status: UNCONFIRMED → NEW
Crash Signature: [@ IPCError-browser | ShutDownKill ]
Ever confirmed: true
R. Hansen, can I share crash dumps with Avast? They might contain some personal information. Lukas, is this a known problem? I can provide crash dumps to you if R. Hansen accepts.
Flags: needinfo?(rypacek)
Flags: needinfo?(rjhansen075)
Sure. Go ahead and share the information.
Flags: needinfo?(rjhansen075)
Avast updated to 18.3.2331, so I reinstalled. Issue is not resolved. Tested with FF 59.0.2 x64.
Updated to Windows 10 Pro x64 1803 (patch level 17134.48), Firefox 60.0.1 x64, and Avast! 18.4.2338. Same issues.
This bug started to affect me after Update to Ubuntu 18.04 with Firefox 60.0.1 (64bit). Exact same problems as described here.
Those being: * Opening a new tab, more often than not, causes that tab to be blank. In that case entering an URL in the location bar does nothing. No site is being loaded. The tab is basically dead. * If a new tab, happens to sometimes and seldom actually load the MozillaStartSite, everything works * Problem persists with all addons disabled * Problem persists with new profile * The broken tabs seem to be associated with threads that have died and are hanging around and keeping firefox from quitting in a normal fashion. The problem seems to be related to firejail, as without firejail I do not experience this issue.
Still happily chugging along with Firefox 61.0 and Windows Defender. I didn't even bother installing Avast this time. If you want me to test it with the latest Avast, set a needinfo flag and I'll get right on it.
Firefox Quantum 60.0.1: Disabling Firejail for Firefox fixed the problem. now after upgrade: Firefox Quantum 60.0.2: Problem of Firefox sometimes opening broken new tabs now happens even outside Firejail. to reproduce: - copy an URI to clipboard - repeat <Ctrl>-T <Ctrl>-V <Enter> - out of ~7 tries, 3 tabs are broken and remain unresponsive
Interesting. I just got a stub-start (11MB single Firefox process that goes nowhere) using Windows Defender, Win 10 x64 1803, and Firefox 61.0.1. Still nothing in about:crashes, but that's pretty good evidence that Firefox is the problem.
Still works fine with Windows Defender. No stub starts. Just the one time (and probably because I restarted Firefox too soon after closing it).

Ubuntu 18.04 Bionic
OS: Linux 4.15.0-46-generic
Firefox Quantum 66.0.1 (64-bit)
Build: 20190322095656
Multiprocess Windows 1/1 Enabled by user
Web Content Processes 9/8
Enterprise Policies Inactive

Using Firejail: NO

The problem has gotten worse with the latest Firefox Update (Ubuntu Package version 66.0.1+build1-0ubuntu0.18. amd64)

To elaborate...

The problem did go away after I stopped using firejail with firefox.
It returned with recent firefox versions and now persists despite firejail not being used.

Yeah, I'm still using Defender and Firefox, and every once in a blue moon I get a stub start as described and have to kill it from Task Manager. Whatever Avast is doing makes the problem worse on my system, but there's also an underlying problem of some kind. Sounds like this is an edge case though, so maybe it gets fixed and maybe it doesn't.

I checked my crash log and there's nothing there. It looks like the problem locks up the initialization process at launch before crash logging begins.

Still totally usable, but Avast is no longer an option and I prefer Avast to Defender. I prefer Firefox more, is all.

the same problem affect me .I use ubuntu 18.04 bionic x86_64 system with firefox quantum 66.0.2 in firejail。 It can random appear ,sometimes on startup ,especially a long time a do not operate on the browser after starting up. But without firejail ,It seldom happenned .

This problem affects to me also. I'm using ubuntu 18.04 x86_64 system with firefox quantum 66.0.3

Many times during the day, when I open a new tab appears blank and I have to open another one until website appears.

I've seen this happening when the 66 version appears, but still happening in .0.2 and 0.3

Please help!

I'm having the same problem, too. I'm using Kubuntu 18.04 and this started some months ago. I never used firejail, starting firefox without add-ons does not help in this case. Every third or forth new tab I'm opening stays blank and is completely broken. Very annoying problem and I'm not seeing any related error in browser console.

Same here (FF 66.0.5/Win7 Pro SP1), several times a day. I first notice it a couple of years ago also for a while, then it corrected unit maybe 3-4 versions ago.

Also having this problem. Opened up a ticket about the bug. I understand Mozilla volunteers aren't paid for committing their personal time towards bug hunting, but Mozilla seems intent on not addressing this issue and exhausting as many efforts as they can directing users to try safe mode and uninstalled and installing, reinstalling Windows, when the problem is well documented. And surged in v.64 until now.

I don't like Chrome and hate that Fisher Price designed software. I don't want to stop using Firefox because I spend more time troubleshooting bugs than using the web.

Also experiencing sub-start problems. I had to start and kill Firefox Beta this past weekend at least 3 dozen times before it finally loaded. No amount of restarting or cold booting helped aid the problem.

(In reply to Alex from comment #55)

Also having this problem. Opened up a ticket about the bug.

Assuming you're talking about bug 1549649, that's different from this bug, which is about the initial tab that loads when Firefox opens being blank.

The older comments here relate to AVAST and/or firejail causing issues, the more recent comments suggest similar things happen in other situations, but there's no clear root cause and thus no solution.

Mozilla seems intent on not addressing this issue

This is casting aspersions, and unhelpful. I don't know why you think we would produce software and then deliberately intend not to fix bugs in current, supported versions... it doesn't make a lot of rational sense.

and exhausting as many efforts as they can directing users to try safe mode

Because we need to work out what's causing the problem, given that Firefox works fine for me and countless other people, and I never see blank tabs. To be clear: I 100% believe that it's broken for other people, but in order to fix that we need to know what is different between your setup and mine in order to work out where the problem comes from. Asking people to try safe mode helps rule out certain reasons the problems might happen.

and uninstalled and installing, reinstalling Windows,

I don't know who advocates this (not me!), but it's unlikely to help.

Given the fact that v.64 caused the recent issues to flair up and Mozilla hasn't made a major effort in tracking down what causes this bug that's incredibly annoying leads me to make such a sweeping statement. That said, I also get dead tabs on startup or it not working at all. I do use Avast, but I also used their cleaner utility in the past because I know Avast didn't play nice with Firefox years ago.

Sub-starts are annoying but my current problems revolve around beta and nightly for that, and I suspect that's just an issue with non-stable versions. The blank tabs/dead tabs is a problem that affects mainstream/stable versions of Firefox, too.

In firefox 67, 68 and 69 the same. I filled this bug 1565185 before knowing about this one. In Ubuntu Mate 16.04 and Ubuntu Mate 18.04. Different computers and different configurations...

I have what seem to be 2 separate "dead tab" issues. However, both are intermittent and I haven't found a controlled way to always reproduce them:

  • I open a new tab in a new firefox profile (no addons); I type a link and hit [Enter]; the little grey progress dot goes back and forth but for at least 10 minutes there is no actual sign of the page getting loaded; e.g. no "Waiting for example.com" or "Performing TLS handshake..." at the bottom, no text or images appear; the page remains white and blank. There is also no output in the browser console.
    Screenshots: https://drive.google.com/open?id=12dENbDqPeaY1MwfFiTFKxPPJ8IfHHJOn, https://drive.google.com/open?id=1-02u90aH7D0AXCwYaOjrkgdAvAcehioM
  • less thoroughly documented: I "triple click" a link (on a touchpad) to open it in a new tab (haven't tried a new profile with no addons yet); the tab opens with the page title in the tab itself, but the page is blank and there is no grey progress dot. I'll reply back if I can capture more details on this one.

I would be happy to provide more debug details if I knew what would be helpful.

Version Details:
Name Firefox
Version 71.0
Build ID 20191205184924
User Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0
OS Linux 4.15.0-1065-oem

(In reply to n.marti from comment #60)

I have what seem to be 2 separate "dead tab" issues. However, both are intermittent and I haven't found a controlled way to always reproduce them:

Please file a separate bug with these details. Please include some context about your network connection, and check the browser console (not the regular developer console) for errors - ctrl-shift-j is the appropriate shortcut on Linux. Please needinfo me on the bug.

  • less thoroughly documented: I "triple click" a link (on a touchpad) to open it in a new tab (haven't tried a new profile with no addons yet); the tab opens with the page title in the tab itself, but the page is blank and there is no grey progress dot. I'll reply back if I can capture more details on this one.

Same thing here please.

Flags: needinfo?(n.marti)

I filed a new bug #1604218

Flags: needinfo?(n.marti)

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME

It's nice when bots are helpful but this is not one of those times, clearly...

Status: RESOLVED → REOPENED
Crash Signature: [@ IPCError-browser | ShutDownKill ]
Resolution: WORKSFORME → ---

Clear a needinfo that is pending on an inactive user.

For more information, please visit auto_nag documentation.

Flags: needinfo?(rypacek)
Severity: normal → S3

I am no longer having this problem. I'm not going to close it "works for me," as it was reopened, but I would recommend this if I am blocking that action.

Thanks for the update Russ! I'll close this out; we can create a new bug or reopen this one if the problem reappears.

Status: REOPENED → RESOLVED
Closed: 5 years ago1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.