Empty update dialog after clicking notification

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: george.carstoiu, Assigned: rstrong)

Tracking

1.9.2 Branch
Points:
---
Bug Flags:
in-testsuite -
in-litmus +

Firefox Tracking Flags

(status2.0 unaffected, blocking1.9.2 .17+, status1.9.2 .17-fixed, status1.9.1 unaffected)

Details

(Whiteboard: [mu][hardblocker])

Attachments

(2 attachments)

Reporter

Description

8 years ago
Posted image 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

8 years ago
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
OS: Linux → Windows CE
OS: Windows CE → All
Hardware: x86_64 → All
Summary: Clicking on the update notification that appears in the right corner of the screen displays blank window with non-functional buttons → Empty update dialog after clicking notification
Confirmed this is happening -- seems to only affect Firefox 3.6.16 builds (3.5.18 is ok).
blocking2.0: --- → ?
rs, are these sensible timer settings to be using ? They're different to the ones suggested in bug 539308.
Component: General → Application Update
Product: Firefox → Toolkit
QA Contact: general → application.update
Version: 3.6 Branch → 1.9.2 Branch
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?
Al, looks like the QA documentation you fixed in bug 539308 changed.
(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.
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.
This is still reproducible using the following values:
app.update.idletime = 1
app.update.interval = 30
app.update.timer = 30000
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?
(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.
The official numbers come from bug 539308.

Who told them these "official" numbers?
As far as the litmus test, it looks like I fumble-fingered and missed a zero.
(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
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?
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)
Thanks, that gives me something to go on
Posted patch patch rev1Splinter Review
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.
Assignee: nobody → robert.bugzilla
Status: NEW → ASSIGNED
Attachment #522900 - Flags: review?(dtownsend)
Whiteboard: [mu][hardblocker]
blocking1.9.2: --- → ?
blocking2.0: ? → ---
Drivers, this affects update notification but does not affect the manual check for updates.

Comment 19

8 years ago
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?
(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
(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?
blocking1.9.2: ? → .17+
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?
(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 on attachment 522900 [details] [diff] [review]
patch rev1

Do we need a test for this?
Attachment #522900 - Flags: review?(dtownsend) → review+
(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...
(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 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.
Attachment #522900 - Flags: approval1.9.2.17?
Comment on attachment 522900 [details] [diff] [review]
patch rev1

Approved for 1.9.2.17, a=dveditz
Attachment #522900 - Flags: approval1.9.2.17? → approval1.9.2.17+
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.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Flags: in-testsuite-
Flags: in-litmus+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.