my evil eye

May 11th, 2011 by rstrong

I got a chalazion about a month and a half ago which has repeatedly gotten better and then worse. They look fairly innocuous but they can leak infection into the eye and in my case it feels like acid. I have an appointment to get it fixed tomorrow during which I get to wear one of those fashionable eye clamps from a clockwork orange. I’m just glad I finally found a doctor that will take care of it instead of repeating, “it will get better”.

eye clamp


Ownership

April 29th, 2011 by rstrong

For around 6 years back in the late 80′s through the early 90′s I managed (my first stint as a manager) a telecom and datacom department for a site with 10 buildings and at its maximum 1500 employees. One of my pet peeves was not having a UPS for the telecom system since if there was ever a power outage people in buildings that didn’t have a security presence would be cutoff from the world. Every year I would present to corporate a request for a UPS and every year they would turn it down. About a year and a half before I quit I included a document that included the fact that if an earthquake happened (think Loma Prieta earthquake around that same time period) that caused a power outage then the people in the buildings without security would not be able to contact security much less any emergency services they might need. For example, we had highly corrosive acid in some of the buildings. I also stated that as a lowly manager there was no way I could take on the responsibility for this decision along with the ramifications noted in the document and included a place to sign the document for the corporate officers to acknowledge that they received and have read this document (I was friends with the company lawyer). I quit a short time later for greener pastures but still had friends at the company that informed me that they finally approved the UPS and they took credit for doing the “right thing”.

*edit* should have mentioned that this was before the proliferation of people having cell phones. As a matter of fact, I had one of those old “ammo case” portable cell phones.

It isn’t important to be given credit for doing the “right thing”… it is important to get the “right thing” done.


Application Update File Fragmentation (update)

April 20th, 2011 by rstrong

Back on December 4th, 2010 I blogged about Application Update file fragmentation and the new lack thereof and wanted to write a quick update after checking both my Mac and Windows systems.

On my Mac, using hfsdebug (download is no longer available), there were 199 files fragmented ranging from 5 fragments to 874 fragments with most of the files being in my local hg repos. The cool thing is that not a single Firefox application file was fragmented.

On my Windows system that I disabled the OS provided defragmentation application about a half a year ago, using Contig, I just checked the Firefox application files of which there were 4 fragmented files ranging from 2 to 4 fragments (shown below). The two dll’s are the only ones to be concerned about and they are by no means badly fragmented.

\D3DCompiler_42.dll is in 4 fragments
\d3dx9_42.dll is in 4 fragments
\removed-files is in 2 fragments
\{972ce4c6-7e08-4474-a285-3208198ce6fd}\preview.png is in 2 fragments

The 4 files have fragments because they were added and have never been patched. I hope to come up with a solution so they aren’t fragmented in Bug 616390 though I am not planning on working on that anytime soon.

Now I can turn back on automatic defragmentation back on my Windows system.


Why data is good and how it helped me deal with Firefox Frankenbuilds

April 14th, 2011 by rstrong

The updater has always had a problem on Windows (likely other platforms as well) where an update doesn’t update all of the files. The latest occurrence of this is on the Firefox 3.6 branch in Bug 639542 – Crash [@ js_DeepBail(JSContext*) ] at address 0×204 due to frankenbuild. Anurag Phadke was able to get data out of http://crash-stats.mozilla.com/ that allowed us to evaluate how bad the problem was and from that analysis I filed bug 635161 to change the updater’s behavior and bug 635834 to get more data so it is possible to evaluate where we are now and so it is possible to evaluate the impact, if any, of bug 635161 after it has made it to an official release.

Below is a simple analysis from the data… long story short, with Firefox 3.5 approximately 8% of crashes contained mismatched dll’s, Firefox 3.6 approximately 0.25% of crashes contained mismatched dll’s, and Firefox 4.0 (includes nightly) approximately 0.04% of crashes contained mismatched dll’s. If the Firefox 4 data is restricted to just the last month the percentage drops down to approximately 0.02% of crashes contained mismatched dll’s. This is by no means declaring success… we definitely can do better.

Total crashes processed : 31761889

Firefox 3.5 Mismatched File Version Report
20101204 through 20110411

Summary
=============================
    Lines processed : 1711982
  Crashes processed : 1721575
      Lines skipped :     361
   Total mismatches :  137788
 Percent mismatches :   8.00%

Skipped Line Breakdown
===============================
 Invalid firefox.exe name : 309
     Missing version info :  52

Mismatched Versions
==============================================================================+
                        |      Total       | DLLVer < FFVer  | DLLVer > FFVer |
                        +------------------+-----------------+----------------+
       Total mismatches : 137788 (100.00%) | 135850 (98.59%) |  1938 (1.41%)  |
 browserdirprovider.dll :  13507   (9.80%) |  11575  (8.40%) |  1932 (1.40%)  |
           brwsrcmp.dll :   6087   (4.42%) |   4894  (3.55%) |  1193 (0.87%)  |
              xpcom.dll : 101843  (73.91%) | 101810 (73.89%) |    33 (0.02%)  |
                xul.dll : 135854  (98.60%) | 135823 (98.57%) |    31 (0.02%)  |
                        +------------------+-----------------+----------------+


Firefox 3.6 Mismatched File Version Report
20101204 through 20110411

Summary
==============================
    Lines processed : 20277061
  Crashes processed : 20278718
      Lines skipped :     3797
   Total mismatches :    49995
 Percent mismatches :    0.25%

Skipped Line Breakdown
================================
      Invalid line format :   34
 Invalid firefox.exe name : 2907
     Missing version info :  857

Mismatched Versions
==============================================================================+
                        |      Total       | DLLVer < FFVer  | DLLVer > FFVer |
                        +------------------+-----------------+----------------+
       Total mismatches :  49995 (100.00%) |   1039 (2.08%)  | 48956 (97.92%) |
 browserdirprovider.dll :  48685  (97.38%) |    370 (0.74%)  | 48315 (96.64%) |
           brwsrcmp.dll :  48465  (96.94%) |    351 (0.70%)  | 48114 (96.24%) |
              xpcom.dll :  16297  (32.60%) |    426 (0.85%)  | 15871 (31.75%) |
                xul.dll :   7903  (15.81%) |    877 (1.75%)  |  7026 (14.05%) |
                        +------------------+-----------------+----------------+


Firefox 4.0 Mismatched File Version Report
20101111 through 20110411

Summary
=============================
    Lines processed : 9750994
  Crashes processed : 9761596
      Lines skipped :     954
   Total mismatches :    3679
 Percent mismatches :   0.04%

Skipped Line Breakdown
===============================
      Invalid line format :  46
 Invalid firefox.exe name : 246
     Missing version info : 664

Mismatched Versions
==============================================================================+
                        |      Total       | DLLVer < FFVer  | DLLVer > FFVer |
                        +------------------+-----------------+----------------+
       Total mismatches :  3679 (100.00%)  |    95 (2.58%)   |  3584 (97.42%) |
       browsercomps.dll :  3501  (95.16%)  |    82 (2.23%)   |  3419 (92.93%) |
           mozalloc.dll :  2110  (57.35%)  |    77 (2.09%)   |  2033 (55.26%) |
              xpcom.dll :  2067  (56.18%)  |    75 (2.04%)   |  1992 (54.15%) |
                xul.dll :  2531  (68.80%)  |    77 (2.09%)   |  2454 (66.70%) |
                        +------------------+-----------------+----------------+

regarding new nightly name…

April 14th, 2011 by rstrong

I’ve always been kinda partial to “meanwhile,_little_orphan_annie_is_sitting_in_a_hole_by_the_roadside”


Firefox auto-pinned to the Win7 task bar

February 9th, 2011 by rstrong

Short version: Firefox will pin itself to the Win7 task bar when setting Firefox as the default browser.

A couple of weeks ago I blogged about Firefox pinned taskbar shortcuts on Win7 and this week I landed Bug 621873 [Firefox] – “Pin to taskbar when setting as default browser on Windows 7″ for Firefox (Thunderbird, SeaMonkey, etc. are also able to implement this functionality if they choose to). With Firefox 4 when setting Firefox as the default browser from within Firefox (this won’t work with the Win7 “Set your default programs”) it will also pin itself to the Win7 Task Bar.

Since there are already users of Firefox on Win7 it will also be pinned to the task bar after an application update to Firefox 4 or when performing a pave over install with Firefox 4 if Firefox is already the default browser. This will only happen once per installation to prevent re-pinning Firefox to the Win7 task bar if it is later removed.

I’m not terribly happy about having to implement this since it really should be done automatically for the default browser and mail clients by the Windows shell. As a matter of fact, the default browser and mail clients were added to the top left of the start menu for years in versions of Windows prior to Win7 (iirc Win2K SP3 thru WinVista). It kind of pisses me off that it was considered important enough to have a browser front and center pinned to the task bar on Win7 but it wasn’t considered important enough to do this for the browser that the users of Win7 have explicitly chosen to use.


Firefox pinned taskbar shortcuts on Win7

January 21st, 2011 by rstrong

There is no official way to pin shortcuts programmatically to the Win7 taskbar and I completely understand why this ability wasn’t added. The issue I have with this is prior to Win7 Windows added the default browser to the start menu and with Win7 the only browser that is displayed in a prominent place by default is IE. So, at one time it was recognized that applications that are used often by most users should have a prominent place in the ui and now that no longer happens except for the OS manufacturer’s browser whether it is the default browser or not. Also, I know several Firefox users that haven’t pinned Firefox to the taskbar, use Firefox exclusively, and still have IE pinned to their taskbar… sure, I fix this for them but that isn’t a scalable solution. As far as I am concerned, the ability for the default browser and default mail client to automatically be pinned to the taskbar should have been added to Win7.

There are a couple of hacky ways to pin Firefox to the task bar and I will likely add this as an option to the installer after Firefox 4 has been released for the reasons stated above.

Follow along in:
Bug 621873 [Firefox] – Replace “Shortcut in Quick Launch bar” by “Pin to taskbar” when installing on Windows 7 [Windows 7]


Windows safe mode and shortcut changes for Firefox 4.0 Beta 10

January 21st, 2011 by rstrong

As of Firefox 4.0 Beta 10 you can hold down the shift key while launching Firefox on Windows to start in safe mode. Also, the Windows shortcut to launch Firefox in safe mode and the start menu directory have been removed. For those wondering why these changes have been made, Alex Faaborg provides several good reasons to remove the safe mode shortcut in Bug 542122 comment 1. Now that there is only one Firefox shortcut in the start menu we decided to remove the directory and instead have a single shortcut for Firefox in the root of the start menu programs directory. Regretfully, there was a bug in the patch that caused the new shortcut to not be created automatically on update for nightly users (Bug 627848) which has been fixed for Firefox Beta 10. The simplest way to fix this with a nightly build is to just reinstall the latest nightly.

Bugs associated with these changes:
Bug 542122 [Firefox] – Add menu command to restart in safe mode [Windows]
Bug 602562 [Toolkit] – Add keyboard modifier to start in safe mode for windows [Windows]
Bug 598779 [Firefox] – Remove start menu directory and safe mode shortcut creation [Windows]
Bug 627848 [Firefox] – Start menu shortcut isn’t migrated as implemented in bug 598779 [Windows]


App Update / Win Installer status – 2010-12-17

December 17th, 2010 by rstrong

Mainly worked on backporting / landing mozilla-1.9.2 fixes and tests over the last couple of weeks. The combined size of all the 1.9.2 patches I landed on Tuesday were 433 KB and I still have 146 KB of patches for 1.9.2 waiting on review.

Progress:


  • Landed on mozilla-1.9.2 for Firefox 3.6.14 – Bug 601518 [Toolkit] – Need updater tests to cover nsUpdateDriver.cpp code [All]. Since changes have to be made to the updater’s Mac relaunch code in Bug 600362 I wanted this backported so there is better coverage on the 1.9.2 branch.
  • Landed on mozilla-1.9.2 for Firefox 3.6.14 – Bug 466778 [Toolkit] – Unable to update when files to be patched are in use on Windows [Windows]. This makes it so we can successfully apply an update when any file is in use except for firefox.exe, thunderbird.exe, seamonkey.exe, and so on. For example, crashreporter.exe was running, plugin-container.exe didn’t exit cleanly, a third party app is using our files, etc. – this is a major improvement for application update and it is now on the 1.9.2 branch! See this post and Bug 466778 for more information.
  • Landed on mozilla-1.9.2 for Firefox 3.6.14 – Bug 570058 [Toolkit] – investigate small writes from MBS_ApplyPatch [All]. This lessens / prevents file fragmentation when patching files with partial patches.
  • Landed on mozilla-1.9.2 for Firefox 3.6.14 – Bug 316890 [Toolkit] – Add more logging to updater and close patch files so they can be deleted [All]. When people upgrade from Firefox 3.6.x to Firefox 4 they do so using the updater from Firefox 3.6.x. and this bug provides more info for troubleshooting problems with the update process.
  • Landed on trunk – Bug 617513 [Toolkit] – Duplicate declaration of doc in updates.xml [All]
  • Landed on trunk – Bug 616765 [Toolkit] – Useless Exists check in nsUpdateDriver.cpp [All]
  • Landed on trunk – Bug 616775 [Toolkit] – Use OpenNSPRFileDesc instead of OpenANSIFileDesc in nsUpdateDriver.cpp [All]
  • Submitted a trunk patch for review – Bug 617512 [Toolkit] – Additional tests for deprecated update xml format [All]
  • Submitted a 1.9.2 patch for review – Bug 480178 [Toolkit] – Billboard should extend to available space and the update UI should be the same width for all locales [All]
  • Submitted a 1.9.2 patch for review – Bug 530872 [Toolkit] – app.update.url params / update.xml cleanup and addition of a custom string property for apps [All]

Future:


  • Finish Bug 619866 [Toolkit] – Shift key for safe mode conflicts with Windows shortcut keys [Windows]… patch is in bug and just need to confirm a couple of things.
  • Finish Bug 598779 [Firefox] – Remove start menu directory and safe mode shortcut creation [Windows]… have a patch started but this is dependent on the previous bug.
  • Continue work on Bug 394984 [Toolkit] – Unable to update on mac if admin user is not the same admin user as the person who installed firefox [Mac OS X]

Application Update file fragmentation and the new lack thereof

December 4th, 2010 by rstrong

Most of this last week I worked on backporting app update tests to 1.9.2 but there was one significant landing (Bug 570058). When updating with a partial update the files created when patching will be allocated before they are written to prevent fragmentation. This is done using platform specific API’s so the files have minimal fragmentation whenever possible.

To verify this with nightly builds, I started off a couple of days ago after defragmenting my hard drive and measured the fragmentation after applying a nightly partial update. The two updates previous to Bug 570058 landing had the following fragmentation for a partial update on Win7.

File Fragments 2 days prior Fragments 1 day prior
xul.dll 43 164
mozjs.dll 0 12
mozsqlite3.dll 9 10
omni.jar 9 6
browsercomps.dll 0 4
mozalloc.dll 2 2
plc4.dll 2 2
plugin-container.exe 2 2

With the first update that included the patch from Bug 570058 (the nightly update to the 12/4 build) all of the files listed above were contiguous (e.g. no fragments)… can’t get better than that! There was one new file (libGLESv2.dll 668 KB) that was added (e.g. not patched like the above files) that was in 2 fragments. The next time this file is patched it will likely be contiguous as well. Other new files were contiguous (libEGL.dll 136 KB and the usual .chk files).

I filed Bug 616390 to evaluate whether the cost / reward ratio is worth doing something similar for complete updates / files that are added which is a much smaller issue.

Thanks go out to Taras for pushing to get this done and his work in Bug 592520 [Core] – Do not fragment the hell out of CACHE__00[1-3]__ [Linux] which I used for the Mac and Linux implementations.

*Edit* I verified that libGLESv2.dll was made contiguous on the next partial update.


Next Page »