1011978 - Audit uses of update-service for guards of MOZ_UPDATER define to avoid exceptions (which cause "you haven't started Firefox in a while" to show up on every new window because we re-run nsBrowserGlue's _onFirstWindowLoaded)

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Friedrich Volkmann]

User Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140217071214

Steps to reproduce:

Firefox 27, installed on 2014-02-17, had been running for a couple of weeks, with ~ 20-30 open tabs. I think that all restarts for a year or two have been crash recoveries.


Actual results:

Every couple of hours or so, the status bar appears, containing the message: "It looks like you haven't started Firefox in a while. Do you want to clean it up for a fresh, like-new experience? And by the way, welcome back!". In the lower right corner, there's a button labelled "Reset Firefox", and a close button. When I click the close button, sometimes the message immediately repeats for a couple of times, so I need to click the close button multiple times to get rid of the message (and the status bar) for a while.


Expected results:

The message should not appear at all.

The text "welcome back" is nonsense when Firefox has been running all the time. Checks like this should only be done at Firefox launch, and accordingly, the message should only show up on Firefox launch. It should not repeat until next launch.

Moreover, the check should compare the current date with the latest termination date, no matter if normal of abnormal termination, not with (as it seems) the latest fresh session start date.

Comment 1

[Matthew N. [:MattN]]

Hello,

That message should only show up when the first window is loaded. What action are you taking before the notification bar appears? Are you using an extension that manages your session?

Comment 2

[Friedrich Volkmann]

It seems that the notification only appears when a web page is loaded (after clicking a link), not while the browser is idle.

I use the Tab Mix Plus add-on with its session manager and crash-recovery.

Comment 3

[Friedrich Volkmann]

Problem persists in FF 31.0. The messages start popping up in the status bar after FF has been running for 2 months.

Comment 4

[Friedrich Volkmann]

(In reply to Matthew N. [:MattN] from comment #1)
> That message should only show up when the first window is loaded.

It shows up whenever a new window opens. When I select the menu item "File" -> "New Window", the message appears in the new window. When I right-click a link and select "open link in new window", the message appears in the new window as well. When I open a link in a new tab, no message appears. When javascript opens a new (popup) window, the message appears in the original (i.e. parent) window. When JS in the popup window opens a third window, the message appears in the root (parent of parent) window.

Comment 5

[:Gijs (he/him)]

(In reply to Friedrich Volkmann from comment #4)
> (In reply to Matthew N. [:MattN] from comment #1)
> > That message should only show up when the first window is loaded.
> 
> It shows up whenever a new window opens. When I select the menu item "File"
> -> "New Window", the message appears in the new window. When I right-click a
> link and select "open link in new window", the message appears in the new
> window as well. When I open a link in a new tab, no message appears. When
> javascript opens a new (popup) window, the message appears in the original
> (i.e. parent) window. When JS in the popup window opens a third window, the
> message appears in the root (parent of parent) window.

Can you open the browser console (ctrl-shift-j), clear it, ensure JS errors are visible, and then open a new window and let us know what, if any, errors show up?

Comment 6

[:Gijs (he/him)]

Also, are you using a distro build?

My current suspicion is that we use Services.telemetry from within _onFirstWindowLoaded and that errors out on builds where telemetry was not built, which causes us to not remove our first window observer, which causes us to re-run that code for the next window that opens, and the next, ...

Comment 7

[Friedrich Volkmann]

I don't know what is a distro build. I am using FF 35.0.1 which I installed from the FreeBSD ports collection on 2015-02-22 (port version: firefox-35.0.1_1,1). That means that I compiled it from the source using the FreeBSD ports framework and the patches included with the FreeBSD port. The current firefox process was started on 2015-06-21. Strangely enough, I am already getting the "it looks like blah blah..." messages although slightly less than the "magical" 60 days have passed.

Browser console output (with all JS/security/logging enabled and all net/CSS disabled):
1) Opening a new window via the "File" menu:
No chrome package registered for chrome://tabmix-os/skin/browser.css
Using //@ to indicate sourceMappingURL pragmas is deprecated. Use //# instead jquery.js:1
TypeError: Cc['@mozilla.org/updates/update-service;1'] is undefined nsBrowserGlue.js:543

2) Opening a new tab:
TypeError: document.getElementById(...) is null  overlay.js:7333

3) Opening a new window by typing «window.open("file:///");» in the error console:
No chrome package registered for chrome://tabmix-os/skin/browser.css
Using //@ to indicate sourceMappingURL pragmas is deprecated. Use //# instead jquery.js:1
TypeError: Cc['@mozilla.org/updates/update-service;1'] is undefined nsBrowserGlue.js:543
[object Window]

Comment 8

[:Gijs (he/him)]

(In reply to Friedrich Volkmann from comment #7)
> I don't know what is a distro build. I am using FF 35.0.1 which I installed
> from the FreeBSD ports collection on 2015-02-22 (port version:
> firefox-35.0.1_1,1). That means that I compiled it from the source using the
> FreeBSD ports framework and the patches included with the FreeBSD port.

You're using a FreeBSD build instead of an official binary released by Mozilla, which means it's built with different options than the default, which can sometimes cause "interesting" behaviour. And indeed, that is the case here:

> TypeError: Cc['@mozilla.org/updates/update-service;1'] is undefined
> nsBrowserGlue.js:543

This is what I was looking for. Thanks!

As a workaround (I don't have source for 35 to hand, but it looks like this hasn't changed too much), if you go to about:config and set the app.update.enabled pref to false, you won't see this on every window anymore.

Comment 9

[:Gijs (he/him)]

Attachment: MozReview Request: Bug 1011978 - fix use of updater service in nsBrowserGlue to check for MOZ_UPDATER,r?jaws

Bug 1011978 - fix use of updater service in nsBrowserGlue to check for MOZ_UPDATER,r?jaws

Comment 10

[:Gijs (he/him)]

I checked for all uses of "/update-service" and didn't find anything else that needed fixing.

Comment 11

[:Gijs (he/him)]

Independently, for this particular case, there might be an argument that we should remove the observer before doing anything else. On the other hand, if any of the code causes an exception, rerunning it later might work, and not rerunning it might also cause problems. Really, none of the code in that codepath should be causing exceptions, but obviously we are flawed humans writing it, and it's hard to know what errors we can expect and therefore how we should be reacting to them... if you have thoughts about this, Jared, please share.

Comment 12

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8649209 [details]
MozReview Request: Bug 1011978 - fix use of updater service in nsBrowserGlue to check for MOZ_UPDATER,r?jaws

https://reviewboard.mozilla.org/r/16371/#review14647

Good find!

Comment 13

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/766ec6335893

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/766ec6335893