[don't know where to throw this one, so sticking it in ui for now-pls reassign] Build ID: 2000050208 IE 5.x's "Text Size" submenu is much, much nicer than Mozilla's in it that it allows easy access to the size you want. Want really large? Just click "Largest". Looking for pretty small? Hit "Smaller" However, in Moz, you must continuously hit "Enlarge Text Size" or "Reduce Text Size" until you finally get what you said. This is a real pain if, say, you need to make the text extremely large for some reason (which in itself takes a continuous clicking effort), but then you want to make it small. If it took 10 annoying clicks to get it to the size you want, it also takes 10 to get back to the original size...argh. Carrying out such a task with the current system is made even harder by the fact that Enlarge/Reduce text size [currently] have no accelerator/key combo, so you must visit the cute little View menu *every single time*. Furthermore, such a system like IE's (with a "Text Size" submenu containing various size options) would allow for some kind of limit on how large/small text can be. Unless you don't want a limit? Right now, it seems text can be made as large (slowing things down) or as small as you want...if this is intended, I can also envision some type of "Other..." menu item on the proposed "Text Size" submenu which would allow the user to enter a size that they desired, or perhaps a percentage of the original [normal] font (i.e. "250%") Let me know what you think.

So we have several suggestions here. * The menus should offer a finite set of text sizes to choose from, to save repetitive incremental sizing. * `Reduce Text' and `Enlarge Text' should have keyboard shortcuts and/or toolbar buttons (this would reduce a lot, but not all, of the need for a menu of predetermined sizes). * There should be a `Zoom to Level ...' item. Seems like an appropriate time to drag out the Aphrodite menu spec again <http://critique.net.nz/project/mozilla/general/interface/menus/menus.txt>: | | View > Zoom submenu | ------------------- | / _Original Size Ctrl+0 | ---------------------------------- | Zoom _In Ctrl++ | Zoom _Out Ctrl+- | _Zoom to Level ... Ctrl+Shift+Z | ---------------------------------- | _Enlarge Text Ctrl+Shift++ | Sh_rink Text Ctrl+Shift+- Note that this assumes the eventual existence of a global zoom, which is independent of text zoom.

I like this suggestion in general. Targeting M18 so we can investigate further.

I have a fix to create a menu just like IE's. Haven't implemented the "Other..." (or an item of a similar function) option yet.

Matthew: I'm going to group Text Size and Use Stylesheet together because both affect the style of the webpage (and it looks pretty bad having each in its own separate group). Also, what do you think about moving Reload, Show Images, and Stop up, to be above the Text Size and Use Stylesheet groups? Seems to me that people will be accessing those navigation/site related items more than they'll be changing their text size and stylesheet...

Hmm..or maybe not, since right now the top half of the menu seems to deal with UI/style changes ,and the bottom half is more website stuff. Sort of. I dunno, what do you think?

Fix checked in. Should I still try to implement the Other... option?

OK, there's an easier way to do this that will make an "Other..." option easier. So I'll work on that tomorrow. Also, a new bug needs to be filed that the text size menu won't update if you resize the font with the modifier + mousewheel.

I never said I thought this menu was a good idea ... I'm concerned that from the user's point of view, it artificially restricts the range of size options available (given that `Other ...' would be too bothersome for most people to use). That's why the Aphrodite spec has Smaller and Larger (with keyboard shortcuts, and ideally with toolbar buttons too) instead. I don't have a Mozilla build available right now, so if you want me to comment on the layout of the `View' menu in general (probably in a separate bug) I'd need a screenshot. But I agree entirely that `Zoom', `Use Style', and `Encoding' should be in the same section of the `View' menu <http://critique.net.nz/project/mozilla/navigator/main/menus/view/>. The idea of changing text size with the mousewheel at all is under review, see bug 45647.

Someone just suggested to scrap the "Other..." idea in lieu of having the old menu items again, i.e. Text Size > Largest Larger Medium Smaller Smallest -------- Enlarge Text Size Reduce Text Size (or perhaps just "Enlarge" and "Reduce"). So, for example if the user clicked Enlarge while Medium was checked, Larger would then become checked. If the user went past Smallest or Largest, no menu item would be checked (not sure if I like this part of the suggestion, potential for confusion). I think this menu is very important, and a large improvement over the former system. As of now, if you enlarge a lot and then decide to go back to normal size, not only do you have to continuously click the Reduce menu item, but you have to remember what 'normal' size looks like.

I don't think the mechanism itself suggests artificial limits, but I do think the current wording suggests a very finite range. The current wording also gives no clue as to what "normal" text size is. I recommend doing what IE and slew of other products (Acrobat, MS Office, etc.) use to represent increasing or decreasing text/view size: percentages. That way there's an obvious norm (100%), and although there is a range supplied, it's not strictly limited like "largest." In addition to that, it's much easier to translate from percentages to an "Other..." dialog (what exactly would you type in? "bigger than largest, please") OR an enlarge/reduce command pair (or both if we want to go overboard).

OK, I can change it to percentages easy enough. Should it still be View | Text Size > ? Or View | Zoom > ? We could also do something like Largest (XX%), Larger (XY%), etc. If you want...

We can also do a wider range of menu itemes with percentages, if you wish. What percentages do you suggest have menu items?

It should stay View | Text Size > since the page itself is not being scaled. View | Zoom > implies that images and everything else will scale as well. I also don't recommend Largest (xx%) since that bears the same implied limits that Largest does on its own. As far as what percentages are listed, I would recommend a small range of useful, usable options. It does not have to cover the entire range of percentages available since it is unlikely that users will regularly want to scale to, say, 1000% text size. For example: Text Size > 200% 150% 125% 100% 75% 50% --------- Enlarge Reduce Also, this may be stating the obvious, but it's important that the text size is actually calculated as a percentage and that if the current magnification matches one of the percentages listed in the menu, that item be checked to show the current zoom.

OK, I'll try to get the changes in today. So we're going with Enlarge and Reduce, rather than Other... ? Agreed, I like that better. I still need to work with bryner on getting the menu checkmark to update if the user changes the font size via mousewheel. Matthew, do you agree with everything being said here? And those percentages that Brendan mentioned?

* The menu name: `Text Si_ze', with `Z' as the mnemonic. In the future, we should have the ability to scale pixel objects (e.g. graphics) as well. (There would be a scaling threshold, to allow us to make the text smaller or larger to a certain degree while leaving graphics at their original size, so they don't get scaled slightly and therefore unattractively when we scale the text.) Once that happens, this menu will become `_Zoom'. So having `Z' as the mnemonic now will be forwards-compatible. :-) * We should use Larger and Smaller, not Enlarge and Reduce, for the same reason I gave in bug 45491: UI grammar. We're manipulating (verb) something (noun) in some way (adverb). We're Viewing (verb) the Text (noun) Smaller or Larger (comparative degree of adverb). (We say `Text Size', not just `Text', for clarity purposes; this disturbs the grammar a little, but not as much as using Enlarge and Reduce (verb) would.) * The percentages used shouldn't just be geometrically based on 100%, but harmonically based so that they produce decent-looking pixel sizes when multiplied by the usual default size. Also, it's not certain that you want to scale all text sizes by the same percentage: if a page has most text rendered at 24 px, and some text at 12 px, you'll probably want to scale down the 24-px text more than you want to scale the 12-px text. So using fixed percentages at all might not be such a hot idea ... But that's a problem for another day. * You need some way of making the 100 % item more obvious than the other items (something in which the magnification menus in most apps usually fail spectacularly). Putting `(Original size)' next to it would fulfil this purpose nicely. So ... Text Si_ze ---------- S_maller Ctrl++ _Larger Ctrl+- -------------------------------- 5_0 % _75 % _83 % [actually 83.333333333 %] * 100 % (Original si_ze) [using the `z' again makes this easy to select] 1_17 % [actually 116.666666666 %] 1_25 % 1_50 % _Other (200 %) ... [menu item shows last-chosen custom scale, and this is the default value in the dialog]

Argh, kveck. Corrections: * The title of the menu should not be just `Text Si_ze', but `Text Si_ze (100 %)' (or whatever the current zoom level is). This means I can see the current zoom level just by dropping down the `View' menu, without having to fish into the submenu. * I had the keyboard shortcuts the wrong way around. Use Ctrl+- for `Smaller', and Ctrl++ for `Larger'.

*** Bug 47462 has been marked as a duplicate of this bug. ***

How is this one coming along?

I like the overall scheme that Matthew is advocating (because it's a system, not just a heap of features!), with the minor exception of the "funny looking" scaling intervals suggested. These derive from a rather old article I wrote. I had my reasons, but in the meantime, I became involved in the IE for Mac beta program, where similar functionality has been implemented with lots of feedback from me, and a different set of intervals has been used. I think Mozilla should use these: 300% 200% 150% 120% 100% 90% 75% 60% This scale works better than my initially proposed one in practice (try it in MacIE) and is derived from the intervals used to regulate the absolute font-size keywords (and HTML 1-7) when the "medium/3" value is sufficiently large. They are all fairly simple whole-number ratios, too (90% is actually 89%, from 8/9), so they fit the "harmonic intervals" criterion. MacIE5 has also a 50% setting, whose main use is in copyfitting for print purposes; it's almost certainly useless on screen. A way to improve upon MacIE in this regard: have an "other..." option that allows one to specify an arbitrary scaling factor. Also note that in MacIE5, the scope of the scaling is the frontmost window/frameset. Everything always reverts to 100% as soon as that window closes. Zoom is no substitute for setting a preferred font size in prefs; but a quick override.

I like the overall scheme that Matthew is advocating (because it's a system, not just a heap of features!), with the minor exception of the "funny looking" scaling intervals suggested. These derive from a rather old article I wrote. I had my reasons, but in the meantime, I became involved in the IE for Mac beta program, where similar functionality has been implemented with lots of feedback from me, and a different set of intervals has been used. I think Mozilla should use these: 300% 200% 150% 120% 100% 90% 75% 60% This scale works better than my initially proposed one in practice (try it in MacIE) and is derived from the intervals used to regulate the absolute font-size keywords (and HTML 1-7) when the "medium/3" value is sufficiently large. They are all fairly simple whole-number ratios, too (90% is actually 89%, from 8/9), so they fit the "harmonic intervals" criterion. MacIE5 has also a 50% setting, whose main use is in copyfitting for print purposes; it's almost certainly useless on screen. A way to improve upon MacIE in this regard: have an "other..." option that allows one to specify an arbitrary scaling factor. Also note that in MacIE5, the scope of the scaling is the frontmost window/frameset. Everything always reverts to 100% as soon as that window closes. Zoom is no substitute for setting a preferred font size in prefs; but a quick override.

I still think we should go from 50 % to 200 %. The 50 % situation is scaling down some GeoCities site where the author has decided, for reasons best known to themselves, to put <h1>the entire page contents in a heading</h1>. And the 200 % situation is for someone with vision difficulties who wants to turn 8 px on some Microsoft site into 16 px.

The newly suggested scaling seems better to me because it miminizes the thinking involved in picking a zoom factor, thereby allowing for an overall better user experience. A user can easily pick a zoom factor on impulse. Also, the range is sufficiently wide-spread to cater for diverse situations, including the particular cases raised by mpt.

As noted in bug 45647, we need keybindings here for enlarging and reducing the text size. Once that is done, the mousewheel shortcut can pretty much go away. Marking dependency.

Blake, Peter Anemma (`jag') has been implementing this. Sorry I don't know his e-mail address, could you CC (or reassign to) him? Ok, the objective is to find a set of zoom levels such that: * they are useful, for the Web pages and monitors of both the present and the future; * they don't confuse the user with too much up-front choice; * they do provide complete user choice, by allowing the user to choose an arbitrary zoom level; * the absolute and relative mechanisms co-exist in a harmonious manner. This last criterion is especially tricky. I see it being achieved like this: there is an infinite scale of steps which the `Smaller' and `Larger' commands step through, and the absolute zoom levels in the menu are just the set of these values which happen to surround 100 % (and which are therefore the most likely to be used for immediate purposes). Now, from my calculations, Todd's suggested series is based on a harmonic scale -- where if n is the signed number of steps from 100%, then z(n) = (-n+6)/(-n+5) * z(n-1). (The exception is that his scale omits 66.67 %.) This series would have the nice property that if extrapolated downwards with the `Smaller' command, it would never crash into 0 %. But it has two not-so-nice properties. First, each consecutive activation of `Smaller' or `Larger' would reduce/enlarge the text by a noticably different percentage amount. And second, it can't be continued (for `Larger' purposes) past 600 %, because you get a division by zero. (Neither of these are a problem in IE for Mac, because AFAIK it doesn't have `Smaller' and `Larger' in the first place.) Instead, I think we should use a geometric series, where z(n) ~= 100% * (3/2)^n. This retains the nice asymptotic property of the harmonic scale, while avoiding both of the harmonic scale's problems given above. I say `~=', and not `=', because we should round the values to reasonably whole numbers as they pass through the absolute values menu, so that the user can understand them (as rbs@maths.uq.edu.au rightly says). 3/2 (== 1.5) is large enough so that I can resize text heavily (by several hundred percent) using `Smaller' or `Larger' without it taking too many key presses. But it is obviously too large an interval to use if we just want to reduce or enlarge not-quite-perfect text by a few pixels, which will be the usual situation. So, for the part of the scale covered by the absolute zoom level menu, as we approach 100 % from both directions, we use different values which smoothly bring the interval between values down to nearly 1/1. Fortunately, we can do this while at the same time using reasonably round numbers in the menu. So the scale used by `Smaller' and `Larger' looks like this: Level Interval ----------------- ... ... 22.2 % 1.5 33.3 % 1.5 50 % 1.5 75 % 1.2 90 % 1.11 100 % 1.2 120 % 1.25 150 % 1.33 200 % 1.5 300 % 1.5 450 % 1.5 675 % ... ... And the part we show in the menu is the part from 50 % to 200 %, like this: Text Si_ze ---------- S_maller Ctrl+- _Larger Ctrl++ -------------------------------- _50 % _75 % _90 % * 100 % (Original si_ze) 12_0 % _150 % _200 % _Other (300 %) ... [menu item shows last-chosen custom level, and this is the default value in the dialog] That leaves one more detail: what happens to `Smaller' and `Larger' when I specify a custom level? Well, I think that whenever the custom level is not part of the series defined above, it should be considered to be its own step in the scale. For example, let's say that the last custom level I specified was 350 %, but I am currently at 120 %. If I repeatedly choose `Larger', I will be zoomed to 150 %, then 200 %, then 300 % (== 200 % * 3/2), *then* 350 % (a detour off the scale to take in the custom level), then 450 % (back to the scale, == 300 % * 3/2), and so on. This prevents the possible situation where I use `Smaller' or `Larger' to step off my custom level, then enter the opposite command only to find that I'm not back at my custom level but at a different level on the 3/2 scale.

mpt writes: "(Neither of these are a problem in IE for Mac, because AFAIK it doesn't have `Smaller' and `Larger' in the first place.)" Sure it does. But it simply takes you to the next value in the fixed scale of intervals. It doesn't apply some tricky scaling factor itself. When you reach the upper or lower extent of the scale, larger/smaller simply ceases to have any effect. This seems to work quite well in practice, since the upper and lower ends of the scale are already quite uselessly dramatic (but it makes good "user is in control" demo fodder). What MacIE5 lacks is a custom zoom level affordance. In this case the semantic of larger/smaller becomes problematic. I suggest snapping to the nearest interval in the fixed scale. So, e.g., if the user picks either a 105% or 119% zoom, and then hits larger, the interval goes to 120%. And if smaller, to 100%. Not terribly sophisticated, but this is an edge case, after all.

> What MacIE5 lacks is a custom zoom level affordance. In this case the semantic > of larger/smaller becomes problematic. I suggest snapping to the nearest > interval in the fixed scale. That's exactly what I suggested above -- with the corollary that you can also snap back into the last-specified custom level, as a diversion during the smaller/larger scale.

OK. got it - sorry I didn't read more carefully. Running late and all...

[Restoring the CCs which Todd deleted.]

Cc:ing Peter ``jag'' Annema <disttsc@bart.nl> Since the current solution sitting in the tree is sub-optimal, it will be nice to see what you have been doing.

Hmmm, mpt just rendered my current code useless ;-) But the infrastructure is there, so writing the new code shouldn't be too hard. I'll do this tomorrow. Btw, 1.2 is good enough a scaling factor, I think 1.5 would scale like insane. But I guess we can finetune all this once my code is done. Assigning this bug to myself.

And accepting.

Note that in the region around 100 % where the user is likely to be scaling, the interval *is* roughly 1.2. But if scaling less than 50 % or more than 200 %, I'm guessing the user will be wanting to move faster than that. One minor clarification: The `last specified custom zoom level' is *not* necessarily the same as the level which the `Other ...' dialog defaults to. If the last specified custom zoom level was 110 %, and I then zoom up to 450 %, when I look in the menu the dialog is going to say `Other (450 %) ...'. But when I use `Smaller' to zoom back down again, 110 % is still going to be a step in the scale, because that was my last specified custom zoom level.

Outside the predefined region is what I was talking about. I wouldn't change ``Other (xx%)''" on zooming in/out using Larger/Smaller, only when selecting Other and changing the number there. The zoom level in ``Text Size (xx%)'' already nicely shows the current zoom level, and changing Other would just be annoying. Thinko? Or am I misunderstanding you here?

> I wouldn't change ``Other (xx%)''" on zooming in/out using Larger/Smaller, only > when selecting Other and changing the number there. But then, if I went Smaller/Larger beyond the range of the menu, I wouldn't be able to find the current zoom level by inspecting the menu ... > The zoom level in ``Text Size (xx%)'' already nicely shows the current zoom > level ... And eventually this submenu is going to have its own toolbar button too (like in IE), and in that case you won't be able to show the current zoom level in the menu title because there won't be a menu title. (I don't think you should show the zoom level in the menu title anyway -- just show it next to `Other'.)

So that's a change to the PS-comment you made "2000-07-31 17:09"?

Yes ... [thinks] ... ah, crap, no. It's getting too confusing. I didn't think through all the details properly. Sorry about that. Um, ok. How about this: * The submenu title is `Text Si_ze (100 %)' (for whatever the current level is). * If the user specified a zoom level using the `Other ...' dialog which is between 50 % and 200 %, that zoom level is remembered (and used as one of the `Smaller'/`Larger' steps) until I go out of the 50~200 % range. That level is shown in the `Other ...' item, which is checked when I go through that step. * If I go out of the 50~200 % range, the last custom level I entered in the dialog is forgotten; the `Other ...' item (and the dialog, if I open it) instead shows the current level (since the current level is not in the rest of the menu). Okay?

Here's something for y'all to look at and have fun with. Sorry it took so long... The .tar.gz contains four files: one diff against most stuff, and three new files which I haven't the slightest how to make ``cvs diff'' put in the diff, so I just tar'ed them. Put the .xul and .js in xpfe/browser/resources/content/ and the .dtd in .../locale/en-US/ and have fun with the .diff (POSIXLY_CORRECT=1 and/or running patch from xpfe/browser/ should help). - ctrl+j/ctrl+k for smaller/larger (ctrl+- and ctrl++ don't seem to work on linux (yet) - Smaller/Larger inside the fixed range takes you from one to the next, or ``Other'' if it happens to be in between. Outside the range, it multiplies with or divides by 1.5. - ``Other'' will show the current zoom factor for any factor which isn't listed in one of the other menu items. - Clicking other will pop up a dialog allowing the user to enter a value N where 1<=N<=5000, the latter to prevent Mozilla from making my X server freeze the computer by taking up all cycles trying to render the default font at 60,000% (I hit reset after 6 hours). I didn't put the current size yet directly after "Text Size" in the View menu, but adding that is trivial if still so desired. Play with it, please give feedback on what you like and what you'd like to see changed, and yes, I know the code is a mess, I'll go clean up later :-) To do: - clean up this code - perhaps split this off into a seperate JS file loaded from the overlay - perhaps (also) turn this into a JS Object with prototypes and stuff

Whoo-hoo! What's the bug no. for + and - not working as shortcuts? I don't think you can leave the shortcuts as Ctrl+J and Ctrl+K, because Ctrl+K is used for `Forward' (remember, this submenu should be in Messenger too).

ctrl+k used as forward? Ewwwww! Did someone file a bug on that yet? And it's "kill to end" on unix/linux in ender, also not very handy... But yes, those will change, to ctrl+- and ctrl++ hopefully :-) Dunno if there's a bug# for that yet though. Now, I don't remember any mention of Messenger, but I can probably hack it in. Move this stuff out into its own js file and xul overlay, put it in global or communicator (any hints on that?) and make Messenger and Navigator both use this.

>I didn't put the current size yet directly after "Text Size" in the View menu, >but adding that is trivial if still so desired. Yes, still helpful. The other glitches I observed are: * Missing '%' on levels * Dump should be more explicit with 'Text Zoom Level: ..." * As you can see on the screenshot, '200' is checked although the current zoom level is back to '100' (I did some maneuverings -- don't know if the order of the selections has something to do with this problem). * Other: a) My system hangs when it is selected. b) Why is '500%' used? Shouldn't this be left empty, and be displayed only after the user has made a selection. c) Somehow, it is not intuitive that 'Other' allows to make custom selections. What about changing the label to look like: [Other... ] (first-time look: when no selection has been made) [XX% Other...] (when the user already has made a selection for 'XX%')

Could you find out for me how you got the menu to show 200% while being at 100%?

I am seeing that it happens when I use the keyboard shortcut 'z' (for Original Si_ze) instead of the mouse.

Yes, I saw comments in another bug that the menu doesn't update when you use the keyboard shortcuts. (Don't just fix that by detecting the keyboard shortcuts: fix it in such a way that it stays fixed no matter what method or UI I use to change the zoom level in the future.) Other bugs, from looking at rbs's screenshot: * The default `Other' value is 500 %, it should be 300 %. * There should be a space between the numbers and the percent symbol. * The ellipsis in `Other (300 %) ...' should be after the brackets, not before them (which is why the item doesn't seem intuitive to rbs at the moment). * Is there a bug on `-' and `+' not working for shortcuts yet? (I'd file it myself, but I don't run Linux and don't know enough of the gory details.)

"I am seeing that it happens when I use the keyboard shortcut 'z' (for Original Si_ze) instead of the mouse." I'm not sure exactly where the error lies. I know how to "fix" it though :-) Thing is, if I assign an accesskey to a menuitem, I expect typing the key to have the same effect as clicking the menuitem, in this case, select it, and set the checkmark accordingly. This doesn't happen. I'll try to find out what's going on here. I've moved all the values and whatnot out into navigator.properties, and I'm building the menu from that, so if so desired, a localizer can put 10 values or 4 values in there.

Whoops, I screwed up with that patch... Let me create another one...

Unlike the first patch, the latest one is not applying smoothly on a clean tree. (I deleted the resources dir, 'rm -r resources', and did a 'cvs upd -d' from within xpfe\browser to start afresh).

Adding keywords

The tree is messy, and I am running into one problem after the other. (When it is not the software, it is my hardware which is playing tricks). I will appreciate if someone is also considering testing and providing feedback to jag.

Fix checked in.

Cleaning up keywords, let's make searching on bugs to review and approve easier.

I saw this fix, but now (2000-09-18-21/Linux) the item has completely disappeard. See bug 53207.

Pinkerton backed this out. I'm not sure why (some problem with Mac menus); I hope it's temporary. Reopening and adding Pinkerton, who can perhaps explain the problem.

akkana: it totally biffed mac menus, so i backed it out until we figured out why. saari has a fix, but from what I hear, this functionality doesn't work on mac for other reasons (other bugs filed, i think). we probably can't leave this in if the submenu is totally ineffective on mac, but i don't know the issues. that would be for jag/brendan/marketing to deal with, not me.

That's bug 52969.

Cc:ing saari

rbs: did you get a message about mid-air collision? Putting back "depends on" 53207

No, I didn't get a mid-air collision.

Marking fixed again, now that the fix to bug 53207 is checked in on both trunk and branch.

hokay, i know i'm coming a bit late into this bug but, after verifying bug 52871, i noticed that the "Other" submenu item has been replaced by "300%..." --shouldn't it have been replaced with "Other (300%)..."? that would seem more clear to me, imho, from a usability standpoint.

No, it should be Other (300 %)... What I think you are seeing is a problem with stringbundle / navigator.properties. It can't find a certain property, so it falls back on a backup version I put directly into navigator.js. <tangent> I didn't put the English word Other in there. I did put "Text Size" in the main menu, the choice to leave it out was rather arbitrary since this should never really happen. I should perhaps have made that into "Error: Text Size" and "Error: Other" so the fact that there's a problem is more clear. </tangent> Anyway, Hixie saw this problem too, I however don't, so I'm curious what the stringbundle problem is. Wanna help me debug this one? Also, do you only see this on the first run after an install, or do you always see it?

jag, i always see it in the Text Size submenu (ie, even after subsequent restarts). mind you, i'm on the branch (and the commercial flavor, at that)...and using optimized (verification) builds... three possible factors there... ;)

Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...