• Landed on trunk – Bug 552602 [Core] – “Open Containing Folder” button on “about:support(Troubleshooting Information)” page does not work. [Windows XP]. This is fallout from Bug 548426 [Core] – xpcom/tests/TestFile.exe fails for windows mobile [Windows Mobile 6 Professional]
• Landed on trunk – Bug 551283 [Toolkit] – Suspicious and possibly unused code in updates.js updateListener.onProgress [All].
• Landed on trunk – Bug 548061 [Toolkit] – Billboard should handle 404 (other errors?) for billboard better [All].
• Landed on trunk – Bug 545707 [Toolkit] – Software update reports transfer speed in bytes per second [Windows Server 2003.]
• Landed on trunk – Bug 549969 [Toolkit] – Add ability to save xml attributes from update xml that app update doesn’t care about [All].
• Received feedback review for patch in progress – Bug 538331 [Firefox] – On update perform action based upon the update metadata [All].
• Started mega-review – Bug 553169 [Toolkit] – Initial review of API rewrite [All].

Future targets:

• Finish patches for Bug 538331 [Firefox] – On update perform action based upon the update metadata [All]. The only part that might be difficult at this stage will be the tests.
• Finish reviews for Bug 553169 [Toolkit] – Initial review of API rewrite [All].
• Start work to add a survey for when an update is declined.

Even with these efforts the billboard size would be different than expected if the user changed their system to use non-default fonts. To lessen the work required to create the billboard and prevent the user interface from not being wide enough on some locales, the dimensions of the Application Update user interface is no longer localized and the dimensions of the billboard is the same for all locales and platforms. Another long standing request for the billboard that is now fixed is to extend the billboard to fit the available space. These changes landed on trunk on 3/11 in Bug 480178 [Toolkit] – Billboard should extend to available space and the update UI should be the same width for all locales [All] and the changes will likely be backported to mozilla-1.9.2 (e.g. Firefox 3.6.x) and mozilla-1.9.1 (e.g. Firefox 3.5.x) though the specific version where these changes will be backported to has not been decided yet.


The before / after comparison of the button strip for the ka locale below shows how the user interface can easily be too narrow and how the new width solves this problem.




Besides the changes described previously the appearance of the buttons on Mac OS X have also been changed and in my opinion greatly improved (thanks go out to Alex Faaborg for this). There are also user interface screenshots on Windows, Mac OS X, and Linux available in Bug 480178.





I haven’t finished the wiki page for these changes yet so I have included a brief summary below… I’ll include a link to the wiki in a future blog post after I have finished the pages:

• The size of the billboard is 700px for the width and 360px for the height for all locales and platforms. The actual width on Windows and Linux ends up being 701px and iirc Mac OS X ends up having a width of 701px and a height of 361px. XUL often adds an extra pixel when specifying the width or height for a child element and allowing the rest of the UI to auto size. So, going with a 700px width by 360px height billboard will be safe.
• The existing method of testing using the app.update.url.override preference can still be used but it now requires new attributes. There is a sample of the update xml available in Bug 480178 in attachment 430898. I’ll blog about the new attributes in the near future as well as update the wiki page for the update xml.
• There is a new method for testing the billboard (this also displays the three possible buttons for this page) by adding a new string preference named app.update.billboard.test_url with a value of the path to the billboard’s html. The path when testing using this method supports file:// urls as well as http(s):// urls. Clicking any of the buttons when testing with this method will close the user interface instead of carrying out their normal action.
• By specifying an attribute named zoomOutToFit on the body of the billboard it will zoom out to fit using full zoom for the width (zoomOutToFit=”width”), the height (zoomOutToFit=”height”), or both the width and height (zoomOutToFit=”both”) when the billboard html extends beyond the available space. In the css for the billboard, overflow should be set to hidden when using this method since even with zooming out the billboard may still display scroll bars. This will decrease the size of images, hence it isn’t recommended… though it might come in handy for locales where the text requires more space. If you use this method you should also test it with the billboard html you are using it with to verify that it works as you are expecting.

In the near future I will also be fixing Bug 548061 [Toolkit] – Billboard should handle 404 (other errors?) for billboard better [All]. This will require an attribute on the billboard’s html body so that Application Update can verify that the page wasn’t redirected as can be the case when using a hotel’s wifi, etc.


I also filed Bug 548764 [Toolkit] – The non-billboard pages need UI redesign [All] to improve the remainder of the Application Update user interface pages.


Thanks goes out to Alex Faaborg for the user interface design / guidance and to Dave Townsend for the quick turnaround on the review so the changes could land in time for the next Developer Preview release.

• Landed on trunk – Bug 530872 [Toolkit] – app.update.url params / update.xml cleanup and addition of a custom string property for apps [All]. This is the main patch for adding support for Custom action based on update xml after app update. As a side benefit there are now several mochitest chrome tests for the app update user interface. This will need to be backported without string changes to 3.6 and possibly 3.5.
• Submitted patches for review for Bug 480178 [Toolkit] – Billboard should extend to available space and the update UI should be the same width for all locales [All]. This will need to be backported without string changes to 3.5.
• Started working on Bug 548061 [Toolkit] – Billboard should handle 404 (other errors?) for billboard better [All].

Future targets:

• Fix a new requirement for Custom action based on update xml after app update – Bug 549969 [Toolkit] – Add ability to save xml attributes from update xml that app update doesn’t care about [All]
• Figure out the implementation for Bug 538331 [Firefox] – On update perform action based upon the update metadata [All]. This is the front end patch for adding Custom action based on update xml after app update.
• Land on trunk – Bug 480178 [Toolkit] – Billboard should extend to available space and the update UI should be the same width for all locales [All]. This will need to be backported without string changes to 3.5.

• Waiting on remaining reviews for Bug 530872 [Toolkit] – app.update.url params / update.xml cleanup and addition of a custom string property for apps [All].
• Started looking at the implementation in the patch for Bug 538331 [Firefox] – On update perform action based upon the update metadata [All]. Should have the implementation figured out next week.
• Started working on and have received ui-review on Bug 480178 [Toolkit] – Billboard should extend to available space and the update UI should be the same width for all locales [All].
• Started on a patch for Bug 548061 [Toolkit] – Billboard should handle 404 (other errors?) for billboard better [All]

Future targets:

• Get reviews for and land Bug 530872 [Toolkit] – app.update.url params / update.xml cleanup and addition of a custom string property for apps [All]
• Figure out the implementation for Bug 538331 [Firefox] – On update perform action based upon the update metadata [All].
• Finish the patch for Bug 480178 [Toolkit] – Billboard should extend to available space and the update UI should be the same width for all locales [All].

Progress:

• Client side patches reviewed but still need to finish tests for Bug 530872 [Toolkit] – app.update.url params / update.xml cleanup and addition of a custom string property for apps [All]. The xpcshell tests are finished but the mochitest chrome tests have shown there are leaks in the client code (it also asserts in debug builds) due to the work done to support remote html which was done for Firefox 3.0. As soon as I fix the leaks and assertions the tests should be done. This is taking much longer than I like but tests are important and it is very important to not add new oranges to the tinderbox.
• ddahl has started work again on Bug 538331 [Firefox] – On update perform action based upon the update metadata [All] as well as general cleanup of overridden attributes in the update xml.
• Reviewed code / provided guidance for Bug 523410 [Core] – Disable LSPs in WinSock for Firefox [Windows.]

Future targets:

• Finish up the tests for and land Bug 530872 [Toolkit] – app.update.url params / update.xml cleanup and addition of a custom string property for apps [All]
• Write mochitests for Bug 538533 [Toolkit] – If a complete update fails the update prompt should state the error and offer a link to download the update [All].
• Finish up Bug 538331 [Firefox] – On update perform action based upon the update metadata [All].

• Patch almost ready for review – Bug 530872 [Toolkit] – app.update.url params / update.xml cleanup and addition of a custom string property for apps [All]. The changes are backward and forward compatible which should minimize releng’s pain when implementing this on AUS. This is the app update work to support Bug 538331 [Firefox] – On update perform action based upon the update meta-data [All] as well as general cleanup of overridden attributes in the update xml.
• Landed Bug 536547 [Toolkit] – 3.5.6 is downloading the same version for an update [Windows]. This prevents resuming the download for an update with the same app version with the same build id.
• Landed Bug 540356 [Toolkit] – Enforce a sane minimum interval for app.update.timer [All]. There have been several bugs filed over the years due to using extremely low values for this timer along with the app update timer interval during release testing and this is the first of a couple of fixes to prevent this from happening in the future.
• Landed Bug 543312 [Toolkit] – Remove the dependency on nsTryToClose.js from app update’s ui [All].
• Landed Bug 538533 [Toolkit] – If a complete update fails the update prompt should state the error and offer a link to download the update [All]. This has caused several bug reports over the years during release testing.
• Met with Ken Kovash to define new app update metrics for Firefox Lorentz.
• Rewrote Software Update:Manually Installing a MAR file.

Future targets:

• Land Bug 530872 [Toolkit] – app.update.url params / update.xml cleanup and addition of a custom string property for apps [All] and ddahl should have Bug 538331 [Firefox] – On update perform action based upon the update meta-data [All] landed as well. The remainder of the work to enable this will be done on AUS and I’ll get an ETA for this from nthomas during the week.

• Write mochitests for Bug 538533 [Toolkit] – If a complete update fails the update prompt should state the error and offer a link to download the update [All]
• Start coding for the new app update metrics for Firefox Lorentz

• Tracked down the cause of the following crashkill bug – Bug 501429 [Core] – Gmail tab crash while closing it’s tab [@ UserCallWinProcCheckWow ] (caused by Google Talk Plugin) [Windows XP]. This was a PITA due to it being in Firefox 3.0 cycle and there being no nightly builds for the range.
• Met with metrics to go over their requirements for Firefox.next.
• Received r+ on Bug 538533 [Toolkit] – If a complete update fails the update prompt should state the error and offer a link to download the update [All]. This is actually an old bug that causes QA to file bugs against app update during almost every release cycle.
• Performed over 5% of the Firefox 3.6 RC1 Full Functional Tests including all of the Windows 7 Multitouch Full Functional Tests.

Future targets:

• Get back on track with the Quarter 1 app update work.

• Dealt with a few items in my review queue.
• Patch ready for review – Bug 538533 [Toolkit] – If a complete update fails the update prompt should state the error and offer a link to download the update [All].
• Discussed with ddahl the after update action work he will be doing for Firefox.next and filed Bug 538331 [Firefox] – On update perform action based upon the update metadata [All] for this work.
• Profiled startup on Firefox WinCE with and without 325 named anonymous functions which showed there is no longer a cost for naming anonymous functions. I discussed this with Brendan and he confirmed that his upvar2 work removed the additional cost associated with naming anonymous functions.

Future targets:

• Land Bug 538533 [Toolkit] – If a complete update fails the update prompt should state the error and offer a link to download the update [All]
• Write mochitests for Bug 538533 [Toolkit] – If a complete update fails the update prompt should state the error and offer a link to download the update [All]
• Add backend suppport for Bug 538331 [Firefox] – On update perform action based upon the update metadata [All]

 
 
Totals for each component using their averages from the previous table.

Samples: 50

 
 
One thing that stands out is that fuelApplication.js appears to be paying a penalty for being the first JavaScript component to load. To verify this I made nsSessionStartup.js load first, fuelApplication.js load second, and analyzed the new data. The results showed that the load first penalty is ≈ 558ms for JS_Execute and ≈ 10ms for the first CallHook.

Totals for each component using their averages with nsSessionStartup.js loading first and fuelApplication.js loading second (complete table not shown).

Samples: 50

 
 
There are a couple of things that can be done to the nsExtensionManager.js component that I’ll write about later. Besides optimizing a couple of these components I think that the fuelApplication.js component should either be re-written as a JavaScript module or be removed entirely. With its removal from the startup path startup time is reduced by ≈ 140ms on WinCE Firefox trunk with a Tegra device as can be seen below. I suspect that this would also reduce startup on a few of the Firefox desktop platforms by ≈ 1%.

Filed: Bug 536504 [Firefox] – Remove fuelApplications.js from the startup path [All]

Samples: 30

 
 
Totals for each component using their averages without fuelApplication.js from the previous table.

Samples: 30

 
 
The profile logs used for this analysis include additional details including call stacks and are available for download…
profile logs

• Landed on 1.9.0 for Firefox 3.0.18, 1.9.0 GECKO190_20091130_RELBRANCH for Firefox 3.0.17, 1.9.1 for Firefox 3.5.8, 1.9.1 GECKO1916_20091130_RELBRANCH for Firefox 3.5.7, 1.9.2 for Firefox 3.6, and trunk (yes, it is a tad ridiculous listing them all but it was even more ridiculous having to land this six times) – Bug 534090 [Toolkit] – do not use background notification for major updates (was PMU 3.0->3.5 major update has been really poor) [All].
• Performed a bunch of startup JavaScript component profiling and I’ll blog about my findings after I have correlated the data.
• Edited to add – Landed on trunk – Bug 529942 [Toolkit] – Remove nsIApplicationUpdateService2 on trunk [All]

Future targets:

• Define app update work for Q1 2010.