Closed Bug 351821 Opened 19 years ago Closed 19 years ago

A redundant button (Download and install now >) appears on 'Software Update' window

Categories

(Toolkit :: Application Update, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.8.1

People

(Reporter: scanorama346, Assigned: moco)

References

Details

(Keywords: fixed1.8.1, regression)

Attachments

(11 files, 2 obsolete files)

18.89 KB, image/jpeg
Details
15.32 KB, image/jpeg
Details
16.87 KB, image/png
Details
14.61 KB, image/png
Details
15.42 KB, image/png
Details
27.56 KB, image/png
Details
18.67 KB, image/png
Details
28.71 KB, image/png
Details
6.65 KB, patch
moco
: review+
Details | Diff | Splinter Review
17.15 KB, image/png
Details
5.91 KB, patch
moco
: review+
mtschrep
: approval1.8.1+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060908 Minefield/3.0a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060908 Minefield/3.0a1 As Minefield was downloading the partial update for 0908 nightly build, a redundant button appeared on the 'Software Update' window. This button is Download and Install now>' It'd make sense if this button appeared before the partial is being downloaded. Reproducible: Always Steps to Reproduce: 1.Run 'Check of update' 2.Download the partial 3.As the partial is downloading, the window will appear with the redundant button on it Actual Results: The button 'Download and install now >' appears on the 'software update' window. Expected Results: The button 'Download and install now >' shouldn't have appeared while partial is being downloaded. It should appear prior to that.
Version: unspecified → Trunk
Summary: Redundant button (Download and install now>) appears on 'Software Update' window → Redundant button (Download and install now >) appears on 'Software Update' window
Summary: Redundant button (Download and install now >) appears on 'Software Update' window → A redundant button (Download and install now >) appears on 'Software Update' window
Comment on attachment 237339 [details] A normal (correct) screenshot from BonEcho Beta 2. Thats what the 'Software update' window should look like. In Minefield, it doesn't have bacl, next and hide buttons. Instead it has Later and 'Download and install now >'
Attachment #237339 - Attachment description: A normal (correct) screenshot from BonEcho Beta 2. Thats what the 'Software update' window should look like → A normal (correct) screenshot from BonEcho Beta 2.
I can't reproduce this in 3 attempts, using a blank profile and the Windows 20060907 nightly.
WFM also
I don't use trunk as a daily browser, so my profile is almost extension free (only ntt to see build id) and I think I saw this once, while clicking on the "more info" button that turns into a link (don't have bug # for that)
When did this regress?
Keywords: regression
I'll investigate. my guess is we have some sort of js error which is preventing us from calling SetButtons() properly. to anyone who is seeing it, do you see anything in your js console?
Status: UNCONFIRMED → NEW
Ever confirmed: true
good news, bad news. bad news, I can't reproduce this. good news, I think my theory was right. see http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/update/content/updates.js#1183 my guess: the call to "gUpdates.update.detailsURL" in gDownloadingPage.onPageShow() is throwing an exception, so we never call setButtons(). 1183 var link = document.getElementById("detailsLink"); 1184 link.href = gUpdates.update.detailsURL; 1185 1186 gUpdates.setButtons(null, true, null, true, null, true, "hideButton", 1187 false, false, null, false, null, false); if you return before calling setButtons(), I can get the same UI as reported here. (I'll attach a screen shot) adding a try / catch can't hurt, and I'll whip up a patch. but if someone has steps to reproduce the bug, or has info from their error console, please let me know. (cc'ing dietrich and bsmedberg, as we three are on the only ones who have touched the client side update code in the past week)
Assignee: nobody → sspitzer
(In reply to comment #9) > my guess: the call to "gUpdates.update.detailsURL" in > gDownloadingPage.onPageShow() is throwing an exception, so we never call > setButtons(). The detailsURL property calls the URLFormatter, which I thought might have been the culprit. However, exceptions there look to be caught: http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/update/src/nsUpdateService.js.in#834 I haven't been able to reproduce this yet.
this is the "red flag" I raised at today's bon echo meeting. I think, at the least, I want to add some try / catch / dumps to trunk and branch in order to wallpaper, and to track down the issue.
Status: NEW → ASSIGNED
Flags: blocking-firefox2?
(In reply to comment #12) > this is the "red flag" I raised at today's bon echo meeting. > > I think, at the least, I want to add some try / catch / dumps to trunk and > branch in order to wallpaper, and to track down the issue. > Has anyone seen this on branch? So far I've unsuccessfully tried to repro with both full and partial updates on trunk Mac/Win and branch Mac.
dietrich: I have not, and I asked marcia (who updates several machines frequently) and she has not either. the only time I have every seen something close was when I "forced" an error.
Flags: blocking-firefox2? → blocking-firefox2+
I managed to reproduce this updating with partial to "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060913 Minefield/3.0a1 ID:2006091304 [cairo]". What I did was click on "download and install" while "more info" is still a button (don't remember that bug number)
> What I did was click on "download and install" while "more info" is > still a button (don't remember that bug number) this implies that the button did (after some time) turn into a link. is that the case?
chatting with dietrich over aim, we have a two part plan. he's working on some try/catch wallpaper, and I have a fix for these issues: 1) "more details>>" button is possibly clickable so we could be calling onShowMoreDetails() twice. 2) "Next" button is possibly clickable before we have shown the details, including the add-ons incompatible warnings. the fix for these is to: a) remove the "more details>>" button. we already always call onShowMoreDetails(). instead, show some "Please wait..." text. note, we are after the l10n-freeze, so I am getting this string from another dtd. for the trunk, I'd like to show "Checking add-ons incompatibility..." or something better. b) disable the back and next buttons. at the end of onPageShow(), we call setButtons() which will set up the buttons.
Attached patch patch (obsolete) — Splinter Review
Attachment #238244 - Flags: review?(dietrich)
because we are past the l10n freeze, I am using "Please wait..." from chrome://pippki/locale/pippki.dtd robert / bsmedberg / anyone: anyone have another string they know about in toolkit (if possible) that I could re-use?
This isn't ideal but there is the following in toolkit's extensions.properties installWaiting=Waiting...
Comment on attachment 238244 [details] [diff] [review] patch tested against branch, looks ok. r=me
Attachment #238244 - Flags: review?(dietrich) → review+
Attached patch wallpapering to cover comment #9 (obsolete) — Splinter Review
Attachment #238254 - Flags: review?(sspitzer)
Comment on attachment 238254 [details] [diff] [review] wallpapering to cover comment #9 I like this for both trunk and branch.
Attachment #238254 - Flags: review?(sspitzer) → review+
mconnor recommends we land both fixes on the trunk (except for a trunk version of my patch, that doesn't require pippki.dtd) so that it can bake. I'll go create a trunk version with my patch and dietrich's patch.
I am going to carry over dietrich's r=
Attachment #238379 - Flags: review+
I chose a string that matched this one: <!ENTITY incompatible.warning "This update will cause some of your extensions and/or themes to stop working until they are updated."> I'll seek further word smithing from beltzner / reed on the trunk.
fixed on the trunk. will seek approval for the branch
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: [fix landed on the trunk, seeking approval for the branch]
Target Milestone: --- → Firefox 2
this has r=dietrich (and r=sspitzer on the part from dietrich)
Attachment #238244 - Attachment is obsolete: true
Attachment #238254 - Attachment is obsolete: true
Attachment #238387 - Flags: review+
Attachment #238387 - Flags: approval1.8.1?
Comment on attachment 238387 [details] [diff] [review] complete branch patch a=schrep - this was a blocker bug and we want to get it into the nightly update cycle for better testing.
Attachment #238387 - Flags: approval1.8.1? → approval1.8.1+
fix landed on the branch as well. as schrep points out: in the wild, it will take 2 cycles to get this. the first update will contain the fix, and the next update will exercise it.
Keywords: fixed1.8.1
Whiteboard: [fix landed on the trunk, seeking approval for the branch]
I'd like to add a "busy" image to the left of the "Please wait" text, in order to show activity. I'll log a new bug for that (and seek ui-r from beltzner / mconnor)
> I'd like to add a "busy" image to the left of the "Please wait" text, in order > to show activity. I'll log a new bug for that see bug #352675. thanks to dietrich for fixing that, and for fixing a scrollbar issue (if the "Please wait..." text is long.
Will the patch land on Thunderbird too?
> Will the patch land on Thunderbird too? yes, recent tbird version 2 beta 1 builds will have the fix, since it is built of the MOZILLA_1_8_BRANCH.
Blocks: 350490
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: