Progress dialog shows no progress meter and text files in field

VERIFIED FIXED

Status

P2
normal
VERIFIED FIXED
18 years ago
3 years ago

People

(Reporter: jimmykenlee, Assigned: dbragg)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+][PDTP2])

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
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
(Reporter)

Comment 2

18 years ago
Bug 47597 may be related to this bug.

Comment 3

18 years ago
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
Whiteboard: [nsbeta3+]
(Reporter)

Comment 5

18 years ago
It definitely comes and goes.  I cannot reproduce the problem with today's 
builds :-(  But I suspect that it will come back. :-(

Comment 6

18 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]
(Reporter)

Comment 7

18 years ago
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.
(Assignee)

Comment 8

18 years ago
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
(Reporter)

Comment 9

18 years ago
No new changes today.  That's a good thing.  Marking Verified.
Status: RESOLVED → VERIFIED
(Assignee)

Comment 10

18 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

18 years ago
Created attachment 19558 [details] [diff] [review]
Diff using -u8
Patch looks good, thanks for incorporating my suggestions.
r=dveditz

Comment 13

18 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

18 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

18 years ago
Created attachment 19571 [details] [diff] [review]
New patch incorporating mscott's suggestion

Comment 16

18 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

18 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
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 18

18 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

18 years ago
*** Bug 56710 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.