Closed
Bug 11210
Opened 25 years ago
Closed 16 years ago
Need better install progress meter for win32 installer
Categories
(SeaMonkey :: Installer, defect, P2)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: cathleennscp, Unassigned)
References
Details
(Keywords: helpwanted, polish, Whiteboard: [adt3 RTM])
Attachments
(2 files)
25.62 KB,
image/gif
|
Details | |
3.49 KB,
patch
|
curt
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 2•24 years ago
|
||
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.
Comment 3•24 years ago
|
||
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?
Keywords: polish
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.
Comment 6•24 years ago
|
||
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 → ---
Comment 7•24 years ago
|
||
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.
Comment 11•23 years ago
|
||
Unsetting missed milestones to aid triage queries.
Target Milestone: M18 → ---
Comment 12•23 years ago
|
||
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
Comment 13•22 years ago
|
||
well in theory for all, but it started out with Win32. over to Curt.
Assignee: ssu → curt
Status: ASSIGNED → NEW
Target Milestone: --- → Future
Comment 14•22 years ago
|
||
Comment 15•22 years ago
|
||
*** Bug 137125 has been marked as a duplicate of this bug. ***
Comment 16•22 years ago
|
||
*** Bug 138486 has been marked as a duplicate of this bug. ***
Comment 17•22 years ago
|
||
*** Bug 138648 has been marked as a duplicate of this bug. ***
Comment 18•22 years ago
|
||
*** Bug 139145 has been marked as a duplicate of this bug. ***
Comment 19•22 years ago
|
||
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?
Keywords: nsbeta1
Comment 20•22 years ago
|
||
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
Comment 21•22 years ago
|
||
Cool, thanks Sean.
Comment 22•22 years ago
|
||
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
Comment 23•22 years ago
|
||
Discussed in Mail News bug meeting. Decided to assign to Syd this bug.
Assignee: ssu → syd
Comment 24•22 years ago
|
||
*** Bug 149713 has been marked as a duplicate of this bug. ***
Comment 25•22 years ago
|
||
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]?
Comment 26•22 years ago
|
||
sure, why not: adt2. Not sure who's really going to do the work, though, nor how you'd like it to look.
Comment 27•22 years ago
|
||
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.
Comment 28•22 years ago
|
||
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.
Comment 29•22 years ago
|
||
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.
Comment 30•22 years ago
|
||
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.
Comment 31•22 years ago
|
||
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%
Comment 32•22 years ago
|
||
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!
Comment 33•22 years ago
|
||
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.
Comment 34•22 years ago
|
||
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
Comment 35•22 years ago
|
||
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.
Updated•22 years ago
|
Target Milestone: Future → ---
Comment 36•22 years ago
|
||
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 38•22 years ago
|
||
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
Updated•22 years ago
|
Attachment #86886 -
Flags: review+
Comment 39•22 years ago
|
||
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
Updated•21 years ago
|
QA Contact: bugzilla → ktrina
Comment 40•21 years ago
|
||
What is the current Situation, I still can find this problem in 1.3a???
Comment 41•21 years ago
|
||
Yes, the installmeter for 1.3a is still the same ugly one :-/
Comment 42•21 years ago
|
||
I think the progress meter is cool.
Updated•19 years ago
|
Product: Browser → Seamonkey
Comment 43•18 years ago
|
||
(In reply to comment #36) > Created an attachment (id=86886) [edit] > 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
Updated•18 years ago
|
QA Contact: bugzilla → general
Comment 44•16 years ago
|
||
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.
Description
•