Closed Bug 37940 Opened 24 years ago Closed 24 years ago

Include some absolute zoom levels in `Text Size' menu

Categories

(SeaMonkey :: General, enhancement, P3)

Product:
SeaMonkey
Component:
General
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bugzilla, Assigned: jag+mozbugs)

References

Details

Attachments

(4 files)

[patch] .tar.gz, 1st take, let the tweaking commence
6.39 KB, application/octet-stream
Details
Screenshot - on Win32
37.31 KB, image/gif
Details
[patch] Second take. Please try this out, it needs to be in tomorrow
35.54 KB, patch
Details | Diff | Splinter Review
[patch] The above .diff was a big oops, use this one instead
36.13 KB, patch
Details | Diff | Splinter Review 
[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.
OS: Windows 98 → All
Hardware: PC → All
I like this suggestion in general.  Targeting M18 so we can investigate further.
Status: NEW → ASSIGNED
Target Milestone: --- → M18
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.
Assignee: bdonohoe → BlakeR1234
Status: ASSIGNED → NEW
Whiteboard: [FIX IN HAND]
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?
Whiteboard: [FIX IN HAND]
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'.
Summary: [RFE] Make text size menu item similar to IE's → Include some absolute zoom levels in `Text Size' menu
*** Bug 47462 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
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.
Blocks: 45647
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.
Assignee: BlakeR1234 → disttsc
Status: ASSIGNED → NEW
And accepting.
Status: NEW → ASSIGNED
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.
Attached image Screenshot - on Win32 — 

    
    

    
  
>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).

    
  
Keywords: patch, 
          
            review

    
    

    
  
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.

    
  
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED

    
    

    
  
Fix checked in.

    
    

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

    
    

    
  
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
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.

    
  
Depends on: 53207

    
    

    
  
Cc:ing saari
No longer depends on: 53207

    
    

    
  
rbs: did you get a message about mid-air collision?

Putting back "depends on" 53207
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.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
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...
QA Contact: mpt → zach

    
  
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: