Closed Bug 389628 Opened 17 years ago Closed 17 years ago

Implement UI for full page zoom

Categories

(Firefox :: General, enhancement, P1)

enhancement

Tracking

()

VERIFIED FIXED
Firefox 3 beta1

People

(Reporter: sharparrow1, Assigned: dao)

References

(Depends on 1 open bug)

Details

(Keywords: relnote)

Attachments

(3 files, 17 obsolete files)

2.12 KB, image/png
Details
57.52 KB, patch
Details | Diff | Splinter Review
50.34 KB, patch
mconnor
: review+
sicking
: review+
Details | Diff | Splinter Review
Now that bug 4821 has been fixed, an API for setting text zoom similar to the one for setting text zoom now exists.  The question now is, how should this be added and integrated with our current text zoom UI?

Filing as UNCONFIRMED so that this goes through the Firefox triage procedure.  Marking uiwanted because it's not really clear how this should be exposed.
mconnor suggested on IRC that we use text zoom up until a certain point (say 120%) then use full zoom after that. If we do this, then we avoid introducing horizontal scrolling for the lower zooms, and don't wreck the layout for the higher zooms.
How would we be introducing horizontal scrolling?  At least the way this is currently implemented, we don't introduce a horizontal scrollbar unless the zoomed content doesn't fit in the window.  (Of course, that could be changed if we wanted to.)
Blocks: 112018
I put a new suggestion in bug 112018 comment 8. I think its simple enough both to implement and use.
(In reply to comment #1)

> mconnor suggested on IRC that we use text zoom up until a certain point (say
> 120%) then use full zoom after that. If we do this, then we avoid introducing
> horizontal scrolling for the lower zooms, and don't wreck the layout for the
> higher zooms.

And you think users are going to understand that ? I don't think so.
Furthermore, such a way of doing would be cool for some sites, and bad for others.
I don't see it as a good solution.
Copying here my proposal added to another bug:

An option would be a zoom button in the main toolbar. Clicking on it zooms in,
shift-clicking on it zooms out, and it's also a menubutton allowing to use a
slider, a textbox and a 1:1 button.
(In reply to comment #0)
> Filing as UNCONFIRMED so that this goes through the Firefox triage procedure.

I'm not sure that'll work. Confirming and requesting blocking, which is the right course of action I think.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox3?
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
Depends on: pagezoom
Should a different bug be filed for seamonkey or can a UI change be made which affects both sm and ff?

Also, I still want it on the menu in Seamonkey in addition to whatever happens on the toolbars.
The core fix in bug 4821 is not entirely enough for a good user experience of
a full zoom. Let me explain : fullZoom zooms all sizes BUT the size of the viewport. So widths and heights in percentage of the viewport's dimension will NOT
be resized. As a matter of a fact, I applied fullZoom=0.5 to CNN's home page and here is the result, attached to this bug.

So the UI for this feature should not only change nsIMarkupDocuementViewer.fullZoom but probably also apply the same %age to the width of the root element of the current document.
And here is the same page when the width of the document's root is also tweaked as proposed... From a user's perspective, let me find it ten times better than the previous screenshot.
attachment 273945 [details] makes more sense to me, especially if you're upscaling. I don't see the point of downscaling if you've got such a big viewport.
Dão, you're not an average user, trust me on that :-)
So does this mean that bug 4821 isn't actually fixed?
(In reply to comment #13)
> So does this mean that bug 4821 isn't actually fixed?

No, it certainly is fixed.

(In reply to comment #12)
> Dão, you're not an average user, trust me on that :-)

Do you think the average user would want to scroll horizontally when scaling
beyond 100%?
(In reply to comment #14)

> Do you think the average user would want to scroll horizontally when scaling
> beyond 100%?

Définitely yes, because if the content is scaled correctly to fit nicely into the
width of the viewport, a 200% zoom of a page basing its contents' width solely on %ages of the viewport will totally hork the layout.
That's analogous to using a smaller screen. It's up to the page to define a absolute (i.e. CSS pixels) width or min-width (or max-width when in comes to downscaling). If it defines the width relatively to the viewport, than that's what the layout engine should deliver.
(In reply to comment #16)
> That's analogous to using a smaller screen. It's up to the page to define a
> absolute (i.e. CSS pixels) width or min-width (or max-width when in comes to
> downscaling). If it defines the width relatively to the viewport, than that's
> what the layout engine should deliver.

I came up with the same example in mind and changed my mind. You're right.
Otherwise it's going to hurt minimo.
(In reply to comment #8)
> Should a different bug be filed for seamonkey or can a UI change be made which
> affects both sm and ff?
> 
> Also, I still want it on the menu in Seamonkey in addition to whatever happens
> on the toolbars.

A separate bug for Seamonkey would be appropriate; the UI implementation is likely to end up in browser/.  You might want to wait and see what the results of the discussion are here, though; there might be some suggestions you'll want to use.
(In reply to comment #9)
> Created an attachment (id=273945) [details]
> test case showing the problem ; see the top toolbar of CNN home page
> 
> The core fix in bug 4821 is not entirely enough for a good user experience of
> a full zoom. Let me explain : fullZoom zooms all sizes BUT the size of the
> viewport. So widths and heights in percentage of the viewport's dimension will
> NOT
> be resized. As a matter of a fact, I applied fullZoom=0.5 to CNN's home page
> and here is the result, attached to this bug.
> 
> So the UI for this feature should not only change
> nsIMarkupDocuementViewer.fullZoom but probably also apply the same %age to the
> width of the root element of the current document.
> 

I was actually going to file this as a separate bug, it seems like incorrect behavior to me.  For example, even here on bugzilla.mozilla.org, the gray box around the bug title is width=100%, so it doesn't really scale right with the rest of the page.

FWIW, I threw together a quick extension to test this feature out:
http://ted.mielczarek.org/code/mozilla/fullpagezoom.xpi - it adds three toolbar buttons for zoom in, zoom out, zoom 100%.  It also has a pref (use about:config) - extensions.fullpagezoom.zoomfactor - to control the zoom factor.


What about the mousewheel.with*key.action prefs?
See nsEventStateManager::DoScrollTextsize etc.
Attached image Office 2007's zoom UI (obsolete) —
When IE7 got its zoom feature and was blogged about, the comments indicated that people didn't want a popup with zoom choices but instead wanted a UI like Office 2007. I've attached a picture of it if you don't know what it looks like.

I guess a slider is the best idea if we are going to put anything in the statusbar at all. If you can, having it snap on 100% (like Office 07) would be great.
When writing documents, changing the display size is a more common task, so the slider/buttons/whatever deserve a place in the primary UI.

IMHO that's not the case for the browser. Ideally, you would adjust the zoom rate for a site only once and Firefox would remember it like it remembers text zoom.
I'd like to try full page zoom as a replacement for text size. I think Ctrl +|-|0 should refer to full page zoom. It works like this in IE7 and Opera, and it feels nice. The zoom widgers of both IE7 and Opera refer to full page zoom. I can't even find the a text size settig in Opera's menu.
I usually prefer text zoom to full page zoom because full page zoom makes images ugly.  I shouldn't have to choose between easy-to-read text and reasonable-looking images.

Sometimes I want to zoom in on images, but usually they're standalone, so that could be accomplished by making Ctrl++ / Ctrl+- do "full zoom" on standalone images only.  (Also, on Mac, I can use ctrl+scrollwhell for temporary zoom on any part of a page, and cmd+opt+\ lets me toggle smoothing.)
Summary: Implement UI for page zoom → Implement UI for full page zoom
I think, the user should be able to do both text-zoom and full-zoom.

Using a slider to zoom seems ugly, because scaled images look best only at specific zoom factors. For example they look good at 100% and 200%, but not at 97.6% or 207.3%. I think we should use a dropdown box like in Opera and IE7.

The other problem is, where to place the dropdown. I think the statusbar would be a bad idea because you can not move or remove items there. On the other hand it would be difficult to find a good location for a toolbarbutton.

We could, of couse implement no UI at all (like now), and use a preference to decide if the user wants to use full page zoom or text zoom when he uses Ctrl+Mousehweel or the view menu. But there may be advanced users who want to use both at the same time, for example when testing and developing websites.

I agree that we should zoom standalone images, so forcing full zoom on standalong images seems to be a good idea.
For an example of full zoom and why scaling the document root is nice, go play with an iPhone... 

As for UI, how about a place in settings where you can tweak which type of zoom you prefer. The prefered zoom is what you get with ctrl-scroll. 

The question I would like to pose is do we beleive that the average user is going to want to zoom text some times and do full zoom at other times? Or are they more likely to want one consistant, convenient zoom that behaves in the way they have decided they prefer.

I really doubt people are going to think about which zoom they are using. To most people zooming is zooming. The details of how it works only matter to a few. I think if you have two different zoom controls, you will only confuse the average user, even if you make a small number of us geeks very happy :)
Just my idea:

1. Change Ctrl +/-/mousewheel to control full page zoom
2. Add View->Page Zoom below View->Text Size
3. Maybe add a dropdown

1. Is a good idea, I think, because page zoom is generally more useful, for example when trying to zoom images, and because other browsers do pagezoom by default, too.
2. Both zoom options are available for the advanced user.
3. Optional. I think it is a good idea, but I find it difficult to find a good location.

This way we won't need additional preferences and zooming images would be no problem, too.
My idea, based on Jonathan's:
1. Make <Ctrl>+<+>/<->/mouse change zoom, and <Ctrl>+<0> or <Ctrl>+middle click reset it.
2. Make <Ctrl>+<Shift>+<+>/<->/mouse change text size, with <Ctrl>+<Shift>+<0>/middle click resetting.
3. Add View->Zoom below Text Size (the worde "Page" is unneeded, because the difference between "Text Size" and "Zoom" is clear enough.)
4. Decide whether to add an Office 2007-style zoom slider to the status bar or leave it up to extension writers. (I think we should add it.) If implemented, it should change in real time as you use Ctrl+mouse to zoom.
5. When the page being zoomed is an image (both standard GIF/JPG/PNG and SVG, opened directly, not embedded), always use page zoom, as changing text size doesn't resize the image.

1. was already explained by Jonathan. Ctrl+Middle click is an easy way of resetting zoom.
2. makes *both* zoom options readily available without having to click on buttons on menus. Again, Ctrl+Shift+middle click might be much easier for some people than Ctrl+Shift+0.
3. Both text size and zoom are discoverable.
4. Makes zoom visible for the beginner user.
5. Fixes the annoyance of trying to "zoom" in on a separately opened (that is, non-embedded) image, and failing to do so because of accidentally changing text size instead of zooming.
Also, a pref (hidden or exposed) that switches <Ctrl>+mouse and <Ctrl>+<Shift>+mouse around (so that <Ctrl>+mouse becomes text size and <Ctrl>+<Shift>+mouse becomes zoom) would be good.
Ctrl+Shift+Mousewheel is currently used by History. I don't know if we should change this.
I'd like to express my opinion that text zoom should be replaced. My arguments pretty much revolve around the fact that text zoom is not what people ever expect. No other apps but web browsers have it, doesn't relate to anything in real world, and in general font size is seen as a website choice (much like colour, font type) than user setting.
A generic text zoom could go to Options->Content->Fonts&Colours where it logically belongs.

As for making images ugly... actually why is Minefield using pixel resize again? Bilinear would make the problem go away. And then, better scaling algorithms exist (not in scope I suppose).
I think that it would be really cool if we could somehow just let the user set the default font size, and trigger page zoom automatically on pages where setting the default font size isn't sufficient (i.e. those which use pixel font sizing).  I think there might have been some proposals floating around for how to do that.

(Note that I personally browse with a default font-size of 26px and a min-font-size of 18px because my display is relatively high-resolution and my eyesight isn't especially great.)

(In reply to comment #31)
> As for making images ugly... actually why is Minefield using pixel resize
> again? Bilinear would make the problem go away. And then, better scaling
> algorithms exist (not in scope I suppose).

Bilinear filtering is Bug 381661.
(In reply to comment #31)
> I'd like to express my opinion that text zoom should be replaced. My arguments
> pretty much revolve around the fact that text zoom is not what people ever
> expect. 

Old Firefox users may expect this. And text-zoom is still usefull if you want to increase text-size but do not want to make the page bigger or make the images and borders look ugly. Even bilinear or bicubic filtering will not prevent this completely.

> No other apps but web browsers have it, doesn't relate to anything in
> real world, and in general font size is seen as a website choice (much like
> colour, font type) than user setting.

I am one of these "More power to the user!"-fraction. I think you would improve nothing by removing for example View->Text Size.

(In reply to comment #32)
> I think that it would be really cool if we could somehow just let the user set
> the default font size, and trigger page zoom automatically on pages where
> setting the default font size isn't sufficient (i.e. those which use pixel font
> sizing). 

Please don't do such things automatically. Firefox should not be really cool, it should be useful and user friendly. And automatically doing strange things with the website isn't very user friendly.
Definitely wanted, not a blocker. Will circle around with comments, but I'm wondering why we'd offer two different types of zoom instead of just calling *this* zoom and calling the other thing changes to the default text size and leaving it to the font prefs.

Myk: will site specific prefs leverage this or font-resizing?
Flags: blocking-firefox3?
Whiteboard: [wanted-firefox3]
(In reply to comment #34)
> Definitely wanted, not a blocker. Will circle around with comments, but I'm
> wondering why we'd offer two different types of zoom instead of just calling
> *this* zoom and calling the other thing changes to the default text size and
> leaving it to the font prefs.

Most of time, especially with well-written pages whose layout scales well with increased text size, I don't *need* to zoom entire page. Of course, if it was only about redundancy of zooming everything then I could easily live with it. But full page zoom has some other drawbacks compared to text zoom:

- decreased quality of images
- most of all, the page grows horizontally and gets a horizontal scrollbar! Enough said, I think we all hate it. Opera fits pages to width but we don't.
(In reply to comment #35)
> - most of all, the page grows horizontally and gets a horizontal scrollbar!

It won't with our zoom implementation, unless the page uses a fixed width.
(In reply to comment #36)
> (In reply to comment #35)
> > - most of all, the page grows horizontally and gets a horizontal scrollbar!
> 
> It won't with our zoom implementation, unless the page uses a fixed width.
> 
Which unfortunately is fairly often the case...
(In reply to comment #37)
> (In reply to comment #36)
> > (In reply to comment #35)
> > > - most of all, the page grows horizontally and gets a horizontal scrollbar!
> > 
> > It won't with our zoom implementation, unless the page uses a fixed width.
> > 
> Which unfortunately is fairly often the case...

But then again, most fixed-width pages break horribly after you increase text size a few times.

I vote for a somewhat similar approach to IE: leave the text size in a menu as is, and make the page zoom easily discoverable (IMHO it could go well on the status bar, though I'm not sure on the best UI yet).

For all other shortcuts (mouse scroll, keyboard) full zoom should be preferred, as it still has the least chance of breaking websites, is (slightly) more familiar to users because of IE7 and Opera, and generally has more uses—a friend of mine uses IE7's zoom to see YouTube videos, for instance—, but I'm in favor of a hidden preference to revert it.
> For all other shortcuts (mouse scroll, keyboard) full zoom should be preferred,
> as it still has the least chance of breaking websites, 

I don't think that's true.  Almost any site with a fixed width will break (create a horizontal scrollbar) with full zoom.  It's rare for sites to break with small amounts of text zoom, and the occasional breakage is usually something minor like navigation links overlapping.

> is (slightly) more familiar to users because of IE7 and Opera

I think users are more familiar with IE6 than they are with IE7.
Well since we're discussing possible solutions I'll keep discussing. If you think bugzilla is not the right place (even in this case) I apologise.

(In reply to comment #33)
> Old Firefox users may expect this. [text zoom - ed. me]

This is true. But this might be an argument against any improvement - old users might expect no changes at all and yet improvements do happen.

> And text-zoom is still usefull if you want
> to increase text-size but do not want to make the page bigger or make the
> images and borders look ugly.

A button for making pages pink is useful if someone wants to make images pink. True by definition ;) but not a good reason to bloat UI imho.

> Even bilinear or bicubic filtering will not
> prevent this completely.

Again true, but nevertheless we do that all the time when viewing photos or movies etc. Bitmaps don't scale well and yet we don't add more UI which would prevent them from scaling.

> I am one of these "More power to the user!"-fraction.

A valid approach, but this is where we differ :)

> I think you would improve
> nothing by removing for example View->Text Size.

IMHO removing UI is always an improvement (yes your feeling is opposite, I understand that).

(In reply to comment #39)
> I don't think that's true.  Almost any site with a fixed width will break
> (create a horizontal scrollbar) with full zoom.

Perhaps you zoomed too much? If text zoom is small enough that they don't break, then the same zoom is small enough that they don't develop scrollbars.

Most pages that need zooming are sub-800px-wide.

By they way, anyone considered a good zoom step? I'm in favour of either 2^0.33 = 1.260 or 2^0.25 = 1.189 (three steps or four steps for 200% scaling).

  It's rare for sites to break
> with small amounts of text zoom, and the occasional breakage is usually
> something minor like navigation links overlapping.
> 
> > is (slightly) more familiar to users because of IE7 and Opera
> 
> I think users are more familiar with IE6 than they are with IE7.
> 

(In reply to comment #39)
> I don't think that's true.  Almost any site with a fixed width will break
> (create a horizontal scrollbar) with full zoom.

Well, I, personally, don't really consider that a "break" per se. I also agree with comment #40:
> Most pages that need zooming are sub-800px-wide.

If the page actually needs zoom, it was possibly designed for an inferior display resolution (i.e. less DPI) than yours, so your browser window should accommodate zooming in a bit. And if we are talking about average Windows users, then that also means maximized browser windows even on LCD monitors with ridiculously wide display areas. But of course, YMMV (and my reasoning about the others' experiences could be quite off from reality).

> > is (slightly) more familiar to users because of IE7 and Opera
> 
> I think users are more familiar with IE6 than they are with IE7.

But IE6's text sizing never worked for a very large set of websites (it failed to affect pixel-defined dimensions), making it less useful. It also was not as easily discoverable as Opera's and IE7's zoom. So, in the end, I really doubt it was ever as used as other browsers' features are today, considering the proportions.


(In reply to comment #40)
> IMHO removing UI is always an improvement

I generally agree with that, but I think in this case keeping text size would be better.

> By they way, anyone considered a good zoom step? I'm in favour of either
> 2^0.33 = 1.260 or 2^0.25 = 1.189 (three steps or four steps for 200% scaling).

I am currently using 119% for the same reason you suggested (but rounded to fit the Zoom extension's limitation), and I'm pretty happy with it.
(In reply to comment #40)
> A button for making pages pink is useful if someone wants to make images pink.
> True by definition ;) but not a good reason to bloat UI imho.

True. But I think more users prefer using text-zoom to making images pink. And I would not consider a "hidden" menu entry as bloat.

> IMHO removing UI is always an improvement (yes your feeling is opposite, I
> understand that).

<irony>Yeah, let's remove the adressbar, the statusbar and the tabs</irony>
IMHO, removing useless UI is an improvement. Changing text-size (for only one website without changing preferred size) is not useless. Many websites even do not respect the setting in the preferences (and don't have to).

(In reply to comment #39)
> I don't think that's true.  Almost any site with a fixed width will break
> (create a horizontal scrollbar) with full zoom.

I disagree. Most fixed-width pages are smaller than the viewport and can be zoomed alot until they hit the common 1024 or 1280 pixel screen width. 

Depends on: 381661
(In reply to comment #34)
> Definitely wanted, not a blocker. Will circle around with comments, but I'm
> wondering why we'd offer two different types of zoom instead of just calling
> *this* zoom and calling the other thing changes to the default text size and
> leaving it to the font prefs.
> 
> Myk: will site specific prefs leverage this or font-resizing?

We can do either or both, depending on what makes sense.  We've had text zoom for forever, plenty of time to gather bunches of feedback from folks who wanted Firefox to remember that setting per-site.

But since we've never had page zoom before, we have no such feedback on that feature.  Perhaps we can leverage the experience of folks who have used page zoom in Opera and IE.  Or maybe we should just make a guess, try it out, and see what our testers think.

If I had to make a guess, I'd guess that users generally want text zoom changes to apply to the site and persist across sessions but for page zoom changes to apply only to the specific page and not persist.

For example, a user might use page zoom to make a YouTube video larger only while playing it (and not while jumping from page to page afterwards looking for the next YouTube video to watch).
(In reply to comment #43)
> If I had to make a guess, I'd guess that users generally want text zoom changes
> to apply to the site and persist across sessions but for page zoom changes to
> apply only to the specific page and not persist.

My guess would be that two ways to zoom could confuse users. IMHO text zoom should be degraded while full zoom should get Daniel's proposed statusbar GUI and primary shortcuts.

> For example, a user might use page zoom to make a YouTube video larger only
> while playing it (and not while jumping from page to page afterwards looking
> for the next YouTube video to watch).

Apart from zooming a video, I would expect full zoom to be at least as useful and successful when it comes to making sites more accessible (readable). If this wouldn't be the case and if full zoom were just a gimmick, not remembering the zoom rate would make sense. But otherwise, zooming out on YouTube after you've zoomed in is just logical.
> If I had to make a guess, I'd guess that users generally want text zoom 
> changes to apply to the site and persist across sessions but for page zoom 
> changes to apply only to the specific page and not persist.
> 
> For example, a user might use page zoom to make a YouTube video larger only
> while playing it (and not while jumping from page to page afterwards looking
> for the next YouTube video to watch).

But I should note that there are also use cases where site-specific text zoom falls down.  Specifically, one person has mentioned to me that he sometimes increases the text zoom while temporarily sitting farther away from his monitor.  Another told me he increases the text zoom in the morning when he doesn't see as well.

And yet we still decided to implement site-specific text zoom for Fx3, because that satisfies the needs of the large majority of users.  So just because site-specific page zoom doesn't satisfy some use cases, that doesn't mean we shouldn't implement it.  Rather, knowing that we can't please everyone, we should take into account how well site-specificity for page zoom would satisfy the most significant use cases.

(FWIW, both of those people mentioned above have tried to satisfy their needs via the tab-specific text zoom in Firefox 2, although what they'd really need is global text zoom, which is implemented in the Fx3 text zoom code but not exposed in UI.)
A note for those discussing this: a proposal with an extension to demonstrate it would likely get a lot more attention.  Without a significant number people actually trying it out, this discussion is mostly just speculation.

(I think all the necessary hooks are exposed to extensions; if they aren't, we probably just want to go ahead and implement this with a lot of hidden prefs.)
Attached file Basic mockup (obsolete) —
This extension creates a very simple zoom UI with a statusbar entry similar to IE7's and a menuentry under view. I wanted to change the strg+mousewheel shortcuts, too, but I don't know how to do this in an extension.

Fell free to use it, to enhance it, etc.
Attached file UI with slider panel (obsolete) —
Thanks for your extension, Jonathan. It was useful to me as a starting point.

This version features a slider which can be opened from the status bar. It also replaces Text Zoom altogether.
It looks good, with one exception: do NOT remove text zoom!
(In reply to comment #49)
I really don't care, as I don't need two ways to zoom. But I'm also not beltzner, so don't tell me.
Attachment #274826 - Attachment is obsolete: true
I would just say that that slider is hard to see and grab with the cursor (especially on higher resolution screens) as it is so small.  The type of people using page zoom (People with less than average eyesight, people who are farther away, ect..) need something extremely easy to see, something big and easy to use with the mouse cursor.
(In reply to comment #51)
> I would just say that that slider is hard to see and grab with the cursor
> (especially on higher resolution screens) as it is so small.  The type of
> people using page zoom (People with less than average eyesight, people who are
> farther away, ect..) need something extremely easy to see, something big and
> easy to use with the mouse cursor.

It's the default size of a xul slider (which is actually bigger than the Windows default, I think). There are menu entries and keyboard shortcuts, too.
It looks like a Vista-specific problem with the too small slider. I just filed bug 390696 about it.
(In reply to comment #53)
> It looks like a Vista-specific problem with the too small slider. I just filed
> bug 390696 about it.
Yeah, it looks fine in XP. I'm thinking we have to avoid using that particular slider type UI style until bug 390696 is fixed.
My suggestions:

1. I think there should be a Page Zoom entry in the View menu, above Text Size.

2. I'd also move Page Style above that — Page Style changes the appearance of the page the most, followed by Page Zoom, then Text Size.

3. The keyboard shortcuts, Ctrl++, Ctrl+- and Ctrl+0, should apply to either Page Zoom or Text Size, whichever is determined to be the most common (though I suggest Page Zoom).

4. The menu entries should use an absolute approach (50%, 100%, 200% etc.) to selecting page zoom and text size. If we use a relative approach (bigger, smaller) and the user finds “bigger” not to be big enough, it takes too long to select the same menu entry again. The current zoom level and text size can be indicated by a bullet (like the current character encoding).

5. It would be useful to show the current level of zoom and the current text size in their respective View menu entries, as the Image Zoom extension does for image zoom. (I think Opera does this, too.)

6. There should be two new toolbar buttons, Zoom In and Zoom Out. A relative approach is better than an absolute approach here because toolbar buttons are supposed to be for quick, one-click interaction with the browser. It's easy to click the button again if the desired results aren't achieved; users that want a specific zoom level can use the menu.

7. Whether these buttons appear on the toolbar by default depends on how discoverable the Customise Toolbar dialogue is judged to be; and on how minimal we want the toolbar to be kept.

8. A zoom control shouldn't appear in the status bar because it does more than just showing status. The feed icon was moved from the status bar for this reason (if I remember correctly).

9. The page zoom setting should persist exactly as the text size setting does. The use cases aren't significantly different and they're essentially two ways of doing the same thing.
An interesting possibility would be a combined zoom: First full-zoom. When the page would overflow the screen and demand an horizontal scrollbar: text-zoom.

Users won't think in terms of "text" or "images" zoom. They just want to read the page, and despise horizontal scrollbars.

The drawback is that this will prevent specialized use like forcing a full zoom for seeing an image little details.

Does this make sense? =)
Are you sure users hate horizontal scrollbars? I mean, sure they hate them when they appear on the initial page, but in a zoomed page it seems natural... keep in mind that a typical user thinks of a webpage as a document, like a piece of paper. What happens if you move a piece of paper closer to your eyes? Right, it gets bigger and if it's too big you can't see all of it anymore. On zoom-out it makes sense to sacrifice that metapher in order to show more content (eventhough I'm not even entirely sure about that... if we really zoomed, without reflowing then the user would still see twice as much content along the Y axes), but on zoom-in it really gets confusing for an average user (hell, it would confuse me if I had not read about it here).

About text-size and page-zoom. Keep in mind you have a large number of users who use text-size every day... and I for one would be really annoyed if a behaviour that I have gotten used to would suddenly change. As a rule of thumb I'd say, don't replace features with something else... try to find a different spot for them.

But first things first... how do you expect it to be used? Is this a tool that a person uses on a single page or is it a setting for the whole domain? If it's a setting it should get a spot in the View menu and not clutter up the GUI. However if it's a tool that the user is supposed to activate on a certain page and which gets deactivated automatically, then it needs a quickaccess feature by providing a button.
I would like to re-emphasize that we should think about WHY people zoom. To me there are two main use cases:

1. The user has poor vision and needs to quickly adjust the size of elements on the page in order to make them readable.

2. The user has a monitor with a high resolution and very small pixels. They also need to increase the size of the page to make it readable.

These two use cases have a critical difference. The second user has an excess of screen real-estate, whereas the first likely already has maximized their browser and is probably running at low resolution.  

If the first user zooms, they would (IMHO) probably prefer that the page simply gets bigger, and none of the layout changes. This means scaling the document root and everything on the page.

If the second user zooms they almost certainly don't want the document root to scale. They will be doing a large amount of browsing at high zoom levels and if the entire web gained a horizontal scroll bar, I suspect they wouldn't be happy.

So is there a third use case? Is there any reason to believe that normal users will regularly use both types of zoom? The only reason to *add* UI is if both have to be available at the same time. Otherwise the entirely normal thing to do is have a user preference for the behavior of the previously established UI.

The default behavior should be the one appropriate for the more common use case (number 2 I suspect). I have yet to hear anyone spend effort expressing that they want to do both. Mostly people commenting here seems to be deathly afraid that they won't be able to easily do the ***one** that they like. Thus we need one UI and a preference not two competing UI's.
Oh ****. I got first and second mixed up in my last comment... The 5th and 6th paragraphs should read...

If the second user zooms, they would (IMHO) probably prefer that the page simply
gets bigger, and none of the layout changes. This means scaling the document
root and everything on the page.

If the first user zooms they almost certainly don't want the document root to
scale. They will be doing a large amount of browsing at high zoom levels and if
the entire web gained a horizontal scroll bar, I suspect they wouldn't be
happy.
Possible UI to handle Gus's two use cases/zooming styles, assuming that I've understood him correctly:

(UI option 1:) A radio button, possibly in a Page Zoom group box:

Page Zoom should change the size of:
 (o) items on the page and the page itself
 ( ) items on the page

As with the one in the Tabs pane, “New tabs should open in:”, a two-option radio button might be clearer than a tick box, whose “off” behaviour may not be obvious.

This way, if we decide that the Text Size control should be considered another type of Page Zoom, we can add a third option:

Page Zoom should change the size of:
 (o) all items on the page and the page itself
 ( ) all items on the page
 ( ) text only

(UI option 2:) A tick box *would* be better if the “off” behaviour is clear:

[x] Allow Page Zoom to change the size of the page itself

(I prefer this option, unless we're folding Text Size into Page Zoom, and as long as the wording can be clear enough.)

These should go in the Content pane of Preferences; strictly, it's more “View” than “Content”, but so is Fonts & Colours. It *could* go in Advanced if there's nowhere better for it.
There is a third kind of people. Those who use Zoom on a per-page basis in order to navigate the page and get rid of annoying sidebars... think about Acrobat Reader for a second... however it could be argued that this should be left to an extension to implement... on the other hand, I never understood why we keep the "customize" menu that empty... couldn't we simply add the zoom-docroot button there and leave it to users to add?

As for shortcuts... what about mousebutton3+mousewheel... right now this does nothing except normal mousewheel scroll... this kind of navigation works beautifully for Cliés (Sony's Palm devices) so why shouldn't it work for us? Of course we still need a keyboard shortcut...

(In reply to comment #58)
> I would like to re-emphasize that we should think about WHY people zoom. To me
> there are two main use cases:
> 
> 1. The user has poor vision and needs to quickly adjust the size of elements on
> the page in order to make them readable.
> 
> 2. The user has a monitor with a high resolution and very small pixels. They
> also need to increase the size of the page to make it readable.

Of course, many users buy a larger monitor with "better resolution" because they have poor vision. They then proceed to crank it up. This is a mix of both of your scenarios.
In the past days I've tried to observe my own behaviour the best I could... and I think we really need both, or a combination of both:

First of all, Zoom is an ugly beast with non-integer multipliers... it looks OK with 2x, 3x and to a certain degree 0.5x. However I find myself using inbetween values very often. Especially with Windows font hinting, I often need only a slightly bigger text size in order to jump from almost unreadable to perfectly fine. Combining both would solve this (so that for example 2.3x would zoom by 2 and scale fonts by 1.15x). So the page would only see a font that's <2x the originally intended font-size. That should work for most pages.

The problem is that I also found myself using text-size to de-emphasize graphical elements when I want to focus on reading... and that's something such a combined tool could not do.

I'd prefer having both available via seperate shortcuts in the view menu, but from what I've experienced combining both seems like a partially satisfying option.


I don't think a "switch zoom-mode" setting is a particularly good idea... for one because I use both, but also because this would make for one scary shortcut model (and we'd need shortcuts for that). Think about it:

Either we keep two seperate shortcuts. Then the user would set zoom mode to "Whole Page", and hit the shortcut he used to zoom text before... and it still would zoom only the text... they'd be pretty confused.

Or we set it to a single shortcut... but that would mean that users who like to use both have zero chance of doing so. Not very satisfying.
OK, this is getting off the rails. As best I can tell, we've used text size as a proxy for zoom because, well, we couldn't do the other thing.

Zoom is zoom.
Text size is text size.

The "text size" controls in the view menu should be replaced with "zoom", and site-specific preferences should remember those values. We should focus on serving those who want larger text through the default text size in preferences.
Beltzner, there are many situations mentioned in this bug in which text zoom is clearly better than full zoom.  If you want to replace text zoom with full zoom, you need to explain why you think the tradeoff favors full zoom (and only full zoom).  You can't just ignore the whole debate/tradeoff by speculating as to the historical reasons that Firefox has text zoom.
I'd have to agree... also, the way I see it the only case where we've found users constantly changing the zoom level is if it scales the document root too... which doesn't seem to get a majority vote. Otherwise it's pretty much something the user changes globally to account for a very high resolution -> Prefs

The font size on the other hand is often set for a single page, making fast access necessary. -> Shotcuts/Menu

Sure, zooming is cool... but I just don't think it needs fast access for anything but fooling around.
@ Beltzner (comment 64),

From a conversation with a lady at a clients office: 
* average person, 40+ old. 
* recent desktop computer, better than average monitor (read, recent LCD).
* Win XP + IE 7.

Question from the lady: "why didn't they put a button to just make the text larger?"

Translation: "the (IE7) '(page)zoom' doesn't work for me, doesn't do what I need". The lady doesn't want the whole page to zoom, but only larger text.

(she knows how to do it, but being an average Windows user, she expects buttons to click on with the mouse for everything).
(In reply to comment #66)
> the way I see it the only case where we've found
> users constantly changing the zoom level is if it scales the document root
> too...

Why?

> Otherwise it's pretty much
> something the user changes globally to account for a very high resolution ->
> Prefs

You never know the DPI setting and the screen resolution that an author had in mind, which a) affects text *as well as non-em declarations and images* and b) will get worse in the future due to more different-sized devices. If you set a global zoom level (minimo?), that won't prevent you from zooming single pages in or out.

A global minimum font size, on the other hand, can be set. Firefox already supports that.

(In reply to comment #67)
> Translation: "the (IE7) '(page)zoom' doesn't work for me, doesn't do what I
> need". The lady doesn't want the whole page to zoom, but only larger text.

Firefox doesn't have IE7's nonsensical page zoom. See http://www.smackthemouse.com/ie7bzoom#h2-4
The case for site-specific settings for full page zoom: A lot of websites have fixed widths, which can be a lot of space lost in wide screen displays, or high dpi that doesn't quite trigger a jump in everything being bigger (say, anything from 120-140?). So some sites might have the fixed width, and small enough text it would be good just to zoom the thing in to see it better. Whereas other sites might have better, more dynamic layout.

I know specifically that this would be useful for higher dpi settings, because when showing the dpi detection feature to a colleague on his high resolution monitor (204 dpi), his immediate reaction was that he thought it didn't work - because Firefox was still very small, but more importantly, the site was horribly small, and I had to use the javascript hack to activate zoom for him to be fully satisfied.
Here are my new ideas:
1. Until we figure out the right UI, implement a menu similar to the one for text zoom, so users can use/test full zoom, and to gather more feedback about the backend.
2. The mouse shortcut for the zoom type that doesn't get Ctrl+mouse: scrolling with the middle button pressed. Possibly implement middlebutton+scroll for page zoom for now, again to gather feedback and make testing easier. (It would be good to collect feedback from the casual testers, nut just the "hardcore" ones who go through installing a test extension.)
We should probably start making patches for this very soon... Dao, do you want to convert your extension to a patch or shall I give it a go when I have time?
Ok, I'll take this with comment 64 as the reference. I'll start with just renaming the View menu entry, which is critical for l10n.
Keywords: uiwanted
Attached patch required locale changes (obsolete) — Splinter Review
"Text Size" -> "Zoom"
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #281170 - Flags: ui-review?(beltzner)
Attachment #281170 - Flags: review?(mano)
Attachment #273945 - Attachment is obsolete: true
Attachment #273946 - Attachment is obsolete: true
Attachment #274136 - Attachment is obsolete: true
Attachment #274779 - Attachment is obsolete: true
Dao, I think it would be best if text zoom was not completely replaced and was still available as a separate option, I'm sure there would be some situations where only text zoom is desired.
I don't really see those situations. Two ways to zoom smells like bloat, and as I wrote earlier, it might even confuse users. Text zoom would still be supported, an extension could add an UI for it.

A global minimum font size combined with page zoom should satisfy most users, which is also what beltzner wrote. So I'm going to do that.
I'd rather think that silently replacing text-zoom with page-zoom is bound to confuse users who were using text-zoom before... and I think with proper naming for both zoom types (i.e. "Text Size" vs. "Page Zoom") confusion would be at an absolute minimum... As I said before, there are plenty of cases where I prefer text-zoom over page-zoom, for the simple reason that page-zoom is bound to create an ugly page... you simply cannot scale images without degrading quality. Also, as I said before: Text-Zoom is a very easy to use way to favour content over style and I (and at least two people I've talked to) use it that way.
Let me mention that Minefield nightlies store the text zoom persistently per site. When Text Zoom UI is replaced, the stored values need to be reset, or converted to page zoom values.
I ran into this when I tried the extension attached with comment #50 - a site was displayed with larger fonts, but I had no way anymore to control this.
When Firefox moves to Page Zoom, the current site-specific preferences for Text Zoom would just be ignored.
(In reply to comment #78)
> When Firefox moves to Page Zoom, the current site-specific preferences for Text
> Zoom would just be ignored.

Right, and it would make sense to leave them around, even though we aren't applying them, so users can get them back if they install an extension that provides them with the ability to set text zoom.
(In reply to comment #75)
> I don't really see those situations. Two ways to zoom smells like bloat, and as
> I wrote earlier, it might even confuse users.

Just have a "Zoom" option under "View", then have two choices under "Zoom":"Zoom Text Only" and "Zoom Everything".  Doesn't sound too confusing to me when both choices are right there together.

Does this tie in to XP and Vista’s DPI settings? My display is 15" 1680x1050, and I’ve set Vista to 120dpi to compensate and keep things readable.

I kept zooming in on pages for a long time, very often. Nowadays, I’ve tweaked the font sizes in the pref panel which helped a lot, but it wasn’t really easy to do, it would be better if Firefox would just latch on to the OS its DPI setting and do ‘the right thing’. I don’t use the minimum font size function by the way. I’m fine with small characters (e.g. for small print notes, or subscripts), I wouldn’t want to force them bigger by setting a minimum font size. I just want the ‘default size’ to be readable.

And if a page designer is too retarded to pick a legible font size, I can enlarge the text by zooming in. On sites like http://anidb.net/ I still use text zoom all the time, it’s just too small. Getting a horizontal scroll bar when zooming like IE7 does would be very undesirable, it’s useless. I never understood why they implemented it like that. If you size the text up 4 sizes, you have to scroll horizontally for every line you’re reading.

As for zooming images, indeed scaling only looks decent on certain values. So it’s probably best if they would ‘snap’ to e.g. 0.5, 0.75, 1.0, 1.5, 2.0, etc. This behaviour is also described in CSS[1], kind of. So in effect, for e.g. 120dpi it would scale images by 1.0, for 130dpi it would scale them by 1.5 and for 192dpi it would scale them by 2.0. That would avoid them looking too unsharp.


~Grauw

[1] http://www.w3.org/TR/CSS21/syndata.html#pixel-units
That's more or less exactly what we do, except that we snap to integer values. So you need to set your DPI to 144 or higher to get into "high DPI mode".
(In reply to comment #81)
> Does this tie in to XP and Vista’s DPI settings? My display is 15" 1680x1050,
> and I’ve set Vista to 120dpi to compensate and keep things readable.

See comment 82.
(Here's what I wrote before roc's comment appeared: I don't think DPI settings are currently respected, although there should be a hidden pref to adjust it manually. You might want to look for an existing bug on that, or file one.)

> And if a page designer is too retarded to pick a legible font size, I can
> enlarge the text by zooming in. On sites like http://anidb.net/ I still use
> text zoom all the time, it’s just too small. Getting a horizontal scroll bar
> when zooming like IE7 does would be very undesirable, it’s useless.

You'll be pleased to hear that with Gecko's full page zoom and a 1680x1050 display, I don't get a horizontal scroll bar at 240% (which is currently the maximum value in the UI).

> As for zooming images, indeed scaling only looks decent on certain values. So
> it’s probably best if they would ‘snap’ to e.g. 0.5, 0.75, 1.0, 1.5, 2.0,
> etc.

Yeah, it could be that the UI will have to do .25 steps. But I kind of hope that bug 381661 will be fixed for 1.9, which would render this unnecessary.
(In reply to comment #75)
> I don't really see those situations. 

Dao,

Perhaps that's because you use the browser differently than we do, or you view different pages with it?  That's fine, just please listen to other people, so you see a more complete picture before making a decision.

> Two ways to zoom smells like bloat, and as
> I wrote earlier, it might even confuse users. Text zoom would still be
> supported, an extension could add an UI for it.

I'll explain the single most important reason why text zoom is essential to me, and for many of the people I work with.  You make the decision.  (I don't like to argue.)

I don't have good eyes, and I have a relatively small screen.  I use text zoom very often, especially when I am tired.  

I view web pages with lots of mathematics daily.  These pages almost always include the formulae as images.  Try to use full page zoom on these pages, and they'll become unreadable:

http://en.wikipedia.org/wiki/Gram-Schmidt_process
http://mathworld.wolfram.com/Gram-SchmidtOrthonormalization.html

Extensions are not really a solution, since (in my limited experience) most people don't use them (or won't have the time and patience to search for the suitable extension that restores text zoom functionality).

> A global minimum font size combined with page 
> zoom should satisfy most users,
> which is also what beltzner wrote.

When you say "most users," think about those users who have actually used the text zoom feature regularly in earlier version.
(In reply to comment #84)
> I view web pages with lots of mathematics daily.  These pages almost always
> include the formulae as images.  Try to use full page zoom on these pages, and
> they'll become unreadable:
> 
> http://en.wikipedia.org/wiki/Gram-Schmidt_process
> http://mathworld.wolfram.com/Gram-SchmidtOrthonormalization.html

We surely don't want page zoom to suck in those situations. Maybe I should ping vlad regarding bug 381661 ...
(In reply to comment #84)
> http://en.wikipedia.org/wiki/Gram-Schmidt_process
> http://mathworld.wolfram.com/Gram-SchmidtOrthonormalization.html

Looking at these under my default setup here, the text in the images and in the page is very very close. If I wanted one magnified, I couldn't imagine not magnifying the other. And the pages flow well on a small-width window, so doing a real full-page zoom would seem to work quite well on a maximized window. Perhaps you could clarify what you mean when you suggest these wouldn't work well?

On that note, maybe "Magnification" would be a better word to describe what full-page zoom does?
(In reply to comment #86)
> Perhaps you could clarify what you mean when you suggest these wouldn't work
> well?

OK, I'll clarify.

I use zoom to make the text more readable (I get tired quickly when reading small type).  On magnified images the text is less readable, sometimes completely unreadable.

> (In reply to comment #84)
> > http://en.wikipedia.org/wiki/Gram-Schmidt_process
> > http://mathworld.wolfram.com/Gram-SchmidtOrthonormalization.html
> 
> Looking at these under my default setup here, the text in the images and in 
> the page is very very close. If I wanted one magnified, I couldn't imagine not
> magnifying the other. 

When saying "very close", do you mean that on the MathWorld page the font size is the same in the text as in the formulae?  That is true, but the formulae still become unreadable when magnified (and the whole point of magnification is to increase readability).

However, most maths pages are like Wikipedia, i.e. the font size in the images is much larger than normal text (so that subscripts, etc. stay readable).  In Fx 2 I have to increase the text size by two steps to get the same font size as in the formulae.
(In reply to comment #87)
> > (In reply to comment #84)
> > > http://en.wikipedia.org/wiki/Gram-Schmidt_process
> > > http://mathworld.wolfram.com/Gram-SchmidtOrthonormalization.html
> > 
> > Looking at these under my default setup here, the text in the images and in 
> > the page is very very close. If I wanted one magnified, I couldn't imagine not
> > magnifying the other. 
> 
> When saying "very close", do you mean that on the MathWorld page the font size
> is the same in the text as in the formulae?  That is true, but the formulae
> still become unreadable when magnified (and the whole point of magnification is
> to increase readability).

FWIW, IE7 scales those images rather nicely. From what I read in bug 381661 comment 10, it seems that we might get that better scaling too.
Thanks for your responses Roc, Dão.

(In reply to comment #83)
> > As for zooming images, indeed scaling only looks decent on certain values. So
> > it’s probably best if they would ‘snap’ to e.g. 0.5, 0.75, 1.0, 1.5, 2.0,
> > etc.
> 
> Yeah, it could be that the UI will have to do .25 steps. But I kind of hope
> that bug 381661 will be fixed for 1.9, which would render this unnecessary.

Well, even with bilinear filtering, snapping to certain values would still look better. For example, take a look at the following image:

http://www.grauw.nl/css/images/menubg.png

If you scale this by 150%, it looks fine. But if you scale this by 106%, you get an ugly moire effect. For photographic images, it is probably less of an issue.

Also, it would perhaps be good if a CSS pixel remains equal to a pixel (or a multiple thereof when the DPI gets very high). That way, lines will stay sharp. Anyway, guess I’ll just have to wait ’till Firefox 3 gets into beta and try it out myself before commenting any more :).
Dao, just a last minute comment about your locale changes, I have a couple of wording suggestions which I probably should have mentioned long ago:

Zoom -> Page Zoom
Increase -> Zoom In
Decrease -> Zoom Out

Because Zoom In and Zoom Out are much more related to the kind of zoom we are implementing rather than Increase or Decrease, which can also actually be ambiguous for page zoom.

Maybe you could also replace Normal with "Reset to 100%"? Normal is still OK but IMO "Reset to 100%" is more obvious.
Actually, forget about the Zoom -> Page Zoom suggestion, it won't look very good with "Page Style" right underneath it, causing two "Page"'s to align.
Attached patch locale changes v2 (obsolete) — Splinter Review
Hrm, okay.
Attachment #281170 - Attachment is obsolete: true
Attachment #282240 - Flags: ui-review?(beltzner)
Attachment #282240 - Flags: review?(mano)
Attachment #281170 - Flags: ui-review?(beltzner)
Attachment #281170 - Flags: review?(mano)
Flags: blocking-firefox3?
Wouldn't 50%,71%,100%,141%,200% be enough choise (roughly sqrt(2) steps)?
Does Joe Users need to go beyond 1/2 or double ?

We should at least use 50%, 75%, 100%, 150%, 200% to minimize rounding errors and image uglyness.
Attached patch Rest of the changes (obsolete) — Splinter Review
This is the non UI-facing changes, its basically replacing most instances of changing text zoom with changing full zoom. Mano, can you please quickly review the toolkit/ and browser/ part of the patch?

After you have I'll find someone to review the mouse scroll part in content/. (BTW, why is that in C++ content/ and not in JS browser/?)
Attachment #282987 - Flags: review?(mano)
Comment on attachment 282987 [details] [diff] [review]
Rest of the changes

Michael, I'm already working on this, and this patch won't help me, as I've already modified large amounts of code that you touch. (Except for the mouse wheel scroll bits in nsEventStateManager.cpp. Attaching this as a separate patch and asking for review might be actually useful.)
Attachment #282987 - Attachment is obsolete: true
Attachment #282987 - Flags: review?(mano)
Attached patch WIP (obsolete) — Splinter Review
Here's what I currently have. Untested and most certainly not yet working.
I guess I'm a bit too eager to see this get done :-) You're welcome to take my nsEventStateManager changes and incorporate it in your next patch.
Attached patch WIP 2 (obsolete) — Splinter Review
Attachment #282988 - Attachment is obsolete: true
Attachment #282240 - Attachment is obsolete: true
Attachment #282240 - Flags: ui-review?(beltzner)
Attachment #282240 - Flags: review?(mano)
Attached patch patch v1 (obsolete) — Splinter Review
All bugs that I know of should be fixed here. But I'm going to do more testing before I request review.
Attachment #274906 - Attachment is obsolete: true
Attachment #282990 - Attachment is obsolete: true
Flags: blocking-firefox3? → blocking-firefox3+
need this for b1
Target Milestone: --- → Firefox 3 M9
Attached patch patch v2 (obsolete) — Splinter Review
Attachment #283077 - Attachment is obsolete: true
Attachment #283274 - Flags: review?(mconnor)
Comment on attachment 283274 [details] [diff] [review]
patch v2

Jonas, could you please have a look at the content/events/ stuff?
Attachment #283274 - Flags: review?(jonas)
I'm not a good super-reviewer for this, I rarely do front-end stuff.
(In reply to comment #104)
> I'm not a good super-reviewer for this, I rarely do front-end stuff.
> 

Part of the patch involves changing content/ so mouse wheel uses full zoom instead of text zoom. Thats the only part you need to review. :-)
Attached patch patch v2.1 (obsolete) — Splinter Review
(no change in the front-end code here.)

Boris, please take a look at the nsEventStateManager modifications.
Attachment #283274 - Attachment is obsolete: true
Attachment #283533 - Flags: superreview?(bzbarsky)
Attachment #283533 - Flags: review?(mconnor)
Attachment #283274 - Flags: review?(mconnor)
Attachment #283274 - Flags: review?(jonas)
1)  I'm not actively doing reviews that someone else is able to do
2)  I'm not sure why we're making this change to all Gecko apps without any
    Gecko discussion that I've seen.

In particular, if some Gecko apps want it (which is something to determine), it might make sense to allow choice of either full zoom or text zoom, depending on what the embedding app wants.  Last I checked, this stuff was all pref-controlled anyway so you'd just be adding another value of the pref.  But that discussion should probably happen in a wider audience than just me, especially because I'm not even all that familiar with this code.
Attachment #283533 - Flags: superreview?(bzbarsky)
Whiteboard: [wanted-firefox3] → [has patch][need review mconnor]
Priority: -- → P1
Comment on attachment 283533 [details] [diff] [review]
patch v2.1


>Index: browser/base/content/browser.xul

>     </statusbarpanel>
>+    <statusbarpanel popup="statusbarpanel-fullZoom">

this needs to be fullZoomPanel to work.

>+      <label id="fullZoomLabel"/>
>+      <dropmarker/>
>+      <panel id="fullZoomPanel" position="after_start" orient="horizontal"
>+             onpopupshown="FullZoom.onPopupShown()"
>+             onpopupshowing="FullZoom.onPopupShowing()">
>+        <spacer flex="1"/>
>+        <stack>
>+          <slider id="fullZoomScaleShadow"
>+                  dir="reverse" orient="vertical"
>+                  curpos="100"
>+                  disabled="true"
>+                  class="scale-slider" flex="1">
>+            <thumb class="scale-thumb" disabled="true" orient="vertical"/>
>+          </slider>

What's this for?  I don't think this adds anything useful, but I'm offline and on a mac right now.

>Index: browser/themes/pinstripe/browser/browser.css

>+#fullZoomScale > .scale-slider {
>+  -moz-appearance: none;
>+}

This rule should die.  The -moz-appearance here is vastly better than the default thumb.

>Index: browser/themes/winstripe/browser/browser.css
>===================================================================
>RCS file: /cvsroot/mozilla/browser/themes/winstripe/browser/browser.css,v
>retrieving revision 1.106
>diff -u -8 -p -r1.106 browser.css
>--- browser/themes/winstripe/browser/browser.css	3 Oct 2007 03:21:09 -0000	1.106
>+++ browser/themes/winstripe/browser/browser.css	4 Oct 2007 09:28:18 -0000
>@@ -1884,8 +1884,28 @@ toolbarbutton.bookmark-item[dragover="tr
> 
> .bookmark-item[dragover-top="true"] {
>   -moz-border-top-colors: #000000;
> }
> 
> .bookmark-item[dragover-bottom="true"] {
>   -moz-border-bottom-colors: #000000;
> }
>+
>+/* Full Zoom UI */
>+#fullZoomLabel {
>+  -moz-margin-end: 0;
>+}
>+
>+#fullZoomLabel + dropmarker {
>+  -moz-appearance: none;
>+  border: 0;
>+  padding: 0;
>+  background: none;
>+}
>+
>+#fullZoomPanel {
>+  background-color: -moz-dialog;
>+}
>+
>+#fullZoomScale > .scale-slider {
>+  -moz-appearance: none;
>+}

screenshots please? (I need a new Windows machine)

general Q: why do we cap keyboard zoom at .5 and 2.5, and mousewheel zoom at much much higher levels?  mouse scroll gets into insane and unusable fairly quickly...
Attachment #283533 - Flags: review?(mconnor) → review-
(In reply to comment #109)
> (From update of attachment 283533 [details] [diff] [review])
> 
> >Index: browser/base/content/browser.xul
> 
> >     </statusbarpanel>
> >+    <statusbarpanel popup="statusbarpanel-fullZoom">
> 
> this needs to be fullZoomPanel to work.

Why? fullZoomPanel is the <panel> element.

> >+      <label id="fullZoomLabel"/>
> >+      <dropmarker/>
> >+      <panel id="fullZoomPanel" position="after_start" orient="horizontal"
> >+             onpopupshown="FullZoom.onPopupShown()"
> >+             onpopupshowing="FullZoom.onPopupShowing()">
> >+        <spacer flex="1"/>
> >+        <stack>
> >+          <slider id="fullZoomScaleShadow"
> >+                  dir="reverse" orient="vertical"
> >+                  curpos="100"
> >+                  disabled="true"
> >+                  class="scale-slider" flex="1">
> >+            <thumb class="scale-thumb" disabled="true" orient="vertical"/>
> >+          </slider>
> 
> What's this for?  I don't think this adds anything useful, but I'm offline and
> on a mac right now.

It's there to mark the "100" position (screenshot coming).

> >Index: browser/themes/pinstripe/browser/browser.css
> 
> >+#fullZoomScale > .scale-slider {
> >+  -moz-appearance: none;
> >+}
> 
> This rule should die.  The -moz-appearance here is vastly better than the
> default thumb.

The slider disappears without an appearance, which is what I want (it would be rendered over the "shadow" thumb otherwise, and there's still the "shadow" slider in the background). Should I use visibility:hidden instead?

> general Q: why do we cap keyboard zoom at .5 and 2.5, and mousewheel zoom at
> much much higher levels?  mouse scroll gets into insane and unusable fairly
> quickly...

There's a pref for .5 and 2.5, I didn't want to be too restrictive with hardcoded values.
Attached image screenshot
Depends on: 390696
> > >     </statusbarpanel>
> > >+    <statusbarpanel popup="statusbarpanel-fullZoom">
> > 
> > this needs to be fullZoomPanel to work.

> Why? fullZoomPanel is the <panel> element.

The docs say that "popup" is the ID of the <popup> (<panel> in this case) to display when the element (<statusbarpanel>) is clicked.
(In reply to comment #112)
> > > >     </statusbarpanel>
> > > >+    <statusbarpanel popup="statusbarpanel-fullZoom">
> 
> The docs say that "popup" is the ID of the <popup> (<panel> in this case) to
> display when the element (<statusbarpanel>) is clicked.

Oops, yes, looks like a typo. I wonder why the patch worked last time I tried it... Anyways, that should be id="statusbarpanel-fullZoom" popup="fullZoomPanel".
Attached patch patch v2.2 (obsolete) — Splinter Review
Attachment #283533 - Attachment is obsolete: true
Attachment #284823 - Flags: review?(mconnor)
Comment on attachment 284823 [details] [diff] [review]
patch v2.2

* the mousewheel vs. keyboard zoom is weird, both should cap at the same point.  If that means we need to have max/min zoom prefs that core uses as well, so be it.

* The slider seems simply broken on Mac.  Can we split that out of the patch, and implement the zoom separately for M10 (there's some question about whether we really want this, especially since this all breaks when you zoom past 250%)  Would rather get the s/text/page/ changes in, and figure out the slider in a second bug

other than that, looks good, can we cap full zoom at .5-3.0 as a range for both keyboard and mouse zoom via a pref, and get this ready to go tomorrow?
Attachment #284823 - Flags: review?(mconnor) → review-
Whiteboard: [has patch][need review mconnor] → [need new patch]
Could somebody please attach a screenshot from Mac? The extension attached to this bug (attachment 274906 [details]) can be used, no need to apply the patch.
Attached patch patch v2.3 (WIP) (obsolete) — Splinter Review
This would be the patch with consistent min/max values and a potential fix for OS X. That is, I haven't removed the slider yet.
Attachment #284823 - Attachment is obsolete: true
Severity: normal → enhancement
Attached patch patch v2.3 (obsolete) — Splinter Review
Attachment #285717 - Attachment is obsolete: true
Attachment #285730 - Flags: review?(mconnor)
Attached patch patch v2.4Splinter Review
fixed a bug in the destroy (shutdown) code.
Attachment #285730 - Attachment is obsolete: true
Attachment #285978 - Flags: review?(mconnor)
Attachment #285730 - Flags: review?(mconnor)
Attached patch patch v2.4 liteSplinter Review
In case there's still something wrong with the latest patch, here's a version without the statusbar panel. This patch is a straight subset, but currently untested!
Whiteboard: [need new patch] → [has patch][need review mconnor]
Comment on attachment 285979 [details] [diff] [review]
patch v2.4 lite

r=me, let's defer on the slider, there's a distinct lack of consensus as to whether its needed.

We also may want to revisit the steppings, but we'll make that call moving forward.
Attachment #285979 - Flags: review+
Whiteboard: [has patch][need review mconnor] → [has patch][has reviews]
Attachment #285978 - Flags: review?(mconnor)
Keywords: checkin-needed
What about comment 107?
It seems like this completely eliminates the possibility of using textZoom by changing a pref.
You need to get the content/ and mail/ changes reviewed. mconnor's review is only valid for the browser/ and toolkit/ parts of this patch.
Keywords: checkin-needed
Whiteboard: [has patch][has reviews] → [has patch][has review mconnor][needs review for content and mail]
Jonas Sicking reviewed content earlier, mail is kept up-to-date with the simplified access to ZoomManager.
Comment on attachment 285979 [details] [diff] [review]
patch v2.4 lite

r/sr=me on the mozilla/content parts
Attachment #285979 - Flags: review+
Keywords: checkin-needed
Whiteboard: [has patch][has review mconnor][needs review for content and mail] → [has patch][has review mconnor]
Checking in browser/base/content/browser-menubar.inc;
/cvsroot/mozilla/browser/base/content/browser-menubar.inc,v  <--  browser-menubar.inc
new revision: 1.118; previous revision: 1.117
done
Checking in browser/base/content/browser-sets.inc;
/cvsroot/mozilla/browser/base/content/browser-sets.inc,v  <--  browser-sets.inc
new revision: 1.104; previous revision: 1.103
done
Checking in browser/base/content/browser-textZoom.js;
/cvsroot/mozilla/browser/base/content/browser-textZoom.js,v  <--  browser-textZoom.js
new revision: 1.4; previous revision: 1.3
done
Checking in browser/base/content/browser.js;
/cvsroot/mozilla/browser/base/content/browser.js,v  <--  browser.js
new revision: 1.877; previous revision: 1.876
done
Checking in browser/locales/en-US/chrome/browser/browser.dtd;
/cvsroot/mozilla/browser/locales/en-US/chrome/browser/browser.dtd,v  <--  browser.dtd
new revision: 1.76; previous revision: 1.75
done
Checking in content/events/src/nsEventStateManager.cpp;
/cvsroot/mozilla/content/events/src/nsEventStateManager.cpp,v  <--  nsEventStateManager.cpp
new revision: 1.715; previous revision: 1.714
done
Checking in content/events/src/nsEventStateManager.h;
/cvsroot/mozilla/content/events/src/nsEventStateManager.h,v  <--  nsEventStateManager.h
new revision: 1.159; previous revision: 1.158
done
Checking in mail/base/content/mailWindowOverlay.xul;
/cvsroot/mozilla/mail/base/content/mailWindowOverlay.xul,v  <--  mailWindowOverlay.xul
new revision: 1.226; previous revision: 1.225
done
Checking in modules/libpref/src/init/all.js;
/cvsroot/mozilla/modules/libpref/src/init/all.js,v  <--  all.js
new revision: 3.697; previous revision: 3.696
done
Checking in toolkit/components/help/content/help.xul;
/cvsroot/mozilla/toolkit/components/help/content/help.xul,v  <--  help.xul
new revision: 1.37; previous revision: 1.36
done
Checking in toolkit/components/help/content/helpContextOverlay.xul;
/cvsroot/mozilla/toolkit/components/help/content/helpContextOverlay.xul,v  <--  helpContextOverlay.xul
new revision: 1.12; previous revision: 1.11
done
Checking in toolkit/components/viewsource/content/viewPartialSource.xul;
/cvsroot/mozilla/toolkit/components/viewsource/content/viewPartialSource.xul,v  <--  viewPartialSource.xul
new revision: 1.28; previous revision: 1.27
done
Checking in toolkit/components/viewsource/content/viewSource.xul;
/cvsroot/mozilla/toolkit/components/viewsource/content/viewSource.xul,v  <--  viewSource.xul
new revision: 1.35; previous revision: 1.34
done
Checking in toolkit/content/viewZoomOverlay.js;
/cvsroot/mozilla/toolkit/content/viewZoomOverlay.js,v  <--  viewZoomOverlay.js
new revision: 1.8; previous revision: 1.7
done
Checking in toolkit/locales/en-US/chrome/mozapps/help/help.dtd;
/cvsroot/mozilla/toolkit/locales/en-US/chrome/mozapps/help/help.dtd,v  <--  help.dtd
new revision: 1.8; previous revision: 1.7
done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [has patch][has review mconnor] → [has patch][has review mconnor/sicking]
Uh.  Guys?  Comment 107?  It really does need to be addressed.  There are
Gecko-based apps other than Firefox out there, last I checked.  Was there a
newsgroup discussion I completely missed somehow?  Or any other sort of public
anything?
(In reply to comment #122)
> What about comment 107?

I don't know what previously-existing preferences comment 107 was referring to. fullZoom is pretty new.

> It seems like this completely eliminates the possibility of using textZoom by
> changing a pref.

We're switching the primary zooming method from text~ to full~. That doesn't mean that no other application or extension is allowed to use textZoom, or that we couldn't switch back in case fullZoom isn't that great after all, or that ZoomManger couldn't evolve to support both. Please file appropriate new bugs.
> I don't know what previously-existing preferences comment 107 was referring
> to.

The preference for exactly what mousewheel does.  It can do zoom, but it can do other things as well.  Exactly what it does is controlled by a preference.  Note that this was the only part in "all Gecko apps" code, so I had assumed that this aspect of things was clear... sorry about that.

> That doesn't mean that no other application or extension is allowed to use
> textZoom,

As of the checkin of this patch it's impossible to do textZoom in response to a mousewheel event, unless I'm seriously misreading the patch.
As a simple example of the sort of thing this patch breaks, the relevant mousewheel option in Seamonkey preferences is labeled "Make the text larger or smaller".  Which is no longer what the behavior will be, with this patch.  Now maybe the Seamonkey developers want the full zoom behavior (and will just change the wording).  Or maybe they want text zoom.  They just no longer get a choice in what they get, with this patch.  And given the lack of public discussion, they probably also don't know that a core API that used to do one thing now does something totally different and that they need to worry about either changing their UI or something.
OK, let's move on with a new bug to add back support for MOUSE_SCROLL_TEXTSIZE (possibly with the old value, 3). If nobody did it, I will file that later, and I can write a patch too.
After using it, I'd like a few features, 

* View Page Info, should have your Page zoom settings
* Using the scroll wheel over the page zoom to change the settings.
* Add 110% option (I added this manually), going from %100->%125 seems a big step
Depends on: 401199
Depends on: 401203
where is this UI supposed to be visible ?
nothing with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007102522 Minefield/3.0a9pre ID:2007102522
(In reply to comment #133)
> where is this UI supposed to be visible ?
> nothing with
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007102522
> Minefield/3.0a9pre ID:2007102522
> 

The View menu. For now there is only as much UI for full zoom as there was for text zoom.
Depends on: 401214
<!ENTITY fullZoomReduceBtn.label        "Zoom In">
<!ENTITY fullZoomReduceBtn.accesskey    "I">
<!ENTITY fullZoomEnlargeBtn.label       "Zoom Out">
<!ENTITY fullZoomEnlargeBtn.accesskey   "O">

Is this really correct? I tend to think that "Zoom in" actually means enlarge, and "Zoom out" means reduce, but these buttons say the contrary. Is this a bug?
(In reply to comment #135)
Yes, thanks for catching that.
Blocks: 401219
Depends on: 401213
Depends on: 401220
No longer depends on: 390696
Keywords: relnote
Whiteboard: [has patch][has review mconnor/sicking]
Blocks: 401297
verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007103004 Minefield/3.0a9pre. Verified based on Comment 134, the Zoom UI is visible under the View menu.
Status: RESOLVED → VERIFIED
Depends on: 402548
Is the full page zoom useful in zooming parts of page like div/table/list ? 
Depends on: 402843
No longer depends on: 402843
Depends on: 401221
No longer depends on: 381661, 401199, 401203, 401213, 402548
imo, if someone uses Text Size option he/she doesn't cares about layout. He only need bigger text. Of course, if it is possible to zoom entire page without horizontal scrollbars for me there is no difference but now eg. bugzilla has scrollbars (1024x768) when i use 2x(ctrl +). With text size option problem does not exists.

Option "text size" can be enabled in about:config for advanced users but it SHOUT BE STILL available.
Maybe somebody can make an extension for text zoom only if a pref is too much. It was the first thing i was looking for when faced this new page zoom "feature".

It is quit silly to change things that works only because somebody screams louder than others.
(In reply to comment #18)
> A separate bug for Seamonkey would be appropriate; the UI implementation is
> likely to end up in browser/.  You might want to wait and see what the results
> of the discussion are here, though; there might be some suggestions you'll want
> to use.

Filed bug 405133.
Depends on: 405310
Depends on: 405374
Depends on: 409180
(In reply to comment #75)
> A global minimum font size combined with page zoom should satisfy most users,
> which is also what beltzner wrote. So I'm going to do that.

No, because the global minimum font size breaks a huge number of sites - particularly left & right menu colums.

From bug 401322: Reasons to make text zoom the default:

1. Why do we zoom? IMO, almost always (at a minimum >50%) to be able to better
read text that is too small.

2. Keep layout? HTML is designed to accommodate all kinds of resolutions,
monitor sizes, dpi settings, font-size settings, etc. Layout is for paper
output, not web sites. Web pages must "go with the flow" (in accordance with our font size preferences).

3. Do we need to see low-res images zoomed into a pixellated mess? Almost
never.

4. Full page zoom causes the dreaded horizontal scrolling. Very little could
justify that high price.

Conclusion: Text zoom is much more useful and should be the default.

People switching from IE can either change the setting to their habitual (but
inferior) behavior, or rejoice in the more useful default setting (text zoom).

Ps. I read a *lot* of comments here, so apologies if I repeated some.
I'd like to join the debate, and hope that's fine.

I like full page zoom much better, and have been waiting for it for a while. That may be partly because I'm a graphic artist, though. On a side note, the fact images don't zoom in very nicely (aka pixelated mess) at the moment isn't a good argument against full page zoom, IMO, as filtering them nicely is a planned feature that's supposed to be implemented later on (if I'm not mistaken... because I can't find the bug # right now).

Whatever devs end up choosing, keep in mind all the opinions here, although they should be taken in consideration, do not properly represent the opinion of the majority of the Firefox users.
To sum things up simply, what I mean is that when replacing text zoom by full page zoom, those in favor of text zoom will all react, while those who like full page zoom better are much more likely to stay quiet, because they already have what they want.

Anyway, I'm in favor of adding back text zoom, considering the amount of people who like this feature, but as I implied above, I'd still like full page zoom to be the default (+ it's the default in IE and Opera). Or add an extra new shortcut for text zoom...
My proposal (well, kinda repetition of my previous one): When the page zoom UI was implemented, the "Text Size" item of the "View" menu disappeared, and a new one, "Zoom" appeared in its place. Why not just put back "Text Size" next to "Zoom"? I find it quite clear: "Text Size: Increase/Decrease/Normal" and "Zoom: Zoom In/Zoom Out/Reset". This should work (unless I missed a change in the XUL specification limiting the number of items in a menu to 9/4 of the menu's name :-).
(In reply to comment #143)
> On a side note, the
> fact images don't zoom in very nicely (aka pixelated mess) at the moment isn't
> a good argument against full page zoom, IMO, as filtering them nicely is a
> planned feature that's supposed to be implemented later on (if I'm not
> mistaken... because I can't find the bug # right now).

bug 381661
Won't you let user to define how big a zoom step would be? like 50%, 60%, 70%, 75%, 80%, 90%, 100%, 110%, 115%, 125%, 130% etc. This will make firefox zooming more charming and smoothing.

Thanks,
(In reply to comment #146)
> Won't you let user to define how big a zoom step would be? like 50%, 60%, 70%,
> 75%, 80%, 90%, 100%, 110%, 115%, 125%, 130% etc. This will make firefox zooming
> more charming and smoothing.
> 
> Thanks,
> 

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