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.
Bug 47597 may be related to this bug.
another cousin is bug 45890
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
It definitely comes and goes. I cannot reproduce the problem with today's builds :-( But I suspect that it will come back. :-(
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
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
No new changes today. That's a good thing. Marking Verified.
Status: RESOLVED → VERIFIED
Re-opening. The "intermittent" aspect of this bug made it look fixed but it wasn't completely.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Patch looks good, thanks for incorporating my suggestions. r=dveditz
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.
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.
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
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
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
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
*** Bug 56710 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.