646054 - Empty update dialog after clicking notification

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[George Carstoiu]

Attachment: Screenshot 1

Mozilla/5.0 (X11; U; Linux i686 (x86_64); af; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16

By clicking on the update notification, a blank window is displayed that has non-functional buttons(see Screenshot 1). This applies to all local versions of Firefox on Ubuntu 10.04 on 32 and 64 bits.

Reproducible: always

Steps to reproduce:
1. Change 'release' in "channel-prefs.js" to 'releasetest'
2. Set the following prefs in about:config:
     app.update.interval = 60
     app.update.timer = 600
3. Restart Firefox
4. Wait a minute to be prompted for an update
5. Click on update notification

Actual results:
 - blank window is displayed

Expected results:
 - a window that starts the update process is shown

Workaround:
 - in order to update Firefox - Help->Check for updates; in this way the update window is displayed correctly and the updating process can commence.

Comment 1

[Vlad [QA]]

I can also reproduce this bug on Windows XP, using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16. 

It is reproducible with all local versions of FF 3.6.16

Comment 2

[u279076]

Confirmed this is happening -- seems to only affect Firefox 3.6.16 builds (3.5.18 is ok).

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

rs, are these sensible timer settings to be using ? They're different to the ones suggested in bug 539308.

Comment 4

[Robert Strong (they/them - no direct email)]

The values aren't all that sensible in the sense that users have values in hours and these values are in milliseconds and seconds. At least we don't get these "type" of bug reports during QA as often now that the values are somewhat restricted. I'd like to restrict the values even more but then QA wouldn't be able to perform manual testing.

Anthony, can you reproduce using the values I asked QA to document and use in bug 539308?

Comment 5

[Robert Strong (they/them - no direct email)]

Al, looks like the QA documentation you fixed in bug 539308 changed.

Comment 6

[u279076]

(In reply to comment #5)
> Al, looks like the QA documentation you fixed in bug 539308 changed.

It's not been changed -- that's just not where I got the values from.  I guess the Litmus test I got the values from is now deprecated.  Now testing the "correct" values on bug 539308.

Comment 7

[Robert Strong (they/them - no direct email)]

Specifically, in bug 539308 comment #2
(In reply to comment #2)
> The following should be changed as follows now that bug 540356 is fixed.
> app.update.interval
> Set this to 60. It tells Firefox to check for updates every 60 seconds.
> 
> app.update.timer
> Set this to 60000.  It tells Firefox to fire a timer every 60 seconds.

In the litmus test it states:
"Change app.update.timer to "6000" milliseconds. (It tells Firefox to fire a timer every 60 seconds.)"

This actually makes the timer fire every second though the clamp on it should reduce the value.

Comment 8

[u279076]

This is still reproducible using the following values:
app.update.idletime = 1
app.update.interval = 30
app.update.timer = 30000

Comment 9

[Robert Strong (they/them - no direct email)]

Interesting... and with the final values decided upon in bug 539308?
app.update.interval = 60
app.update.timer = 60000

Is the update to go to 4.0?

Comment 10

[u279076]

(In reply to comment #9)
> Interesting... and with the final values decided upon in bug 539308?
> app.update.interval = 60
> app.update.timer = 60000
> 
> Is the update to go to 4.0?

What are the final official numbers? This is really confusing to our contractors who are helping that have no experience with this?

app.update.idletime = 1
app.update.interval = 30
app.update.timer = 30000

...is what they have been told.

Comment 11

[Robert Strong (they/them - no direct email)]

The official numbers come from bug 539308.

Who told them these "official" numbers?

Comment 12

[Al Billings [:abillings - ex-MoCo]]

As far as the litmus test, it looks like I fumble-fingered and missed a zero.

Comment 13

[u279076]

(In reply to comment #11)
> The official numbers come from bug 539308.
> 
> Who told them these "official" numbers?

I did because that's how I understood it from your initial comment in bug 539308.  Please just clearly tell me what the values are so I can set the testers straight.

By the way, the following values reproduce the bug as well:
app.update.idletime = 1
app.update.interval = 60
app.update.timer = 60000

Comment 14

[Robert Strong (they/them - no direct email)]

Yep, the initial comment in a bug is not always the end decision in a bug.

The values you stated in comment #13 are correct.

So, is this updating to Firefox 4 as I asked in comment #9?

Comment 15

[u279076]

The testers have been advised to use:
app.update.idletime = 1
app.update.interval = 60
app.update.timer = 60000

WRT comment 9, the notification says "Firefox 4" but the dialog is empty with unusabled buttons (as per the original report and screenshot in this bug)

Comment 16

[Robert Strong (they/them - no direct email)]

Thanks, that gives me something to go on

Comment 17

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1

Thanks Anthony for the additional information and tracking this down.

Regretfully, there is no way to test this code on 3.6 which is why it wasn't caught... it is thoroughly tested on trunk.

btw: in Firefox 4 the app.update.timer is no longer used and there is no new pref to set for testing since the timer will fire every 2 minutes until all consumers have been notified and will schedule the next timer notification to be when the next consumer needs to be notified.

Comment 18

[Robert Strong (they/them - no direct email)]

Drivers, this affects update notification but does not affect the manual check for updates.

Comment 19

[LegNeato]

Ok, so sounds like we should get this in a 3.6 software update before we do the 4.0 prompt? Is 3.5 affected?

Comment 20

[Robert Strong (they/them - no direct email)]

(In reply to comment #19)
> Ok, so sounds like we should get this in a 3.6 software update before we do the
> 4.0 prompt?
Yes

> Is 3.5 affected?
No

Comment 21

[Daniel Veditz [:dveditz]]

(In reply to comment #17)
> Regretfully, there is no way to test this code on 3.6 which is why it wasn't
> caught... it is thoroughly tested on trunk.

huh? I'm confused, this bug _was_ caught by someone testing Firefox 3.6.

Taking comment 18 and 19, we need to get this fix into the upcoming 3.6.17 and then will have to ship that (April 20-something) before we can turn on the advertized/prompted 4.0 update?  But we can advertize 4.0 to 3.5.x users before then if we want?

Comment 22

[Daniel Veditz [:dveditz]]

There's not much info in the bug about the actual bug, but from the patch it looks like the wizard broke before going to the addon compatibility check page? Does that have any implications for testing, like try it with and without addons, and with and without 4.0-incompatible addons?

Comment 23

[u279076]

(In reply to comment #22)
> There's not much info in the bug about the actual bug, but from the patch it
> looks like the wizard broke before going to the addon compatibility check page?
> Does that have any implications for testing, like try it with and without
> addons, and with and without 4.0-incompatible addons?

The bug happens when the Firefox 4 update notification which pops up in the bottom-left corner of the window and the user clicks this notification.  Clicking this should display the Firefox 4 update billboard.  Instead, we get an empty dialog with unusable buttons.

AFAIK, no add-ons come into play as this is happening on new profiles and the add-on checker does not come into play this early in the update process.

Comment 24

[Dave Townsend [:mossop]]

Comment on attachment 522900 [details] [diff] [review]
patch rev1

Do we need a test for this?

Comment 25

[Al Billings [:abillings - ex-MoCo]]

(In reply to comment #24)
> Comment on attachment 522900 [details] [diff] [review]
> patch rev1
> 
> Do we need a test for this?

That would be nice...

Comment 26

[Robert Strong (they/them - no direct email)]

(In reply to comment #21)
> (In reply to comment #17)
> > Regretfully, there is no way to test this code on 3.6 which is why it wasn't
> > caught... it is thoroughly tested on trunk.
> 
> huh? I'm confused, this bug _was_ caught by someone testing Firefox 3.6.
unit tests. This has to do with the add-on incompatible check page which is shown after after an update notification. On 3.6 and previous we can't install / uninstall add-ons. On 4.0 we can and this is tested. One option would be to write mozmill tests for 3.6 for this bug.

> Taking comment 18 and 19, we need to get this fix into the upcoming 3.6.17 and
> then will have to ship that (April 20-something) before we can turn on the
> advertized/prompted 4.0 update?  But we can advertize 4.0 to 3.5.x users before
> then if we want?
Yes.

(In reply to comment #24)
> Comment on attachment 522900 [details] [diff] [review]
> patch rev1
> 
> Do we need a test for this?
Would be nice but this is 3.6 where we can't install / uninstall add-ons.

Comment 27

[Robert Strong (they/them - no direct email)]

Comment on attachment 522900 [details] [diff] [review]
patch rev1

Regretfully, there is no way to test this on 1.9.2 though this is already tested on 2.0.

Comment 28

[Daniel Veditz [:dveditz]]

Comment on attachment 522900 [details] [diff] [review]
patch rev1

Approved for 1.9.2.17, a=dveditz

Comment 29

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-1.9.2
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/5cd0a3c68050

No way to test this on 1.9.2 without restartless add-ons and this is already part of litmus.