45890 - installer's progress meter is stuck on linux

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P3)

Description

[R.K.Aa.]

when installer gets to the part where progress-meter displays, it initially
shows a progress-meter about an inch long, and during the whole download this
indicator does not move at all. Which can be confusing to users, and mislead
them to believe that the download isn't going so well.

Noticed this in installer from yesterday and today. (haven't tried it before)

Comment 1

[Sean Su]

reassigning to Samir.

Comment 2

[Samir Gehani]

Fixed.

Comment 3

[Grace Bush]

build 2000072408

Comment 4

[R.K.Aa.]

there is still a problem: Now the window won't refresh, or refreshes very very
slow.
There is/was a bug on extremely high CPU usage during download. The CPU usage
isn't high anymore and the download seems to go OK. I believe the suggested fix
for the CPU usage was to not poll so often. The fix may have influenced this
bug?

As it is now, when you cover the window with another app, and uncover it again -
it becomes all grey, slightly darker grey in the area where the progress-meter
should have been located.

Comment 5

[Samir Gehani]

Some more fixes for this will go in today.  I only tested this in the case where 
the xpis are co-loacted with the installer.  This morning while resolving 
another bug I found that when teh xpis are to be download the progress meter has 
some flaws.  And yes, this bug fix fixed the CPU usage bug.  I'll go find it and 
resolve that too.  Thanks for pointing the latter out.

Comment 6

[R.K.Aa.]

are you aware that the directory to which the download is performed has changed
location?

Earlyer it went into a subdir of mozilla-installer (the dir where the gz unzips)
But now it creates the download dir one floor up so to speak. In ../.tmp.xi.0
instead of .tmp.xi.0 in other words.
(meaning for instance /tmp/mozilla-installer/.tmp.xi.0 is now /tmp/.tmp.xi.0)

Not a problem - it is fair to assume user has write-access to the directory
immediately above. Just an observation.


The CPU installer bug is bug 40632 btw.

Comment 7

[Samir Gehani]

R.K.Aa.,
I had to change the location of download due to anotehr bug: making the linux 
installer CD-compatible.  We couldn't assume cwd since cwd on the read-only CD 
media won't quite work when trying to write downloaded bits :o)  In reality we 
ship with the bits in a directory co-located with the installer called 'xpi' 
which conatins the .xpis.  However, the installer copies the required .xpis to a 
tmp location during install and deletes them when done (bad design to duplicate 
that may change in the future).  The problem of writing to cwd instead of local 
disk is alleviated by writing to tmp in this case.  Hope this helps.  And I 
assume all users will have access to /tmp.

BTW, thanks for the CPU usage bug number.

Comment 8

[R.K.Aa.]

thanks for taking time to explain - i didn't do my homework well or i'd seen it
deliberatly wrote to /tmp and not ../