rstrong's blog

It has been a good couple of weeks. There are several bugs I am relieved that are now fixed for Firefox 3.6… especially that we now check if Firefox is in use prior to updating and prevent launching Firefox during an update. Also, checking for updates for users that aren’t able to apply updates. Beltzner did his usual beltzner thing by catching what I see as a major usability flaw in that the original patch notified users repeatedly for the same release until Firefox was upgraded which I was able to fix. I’m still kicking myself for not catching that myself.

Progress:

• WOOT! Landed on trunk and 1.9.2 branch – Bug 407875 [Toolkit] – “Unprivileged users are not notified of security updates [All]“. The next bugs to fix that are similar are the dependent bugs of Bug 318855 [Toolkit] – “App update should provide method to update when the user doesn’t have privileges [All]“.
• Landed on trunk and 1.9.2 branch – Bug 510501 [Toolkit] – “not granting UAC permission to updater.exe causes full update to be downloaded [Windows]“. The next bug to fix that is similar is Bug 336267 [Toolkit] – “If software update is disabled or “ask” after an update has been downloaded, the update should be disabled or asked [All]“.
• Created a wiki page for the work on Bug 410639 [Toolkit] – “Provide ability to change update channel within the application [All]” and emailed dev-apps-firefox / dev-platform (followups to dev-apps-firefox) for this proposal.

Future targets (short work week so no way this will all get done):

• Bug 336267 [Toolkit] – “If software update is disabled or “ask” after an update has been downloaded, the update should be disabled or asked [All]“
• Investigate Bug 526441 [Toolkit] – “Unable to use FileUtils.jsm in nsExtensionManager.js.in on 1.9.2 due to reftest failures”.
• Yes, I still need to blog about the lessons I’ve learned while trying to improve startup time for app update but the Firefox 3.6 took precedence.
• Investigate Bug 529948 [Toolkit] – “Cannot check for updates on trunk when the download server is down” along with its friends

I’m taking Wednesday off so next week is a two day work week for me since Thursday and Friday are holidays.

To increase the participation in and awareness of application’s beta programs and specifically Firefox’s beta program we will be providing the ability to change the application update channel within the application. This will be an opt-in for each application.

The details in the wiki are by no means complete but they should provide a place to start from

wiki Application Update:Channel Change
Bug 410639 – Provide ability to change update channel within the application

Feedback / comments welcome preferably either in the dev-apps-firefox newsgroup / mail list or the wiki page’s discussion page though you can just respond in this blog if you prefer.

Progress:

• Landed on trunk and 1.9.2 branch – Bug 525390 [Toolkit] – 3.5.4 Upgrade failure: entry point js_SaveRegExpStatics could not be located [Windows / WinCE / WinMo]. This also fixes Bug 312010 [Toolkit] – possible to start firefox when the “Software Update” dialog is running [Windows / WinCE / WinMo]. Also filed the spinoff Bug 528603 [Toolkit] – Upgrade failure with Zone Labs / Zone Alarm ForceField: “entry point js_SaveRegExpStatics could not be located” [Windows] to track the fix Zone Labs is coming out with.
• Landed on trunk and 1.9.2 branch – Bug 523915 [Toolkit] – updater crashes when trying to update with crash reporter open [Windows].
• Landed on trunk and 1.9.2 branch – Bug 528445 [Toolkit] – change app.update.log.* in updates.js to app.update.log for UI logging [All].

Future targets:

• Still going to try to get Bug 407875 [Toolkit] – Unprivileged users are not notified of security updates fixed for Firefox 3.6.
• Investigate Bug 526441 [Toolkit] – Unable to use FileUtils.jsm in nsExtensionManager.js.in on 1.9.2 due to reftest failures.
• Finish up a couple of more reviews in my queue I haven’t had time to do.
• Still need to blog about the lessons I’ve learned while trying to improve startup time for app update but Firefox 3.6 is taking precedence.

Updated: Forgot to include in the progress section. Landed on trunk and 1.9.2 branch – Bug 527845 (WinCE only) [Toolkit] – App update can’t deal with read-only files [Windows CE]

With the landing of Bug 311965 time spent during startup in app update on mobile devices should have improved by around 72%. On Firefox WinCE this equates to reducing the time spent during startup in app update from over 180ms to around 50ms. This is on top of a previous reduction of around 25% from over 200ms to around 150ms as measured on Maemo Fennec and with this latest change I estimate the time spent in startup on Maemo Fennec to be around 40ms.

Progress:

• Landed on trunk and 1.9.2 branch – Bug 311965 [Toolkit] – Refactor nsUpdateService.js to load less code at startup.
• Landed on 1.9.2 branch – Bug 522583 [Toolkit] – nsUpdateService.js.in cleanup (remove previous update migration code, defineLazyServiceGetter for nsIObserverService, and other cleanup).
• Landed on 1.9.2 branch – Bug 521452 [Toolkit] – nsUpdateService and nsBlocklistService both have getFile(key, pathArray). Had to backout the changes to nsExtensionManager.js.in due to Bug 526441 [Toolkit] – Unable to use FileUtils.jsm in nsExtensionManager.js.in on 1.9.2 due to reftest failures.
• Landed on 1.9.2 branch – Bug 521956 [Toolkit] – nsUpdateService, nsExtensionManager.js.in and, nsBlocklistService include badCertHandler.js

Future targets:

• Finish up several decent sized reviews in my queue I haven’t had time to do.
• Blog about the lessons I’ve learned while trying to improve startup time for app update.
• Investigate Bug 525390 [Toolkit] – 3.5.4 Upgrade failure: entry point js_SaveRegExpStatics could not be located
• Investigate Bug 526441 [Toolkit] – Unable to use FileUtils.jsm in nsExtensionManager.js.in on 1.9.2 due to reftest failures.
• I’m going to try to get Bug 407875 [Toolkit] – Unprivileged users are not notified of security updates fixed for Firefox 3.6.

This last week I’ve been focusing on Fennec / Firefox WinCE TS for app update and it looks like we can save around 130ms on startup on Firefox WinCE when using Taras’ patch from Bug 470116 to log the time spent during startup… I expect a similar savings for Mobile Fennec.

Note: we really need to come up with a better way to update each app’s installer manifests and remove-files so when we make changes to toolkit code that adds / removes files we don’t have to get reviews from each app to land the changes. I know bsmedberg would like to remove the requirement for the manifest by only having the files that will be included in each installer under dist/bin but I wonder if it is realistic to do so since each app would need to do this.

Progress:

• Finished up the patch Bug 311965 [Toolkit] – Refactor nsUpdateService.js to load less code at startup.

so it is now ready to land as soon as I get patches for all app’s approved for landing. As time permits I will be blogging about the lessons I’ve learned while trying to improve startup time for app update.

Future targets:

• Land Bug 311965 [Toolkit] – Refactor nsUpdateService.js to load less code at startup.
• Finish up several decent sized reviews in my queue I haven’t had time to do.
• Bug 525390 [Toolkit] – 3.5.4 Upgrade failure: “entry point js_SaveRegExpStatics could not be located” [Windows]
• I’m going to try to get Bug 407875 [Toolkit] – Unprivileged users are not notified of security updates fixed for Firefox 3.6.

This last week I’ve been focusing on Fennec / Firefox WinCE TS for app update. According to Taras’ logs for Maemo Fennec this lessens the time spent in nsUpdateService.js during startup by around 50ms and there should be a similar win on Firefox WinCE.

Progress:

• Landed on the mozilla-1.9.2 branch – Bug 512651 [Toolkit] – lessen the write access checks during startup and remove final-ui-startup observer. According to Taras’ logs for Maemo Fennec this lessens the time spent in nsUpdateService.js during startup by around 50ms and there should be a similar win on Firefox WinCE. It appears that there was around a .5 % win on trunk Windows desktop TS as well though this may be a combo of this and Bug 521262 which landed at the same time on trunk.
• Landed on the mozilla-1.9.2 branch – Bug 521371 [Toolkit] – Extraneous ‘2′ written to the update log file.
• Landed on the mozilla-1.9.2 branch – Bug 521262 [Toolkit] – XREDirProvider provides app chrome dir twice, making us parse manifests twice. This caused non-xulrunner apps to parse the manifests in the app dir twice on startup so there might be a win on Firefox WinCE.
• Landed on trunk – Bug 521452 [Toolkit] – nsUpdateService and nsBlocklistService both have getFile(key, pathArray). This gets us closer to fixing Bug 311965 [Toolkit] – Refactor nsUpdateService.js to load less code at startup.
• Landed on trunk – Bug 522583 [Toolkit] – nsUpdateService.js.in cleanup (remove previous update migration code, defineLazyServiceGetter for nsIObserverService, and other cleanup). This gets us closer to fixing Bug 311965 [Toolkit] – Refactor nsUpdateService.js to load less code at startup.
• Patch in progress for Bug 311965 [Toolkit] – Refactor nsUpdateService.js to load less code at startup. This should translate into TS wins especially for Fennec and Firefox WinCE.

Future targets:

• Finish up Bug 311965 [Toolkit] – Refactor nsUpdateService.js to load less code at startup.
• I’m going to try to get Bug 407875 [Toolkit] – Unprivileged users are not notified of security updates fixed for Firefox 3.6.

Progress:

• Landed on trunk – Bug 513958 [Toolkit] – Firefox silently fails to start if %APPDATA% variable is missing. This is a crash on startup caused when the call to SHGetFolderPath, SHGetSpecialFolderLocation, SHGetPathFromIDListW, SHGetSpecialFolderPathW, and friends fail.
• Landed on trunk – Bug 521371 [Toolkit] – Extraneous ‘2′ written to the update log file.
• Landed on trunk – Bug 512651 [Toolkit] – lessen the write access checks during startup and remove final-ui-startup observer. This reduces time spent in nsUpdateService.js by around 50ms on Maemo and I suspect a similar win on WinCE.
• Landed on trunk – Bug 521262 [Toolkit] – XREDirProvider provides app chrome dir twice, making us parse manifests twice. This caused non-xulrunner apps to parse the manifests in the app dir twice on startup so there might be a win on Firefox WinCE.

Future targets:

• I’m going to continue invesitaging TS wins on Maemo / WinCE / WinMo in Bug 311965 [Toolkit] – Refactor nsUpdateService.js to load less code at startup. This may translate into TS wins in other components.

Most of the last couple of weeks has been spent reviewing patches and finishing up the patch for Bug 508684 where I spent more time than I should have churning over the correct approach to take. I should have the review finished for Bug 491947 [Firefox] – “Disable DDE shell integration” soon as well.

Progress:

• Landed on trunk, 1.9.2 branch, and 1.9.1 branch – Bug 508684 [Firefox:Installer] – Add Ability to Change “Firefox as your default browser” and inform of upgrade on Summary step. Note that the ‘inform of upgrade’ part didn’t land on the 1.9.1 branch since it required new strings. Also, adding this to the Summary step is only temporary until the process flow for the installer is changed in Bug 513414 [Firefox] – Reduce the number of installation steps on Windows
• Landed on trunk – Bug 471219 [Toolkit] – Store timer registrations somewhere permanent.
• Bug 507719 [Toolkit] – [Exception... "update.locale file doesn't exist in either the XCurProcD or GreD directories" is fixed on trunk (soon to be on the 1.9.2 branch) by the landing of Bug 471219. A different approach will need to be taken for the 1.9.1 branch

Future targets:

• Bug 512651 [Toolkit:Application Update] – lessen the write access checks during startup
• Bug 407875 [Toolkit:Application Update] – Unprivileged users are not notified of security updates
• Bug 496207 [Firefox:Installer] – Workaround zombie firefox.exe process during install
• Bug 315278 [Toolkit:Application Update] – Update process produces a broken application when disk space is low
• Bug 504911 [Toolkit:Application Update] – Failed partial doesn’t show ui for complete update for Firefox 3.0/3.5 partner builds from Yandex

I’m taking Friday off so I’m posting this early.

Progress:

• Landed on 1.9.2 branch (already landed on trunk) – Bug 470979 [Toolkit:Application Update] – Keep a copy of the last-update.log renamed when the partial fails for troubleshooting
• Landed on 1.9.2 branch (already landed on trunk) – Bug 512994 [Toolkit:Application Update] – Deleting / recreating the updates/0 directory puts the filesystem into a weird state on Windows CE / Windows Mobile
• Ready to land (tree hasn’t been green enough) – Bug 508684 [Firefox:Installer] – Add Ability to Change “Firefox as your default browser” and inform of upgrade on Summary step. Note: there is also a reviewed patch ready to go for for Firefox 3.5.x
• Patch in progress – Bug 496207 [Firefox:Installer] – Workaround zombie firefox.exe process during install
• It is worth noting that Jim Mathies’ patch in Bug 491947 will make it so we remove and no longer add the registry keys for DDE shell integration which should for all practical purposes fix several open bugs with our DDE integration.
• WinCE app update has been working consistently for over a week now. Yay!
• The firefox.exe encountered a serious error crash after an update seems to have disappeared though I’ve asked QA to continue keeping an eye on it and to let me know if they crash on Firefox launch after an update. I have seen this same error when launching Firefox on WinCE without an update on two systems so I don’t think this is an app update bug. It was not possible to debug since in both of these cases the OS froze as well.
• Talked with Vlad and decided that we shouldn’t bother hacking around the incorrect ellipsis provided by the MS Shell Dlg font on WinCE – Bug 512819 [Toolkit:Application Update] – Unicode ellipsis is not properly displayed in the updater dialog when using the MS Shell Dlg font

Next targets (there is more here than will likely be accomplished in a week):

• Bug 496207 [Firefox:Installer] – Workaround zombie firefox.exe process during install
• Bug 512651 [Toolkit:Application Update] (partially fixed by Bug 512994) – lessen the deletions / recreations of the updates and updates/0 directories during startup
• Bug 507719 [Toolkit] – [Exception... "update.locale file doesn't exist in either the XCurProcD or GreD directories"
• Bug 315278 [Toolkit:Application Update] – Update process produces a broken application when disk space is low
• Bug 504911 [Toolkit:Application Update] – Failed partial doesn’t show ui for complete update for Firefox 3.0/3.5 partner builds from Yandex
• Bug 407875 [Toolkit:Application Update] – Unprivileged users are not notified of security updates

and gave me more time to spend with my pony

As mentioned on the Blog of Metrics we changed the installer in Bug 404541 so we always provide a suggested installation directory. When I implemented the ability to install as a non-admin user I wanted the user to decide where to install Firefox since locations outside of Program Files are suboptimal. I justified this in part by saying to myself that it was a small percentage of users and forgot / ignored what I often say myself… “a small percentage of our user base doesn’t mean it isn’t a large number of users”.

Also mentioned on the Blog of Metrics are a couple of more changes coming to the installer. After Bug 508684 lands we are going to ask if Firefox should be made the default browser on the Summary page since many people missed it on the Setup Type page. This will hopefully also land for Firefox 3.5.4 or 3.5.5 and for Firefox 3.6 we will also change the install button’s text to “Upgrade” when installing on top of an existing install which was another thing the install survey pointed out was confusing to users.

We are also going to workaround zombie firefox.exe processes in Bug 496207 by only prompting to close Firefox once and if it is still present during the installation require an OS reboot to complete the install by replacing the files that were in use. This is once again one of those instances where I believe it affects a very small percentage of users but affects a large number of users. The details as to why we can’t just kill the firefox.exe process, etc. are in Bug 496207.

I have to say that I am thrilled with the data provided by the install survey and wish similar data gathering techniques could be used throughout Firefox. Thanks go out to all involved and especially to Ken Kovash. My pony also thanks you.