Closed Bug 11210 Opened 25 years ago Closed 16 years ago
Need better install progress meter for win32 installer
Summary: install progress window for Windows Wizard → [feature] install progress window for Windows Wizard
setting target milestone to M10
Summary: [feature] install progress window for Windows Wizard → Need better install progress window for Windows Wizard
Target Milestone: M10 → M15
This is has been added, but it's not the final look/feel that we might want to give the users for RTM. I'll leave this unfixed, but will update the Summary and Target Milestone appropriately.
The main problem I have with the dialog is that the overall progress indicator and the individual-file progress indicator are confused. How about this: +------------------------------------+ |Installing Mozilla :::::::::::::::::| +------------------------------------+ | Total progress: | | [########::::::::::::::::::::::::] | | | | Time remaining: about 40 seconds | | | | Copying file: navigator.xul | | [######################::::::::::] | | | | ( Cancel ) | +------------------------------------+ Note: The progress indicator for an individual file should *only* be shown if it has been estimated (from current transfer speeds) that the rest of the file will take at least two seconds to copy. Any shorter than that, and the indicator will appear and disappear so quickly as to be useless.
adding polish keyword. I don't think we should hold beta for this, but we had talked about getting the changes in. Do we have a chance of making it?
there's still a chance.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
fixed. There's no cancel button because the underlying engine does not have such a support (yet). Everything else is there to make it have a better look and feel.
Well, that's better than it was before, but there's still some minor glitches. * The overall progress indicator isn't nearly granular enough. When installing both browser and mail/news, the indicator only stops at ~3 points along the way. It should update more often, otherwise don't bother including it. Not updating it during prepare-file stages would be ok (presumably because you don't know how many files there are going to be), but during the copy stage it should update as often as the copy-file indicator. (So when installing both components, it could jump from 0% to 25% after browser files have been prepared, then slide to 50% during the copying of browser files, then jump to 75% after mail/news files have been prepared, then slide to 100% during the copying of mail/news files.) * The indeterminate-progress indicator, shown during the `prepare-file' stage, looks silly IMO, especially since indeterminate progress is already being shown by the rapidly-changing filenames. It might be better to hide this indicator except when actually copying files. * In `Currently Installing xyz', the word `Currently' is unnecessary. Put a colon after `Installing' instead. * In `Currently Installing MailNews', the `N' is underlined. Probably a typo, where it was meant to be the slash in `Mail/News'. * When copying files for mail/news, the background of the second indicator goes white, whereas the rest of the time it's the UI default color (e.g. gray). Reopening and downgrading to minor.
Severity: normal → minor
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I wrote: > > * In `Currently Installing MailNews', the `N' is underlined. Probably a typo, > where it was meant to be the slash in `Mail/News'. Actually, this happens in the component selection dialog as well -- click on `Mail&News' (why isn't it `Mail & News'?) in the component list, and the description shows the N underlined. I think this is where Windows assumes that a & character means the next character in the string should be underlined. So, before printing them in dialogs, you need to run component names through a procedure which escapes out any `&' characters so that they actually appear as `&' and not as underlines.
*** Bug 33356 has been marked as a duplicate of this bug. ***
mass change to M16
Target Milestone: M15 → M16
fwiw escape of & is &&. To get it underlined use &&&.
Unsetting missed milestones to aid triage queries.
Target Milestone: M18 → ---
taking this one. btw: is this only win32 or OS=all ? I just assumed win32
OS: other → Windows 2000
QA Contact: gbush → gemal
Summary: Need better install progress window for Windows Wizard → Need better install progress meter for win32 installer
well in theory for all, but it started out with Win32. over to Curt.
Assignee: ssu → curt
Status: ASSIGNED → NEW
Target Milestone: --- → Future
*** Bug 137125 has been marked as a duplicate of this bug. ***
*** Bug 138486 has been marked as a duplicate of this bug. ***
*** Bug 138648 has been marked as a duplicate of this bug. ***
*** Bug 139145 has been marked as a duplicate of this bug. ***
nominating nsbeta1. This ugly bug has been around forever, it needs to be cleaned up for rtm. The install progress bar (not the download one) has completely inconsistent behavior. Sometimes it goes back and forth, sometimes it just goes left to right, sometimes it is a solid bar from left to right, sometimes it is a smaller bar, and yet other times the solid bar breaks in half, then comes back together, then proceeds on. ADT - please consider strongly for rtm, it makes us look sloppy. Curt - have you looked at this yet?
This problem in the installer is more obvious now days because the size of the .xpi files have changed, thus changing the speed and size of the progress bar(s). I've been wanting to fix this for the longest time, but its visibility was not as much as it is now. It think I know what's causing this. Taking this.
Assignee: curt → ssu
Cool, thanks Sean.
Sean, Putterman mentioned that you might not be able to fix this because of other committments. You mentioned you know what is causing it. Can you let me know again if you can do it, or if you can pass it off to someone who can? I would really like to get this plussed and adt rated asap. Thanks!
Priority: P5 → P2
Discussed in Mail News bug meeting. Decided to assign to Syd this bug.
Assignee: ssu → syd
*** Bug 149713 has been marked as a duplicate of this bug. ***
Syd/Dan/Sean/Grace/Henrik - This bug still was never triaged by the install team. I would like to suggest this as an ADT2. There was additional feedback since the release of 7.0 PR1 that reinforces how sloppy this looks. We should *really* fix it for rtm. Would you agree to assign this bug an [ADT2]?
sure, why not: adt2. Not sure who's really going to do the work, though, nor how you'd like it to look.
Sean mentioned that he thinks he knows where and how to fix it. My thoughts on how it should look is that it should be consistent. For each component, the bottom meter should progress left to right until the component is finished. The top meter shows the total progress and appears to be working fine.
A left to right meter is only possible when you know how long something is going to take. The slopping back and forth is an attempt to show an "indeterminant" state like the barber pole in modern, that is, we're still doing something, don't kill us off. The only left-to-right motion we could do was some random motion over and over until we're done. Users might think something was supposed to change when the bar got to the right, but since the top bar shows us unfinished I guess they won't be expecting too much. I guess that'd be better than the "Oh no! it's lost it's mind!" reaction we get now. If we dropped the display of each filename it would probably go somewhat faster, by the way.
Don't we know how many files are associated with each component? Couldn't we make a linear relationship and have each file of the component represent x% of the total? Granted it would probably be a little herky jerky because each file has a different size, but it would probably be much better than it currently is. I guess I would also be fine with it going back and forth as long as it was consistent, but as I said in comment #19, right now it does about 4 different behaviors. If neither of these options were viable and worse comes to worse, I wouldn't be opposed to removing the bottom bar altogether and just have the top overall status.
the part that we don't know (the sloshing back and forth) is because we're uncompressing the files from the .xpi archive. Right now, libjar does not tell us how many total files there are. If we could get that info, we can get rid of the sloshing back and forth. But this means a change in the libjar code. Not sure if we want this right now or not.
I dont really see the need for a progress on each component. Just have one progres meter, a total one. Most users dont care about each component. Something like this would be more helpfull: Currently installing : XPCOM Total Progres : 0% [ooooooooooooo........] 100% 55%
too late to be designing polish-type bugs that are marked future. nsbeta1-/[adt3 RTM] per ADT triage. let's keep our focus on high visibility adt1 bugs for 1.0.1, that will make this a slammin' release. thanks!
It was only marked future because it is an extremely old bug and this drop down box wasn't updated!!! It was never turned off of future due to oversight! Jaime - this bug has been around since 6.0, and something needs to be done about it, even if the problematic bottom progress meter goes away entirely. Something needs to be done about it. Renominating nsbeta1, removing ADT rating to get this back on radar.
ADT impact can be changed, from ADT3 to 2 or 3 (and, only after discussion with the ADT), but NOT removed. Adding [adt3 RTM] back. Its still too late for taking a polish bug that has not been designed, nor has consensus on how it should work. --> Buffy btw - only engineer can change the milestone, so setting that back to future, less you have curt's buyin to do so. If you do, pls feel free to change it back to 1.0.1. thanks!
Whiteboard: [adt3 RTM]
Target Milestone: mozilla1.0.1 → Future
It doesn't need to be designed, just fixed. There are several ways it can be fixed which is what the discussion has centered around. I have had talked about this bug with Curt, Sean, Dan, & Grace. To avoid butting more heads, I will follow up with them *again* to try to see the feasibility.
fixes the problem shown in the attached image. this is not a rework of the dialog at all. just fixing up the broken progress bar.
Comment on attachment 86886 [details] [diff] [review] patch v1.0 I see that I haven't been paying enough attention to this discussion. It appears that, although I really don't care for the sloshing back and forth behavior, we are stuck with it for this release. Sean, is it worth opening another bug against this specific behavior (i.e., getting the progress bar to always progress to the right), or are you saying it just isn't doable with what we have to work with? There also seems to be a need to generally redesign this dialog for some future release. How should be track that? Should we leave this bug open for that purpose, or open some kind of PRD requirement or what? So, it looks like Sean's fix very specifically addresses only the odd behavior wherein the progress indicator would sometimes be broken into multiple pieces. And it further appears that this is all we can reasonably address for rtm. I'm in agreement with this, have tried the patch out and am satisfied that it fixes this one particularly egregious bit of behavior. So... r=curt
okay I've filed a new bug (bug 150678) to deal with the choppy/messed up looking progress bar. the attachments have been attached to the new bug too
What is the current Situation, I still can find this problem in 1.3a???
Yes, the installmeter for 1.3a is still the same ugly one :-/
I think the progress meter is cool.
(In reply to comment #36) > Created an attachment (id=86886)  > patch v1.0 > > fixes the problem shown in the attached image. this is not a rework of the > dialog at all. just fixing up the broken progress bar. is this patch worth anything?
Assignee: curt → general
QA Contact: ktrina → bugzilla
against obsolete installer => invalid
Status: NEW → RESOLVED
Closed: 24 years ago → 16 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.