11210 - Need better install progress meter for win32 installer

Status: RESOLVED INVALID

(SeaMonkey :: Installer, defect, P2)

Description

[Sean Su]

setting target milestone to M10

Comment 1

[Sean Su]

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

[Matthew T (active 1999-2002)]

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

[Michael La Guardia]

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?

Comment 4

[Sean Su]

there's still a chance.

Comment 5

[Sean Su]

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

[Matthew T (active 1999-2002)]

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.

Comment 7

[Matthew T (active 1999-2002)]

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 8

[Matthew T (active 1999-2002)]

*** Bug 33356 has been marked as a duplicate of this bug. ***

Comment 9

[Sean Su]

mass change to M16

Comment 10

[timeless]

fwiw escape of & is &&.  To get it underlined use &&&.

Comment 11

[Daniel Veditz [:dveditz]]

Unsetting missed milestones to aid triage queries.

Comment 12

[Henrik Gemal]

taking this one.
btw: is this only win32 or OS=all ?
I just assumed win32

Comment 13

[Sean Su]

well in theory for all, but it started out with Win32.  over to Curt.

Comment 14

[Henrik Gemal]

Attachment: weird progress indication

Comment 15

[Henrik Gemal]

*** Bug 137125 has been marked as a duplicate of this bug. ***

Comment 16

[Henrik Gemal]

*** Bug 138486 has been marked as a duplicate of this bug. ***

Comment 17

[Henrik Gemal]

*** Bug 138648 has been marked as a duplicate of this bug. ***

Comment 18

[John Levon]

*** Bug 139145 has been marked as a duplicate of this bug. ***

Comment 19

[Gregg Landskov (gone)]

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?

Comment 20

[Sean Su]

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.

Comment 21

[Gregg Landskov (gone)]

Cool, thanks Sean.

Comment 22

[Gregg Landskov (gone)]

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!

Comment 23

[Michael Buckland]

Discussed in Mail News bug meeting.  Decided to assign to Syd this bug.

Comment 24

[Henrik Gemal]

*** Bug 149713 has been marked as a duplicate of this bug. ***

Comment 25

[Gregg Landskov (gone)]

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

[Daniel Veditz [:dveditz]]

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

[Gregg Landskov (gone)]

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

[Daniel Veditz [:dveditz]]

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

[Gregg Landskov (gone)]

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

[Sean Su]

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

[Henrik Gemal]

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

[Jaime Rodriguez, Jr.]

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

[Gregg Landskov (gone)]

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

[Jaime Rodriguez, Jr.]

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!

Comment 35

[Gregg Landskov (gone)]

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.

Comment 36

[Sean Su]

Attachment: 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.

Comment 37

[scottputterman]

marking nsbeta1- again.  

Comment 38

[Curt Patrick (gone)]

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

Comment 39

[Sean Su]

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

Comment 40

[Chan Min Wai]

What is the current Situation, I still can find this problem in 1.3a???

Comment 41

[Anders Åge Larsen]

Yes, the installmeter for 1.3a is still the same ugly one :-/

Comment 42

[John Brahy]

I think the progress meter is cool. 

Comment 43

[Wayne Mery (:wsmwk)]

(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?

Comment 44

[Wayne Mery (:wsmwk)]

against obsolete installer => invalid