Closed
Bug 51816
Opened 24 years ago
Closed 24 years ago
Progress dialog shows no progress meter and text files in field
Categories
(Core Graveyard :: Installer: XPInstall Engine, defect, P2)
Core Graveyard
Installer: XPInstall Engine
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: jimmykenlee, Assigned: dbragg)
References
Details
(Whiteboard: [nsbeta3+][PDTP2])
Attachments
(2 files)
6.35 KB,
patch
|
Details | Diff | Splinter Review | |
7.11 KB,
patch
|
Details | Diff | Splinter Review |
Build: 2000-09-07-09-M18(WIN), 2000-09-07-04-M18(MAC), 2000-09-07-08-M18(LINUX) 1. From http://jimbob/trigger3.html, enter manyfiles.xpi into the first field 2. Click Trigger button to install 3. From confirm dialog, click Ok button RESULT: Progress dialog appears. "SmartUpdate Many Files" appears from the first field. No text appears from second field. Progress meter stays empty. EXPECTED RESULT: Text appears from second field showing what is being installed. Progress meter shows during download and then turns into "barber pole" during installation.
Also, installation does complete. There are no issues with the actual desired installation. Nominating for nsbeta3. With no status information during download and installation, it appears that the installation has already failed. It appears that the machine is "frozen". There would be a high probability that users would attempt to cancel the install since nothing appears to be happening.
Keywords: nsbeta3
Comment 4•24 years ago
|
||
This appears to come and go, and it's not in an area where we changed anything, but it needs to work or people updating Mozilla (which takes a while!) will think it's hung. nsbeta3+ and reassigning to dbragg
Assignee: dveditz → dbragg
Priority: P3 → P2
Whiteboard: [nsbeta3+]
It definitely comes and goes. I cannot reproduce the problem with today's builds :-( But I suspect that it will come back. :-(
Comment 6•24 years ago
|
||
PDT agrees P2 if this bug still exists. Jimmy, could you retest and resolve it if you can't reproduce?
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP2]
Build: 2000-09-14-09-M18(WIN), 2000-09-14-08-M18(MAC), 2000-09-14-08-M18(LINUX) After much testing, I cannot reproduce the problem today. Currently, I am getting the expected behavior. This is something I see often, so if it comes up again, I will share the news.
Bugzilla is acting weird. Tried to mark WORKSFORME based on Jimmy's tests and my own. Trying again.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
No new changes today. That's a good thing. Marking Verified.
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 10•24 years ago
|
||
Re-opening. The "intermittent" aspect of this bug made it look fixed but it wasn't completely.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Assignee | ||
Comment 11•24 years ago
|
||
Comment 12•24 years ago
|
||
Patch looks good, thanks for incorporating my suggestions. r=dveditz
Comment 13•24 years ago
|
||
I was confused by this change: - "chrome,centered,titlebar,resizeable", + "chrome,centered,titlebar,resizable", resizeable is now mispelled. Is that intentional? Also instead of doing the following: NS_ConvertASCIItoUCS2("...") let's change the code that was there to use NS_LITERAL_STRING: NS_LITERAL_STRING("...").get(). Other than those two questions this patch looks good.
Assignee | ||
Comment 14•24 years ago
|
||
That's actually kind of funny. "resizeable" is incorrect as far as the code is concerned. What's funny is that I thought the same thing when I originally wrote it. Changing the spelling to resizable is actually correct. By the way, I looked it up in dictionary.com and resizeable or resizable are not words but both sizable and sizeable are both acceptable. Go figure. I'll make the other change and check it in.
Assignee | ||
Comment 15•24 years ago
|
||
Comment 16•24 years ago
|
||
I didn't realize the argument in question needed to be an nsString. In that case, using NS_LITERAL_STRING is the wrong thing to do. Go ahead and use the original patch =). thanks Don. sr=mscott
Assignee | ||
Comment 17•24 years ago
|
||
I'm pretty sure we've got it fixed now. There's still a huge dependency on what we get from http and ftp messages but there always will be. In fact ftp still has problems but it's not in our progress dialog code.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 18•24 years ago
|
||
Build: 2000-11-27-08-Mtrunk(LINUX), 2000-11-27-08-Mtrunk(WIN), 2000-11-27-08-Mtrunk(MAC) Progress meter and text files display from progress dialog.
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 19•24 years ago
|
||
*** Bug 56710 has been marked as a duplicate of this bug. ***
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•