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)
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.
Reporter | ||
Updated•19 years ago
|
Version: unspecified → Trunk
Reporter | ||
Comment 1•19 years ago
|
||
Reporter | ||
Updated•19 years ago
|
Summary: Redundant button (Download and install now>) appears on 'Software Update' window → Redundant button (Download and install now >) appears on 'Software Update' window
Reporter | ||
Updated•19 years ago
|
Summary: Redundant button (Download and install now >) appears on 'Software Update' window → A redundant button (Download and install now >) appears on 'Software Update' window
Reporter | ||
Comment 2•19 years ago
|
||
Reporter | ||
Comment 3•19 years ago
|
||
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.
Comment 4•19 years ago
|
||
I can't reproduce this in 3 attempts, using a blank profile and the Windows 20060907 nightly.
Comment 6•19 years ago
|
||
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)
Assignee | ||
Comment 8•19 years ago
|
||
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
Assignee | ||
Comment 9•19 years ago
|
||
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
Assignee | ||
Comment 10•19 years ago
|
||
Comment 11•19 years ago
|
||
(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.
Assignee | ||
Comment 12•19 years ago
|
||
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?
Comment 13•19 years ago
|
||
(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.
Assignee | ||
Comment 14•19 years ago
|
||
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.
Updated•19 years ago
|
Flags: blocking-firefox2? → blocking-firefox2+
Comment 15•19 years ago
|
||
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)
Assignee | ||
Comment 16•19 years ago
|
||
> 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?
Assignee | ||
Comment 17•19 years ago
|
||
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.
Assignee | ||
Comment 18•19 years ago
|
||
Attachment #238244 -
Flags: review?(dietrich)
Assignee | ||
Comment 19•19 years ago
|
||
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?
Assignee | ||
Comment 20•19 years ago
|
||
Assignee | ||
Comment 21•19 years ago
|
||
Assignee | ||
Comment 22•19 years ago
|
||
Assignee | ||
Comment 23•19 years ago
|
||
Assignee | ||
Comment 24•19 years ago
|
||
![]() |
||
Comment 25•19 years ago
|
||
This isn't ideal but there is the following in toolkit's extensions.properties
installWaiting=Waiting...
Comment 26•19 years ago
|
||
Comment on attachment 238244 [details] [diff] [review]
patch
tested against branch, looks ok. r=me
Attachment #238244 -
Flags: review?(dietrich) → review+
Comment 27•19 years ago
|
||
Attachment #238254 -
Flags: review?(sspitzer)
Assignee | ||
Comment 28•19 years ago
|
||
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+
Assignee | ||
Comment 29•19 years ago
|
||
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.
Assignee | ||
Comment 30•19 years ago
|
||
I am going to carry over dietrich's r=
Attachment #238379 -
Flags: review+
Assignee | ||
Comment 31•19 years ago
|
||
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.
Assignee | ||
Comment 32•19 years ago
|
||
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
Assignee | ||
Comment 33•19 years ago
|
||
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 34•19 years ago
|
||
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+
Assignee | ||
Comment 35•19 years ago
|
||
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]
Assignee | ||
Comment 36•19 years ago
|
||
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)
Assignee | ||
Comment 37•19 years ago
|
||
> 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.
Assignee | ||
Updated•19 years ago
|
Depends on: majorupdate
Reporter | ||
Comment 38•19 years ago
|
||
Will the patch land on Thunderbird too?
Assignee | ||
Comment 39•19 years ago
|
||
> 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.
Updated•17 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•