Installer is unresponsive when installing. At the minimum it should respond to update, and activate events. I accidentally clicked in the background prior to the install and could not bring the dialog forward until the end of the installation. Found in today's 3/20 beta1 commercial build
|
||
Comment 1•18 years ago
|
||
We give the OS 1 tick every WaitNextEvent(). Since SmartDownload shares the main event loop, by experimentation we found that giving the OS anymore time significantly slows download and install time. One possible remedy is to increase the number of ticks given to the OS at install time, but leave it at 1 during download. So the installer will still appear unresponsive during download but will regain responsiveness during install. Scheduling for M17.
|
||
Comment 2•17 years ago
|
||
Ping: M17 has passed. At the moment, if during the copying process you bring another application to the front and then bring the installer back to the front, the installer will fail to update even its own display -- only the progress indicators will be updated.
|
|
||
Updated•17 years ago
|
||
Expect a minus, If so please add this to the relnote3. Adding helpwanted per nsbeta3- I think the suggestion in 2000-03-20 10:33 makes sense, can someone external write the patch? Marking relnote because I'm sure mac users would like to know if mozilla's installer crashed or is actually doing something.
|
||
Updated•17 years ago
|
||
|
|
||
Updated•17 years ago
|
||
|
||
Updated•17 years ago
|
||
|
|
||
Updated•17 years ago
|
||
|
|
||
Comment 5•17 years ago
|
||
Unsetting missed milestones to aid triage queries.
|
|
||
Comment 6•16 years ago
|
||
Over to Syd for installer bug triage
Quoth Steve Dagley: "The Mac installer code was never Carbonized and there is no intention to ever change that." http://groups.google.com/groups?threadm=yahoo_com-77F6E8.09344011022003%40h-204-29-187-156.netscape.com http://groups.google.com/groups?threadm=avkj4k%24ihs2%40ripley.netscape.com
|
||
Updated•13 years ago
|
||
Description
•