Add zoom controls to the Firefox menu

RESOLVED WONTFIX

Status

()

defect
RESOLVED WONTFIX
9 years ago
6 years ago

People

(Reporter: faaborg, Assigned: rogerio.rag)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments, 2 obsolete attachments)

The Firefox menu currently does not contain zoom controls.  We believe the previous usage data on them was low because user's either didn't discover the capability, or they found individual menu commands for adjusting each zoom level to be overly cumbersome.

To correct both of these problems simultaneously, we would like to surface control over page zoom directly in the Firefox menu, and using a xul slider.
This slider should use discrete steps, so that it is easier for the user to return to 100%.  We could place 100% at around 1/3, to provide a few steps of zooming out, or we could place it in the center for balance.
(In reply to comment #1)
> return to 100%.  We could place 100% at around 1/3, to provide a few steps of

Have a 100% button, at end of scroll bar

Zoom ----||------ <100%>
Unlike our Competitors, Fx provides an "Zoom Text only" Setting in the old Menu.
Will that Setting be covered in the new Button Menu?
The Menu Item in the old Menu is the only Place in the UI to set it.
I think it will be good if that feature is present in the Firefox Menu. Primary reason, only Firefox has this feature.
Again, as with the edit tray, the mockups look good in English, but they may break for some locales. I know in Portuguese it's "mudar tamanho", since there is no direct translation to the word "zoom". How will that work out?
Just show the percentage. The zoom control is special because it is *both* a control and a *status indicator*. It's bad enough having the zoom control hidden away in a menu (rather than on the status bar where it belongs), but requiring an extra mouse-over just to see a tooltip to show the current zoom level is even worse!!

In standard CAD/drawing/office applications the zoom control almost never says "zoom" - it usually just shows the zoom level and + and - controls on either side of the slider. It's also usually located in the bottom-right of the screen right beside the full-screen control (e.g. in MS Visio).
(In reply to comment #3)
> Unlike our Competitors, Fx provides an "Zoom Text only" Setting in the old
> Menu.
> Will that Setting be covered in the new Button Menu?
> The Menu Item in the old Menu is the only Place in the UI to set it.

I think it will clutter-up any menu and is better placed in the main options menu.
>Again, as with the edit tray, the mockups look good in English, but they may
>break for some locales. I know in Portuguese it's "mudar tamanho", since there
>is no direct translation to the word "zoom". How will that work out?

Always a difficult problem, options would include trying to find a shorter word that still works (size?), or ending up with a wider firefox menu.  I've still been meaning to check out what happens to the Firefox menu in german, it's not that we don't have plenty of screen space, but it might end up looking rather wide.
(In reply to comment #5)
> Again, as with the edit tray, the mockups look good in English, but they may
> break for some locales. I know in Portuguese it's "mudar tamanho", since there
> is no direct translation to the word "zoom". How will that work out?

why cant we use "Zoom" itself 
According to http://www.merriam-webster.com/dictionary/zoom
first known use is 1903, so it is now really an original English word, 
but somebody coined it in recent past. 
Additionally it looks like http://www.answers.com/topic/zoom is giving small words in most languages.
Sorry, I meant in certain languages the person doing the localization has the options of replacing the word or having a wider menu.  We would still use zoom for en-us / en-gb

People localizing Firefox always have the option to substitute terms if they feel it makes sense.  For instance, sometime a term is replaced with another term in software for a certain locale because there is more descriptive concept, or everyone is being consistent with what someone selected in a product a long time ago.
I think it would help to have additional buttons for non gradual adjustments.
Take a look at Photoshop as an example. You can zoom from 50%, then 75,100,150,200,300,400,800. This is for zooming images, so i think for web browsing, 50%,75,90,115,130,150 might be more appropriate.
And we need to include a way to reset the zoom level. Maybe snap the slider to preset levels, like 50%, 75% and so on. In fact, I'm pretty sure there's an about:config line for this, but I'm not really sure about what it does. I know mine is user set, because I've messed with it in the past :P
Blocks: 595105
No longer blocks: 595105
This may be hard to do because AFAICT our slider widget can't have variable increments. The pref which controls zoom values is toolkit.zoomManager.zoomValues.
If we want to use a slider, the slider should be fixed first. bug 590453
Depends on: 590453
Posted patch patch (obsolete) — Splinter Review
I have created a patch for this bug. How does it look?

I am not sure exactly where the tooltip should be. Under the slider as a whole, or under the slider's handle? The latter could be tricky as it doesn't seem to be possible to get the handle's position on the screen.

Right now the tooltip's top left corner is aligned with the slider's bottom left corner, although it seems there is some space between the two.
Attachment #477950 - Flags: ui-review?(faaborg)
Comment on attachment 477950 [details] [diff] [review]
patch

Looks good, let's land this to get a better feel for it, and we might want to make some changes in follow up bugs.
Attachment #477950 - Flags: ui-review?(faaborg) → ui-review+
>I am not sure exactly where the tooltip should be.

Ideally it would track with the slider, but I'm not sure if that possible.
Attachment #477950 - Flags: review?(gavin.sharp)
(In reply to comment #18)
> >I am not sure exactly where the tooltip should be.
> 
> Ideally it would track with the slider, but I'm not sure if that possible.

I could try to calculate its position based on assumptions about how the UI control looks, but there is no way of knowing if those assumptions hold on every platform.

Also another oddity I found: If you focus the slider and then close the Firefox button menu without putting focus somewhere else, the slider is still focused and can be shifted using the arrow keys. Also nothing in the Firefox button menu is keyboard accessible.
As previously stated, I think that hiding the zoom control in a menu does not provide the best user experience - the zoom status is not instantly relayed to the user and it is still awkward to adjust the zoom setting.

I've noticed that in beta7pre nightly builds that new zoom toolbar icons have appeared. However, these toolbar icons don't really give the main benefit of having the zoom controls on the toolbar - that is they don't show the % zoom level status. Opera's toolbar zoom controls are much better in this respect.

I've therefore created a new detailed article on the wiki outlining some toolbar design proposals. I have attached two such proposals here, but more can be found on the wiki page at:
https://wiki.mozilla.org/User:Broccauley/Visible_Zoom_and_Sync_Status_Without_the_Status_Bar
I definitely think the zoom level should be more easily seen, I have seen cases where the browser has either been slightly zoomed and forgot to be reset or even accidentally changed (via ctrl).. It's possible for a page to be zoomed or shrunk by a small amount and the average user might not realize it. Since the zoom level is retained after browser close this is a problem.
(In reply to comment #20)

The proposal is very nice. I would support something like this located on the toolbar. I think the one that Internet explorer 8 has a pretty good zooming function. I think it should be copied from that, but instead of located in the status bar, it should be located in the toolbar.
(From bug 610919 comment 6) 

When this patch is completed, we should also add a menuseparator after "Full Screen", to create more logical grouping in the Firefox menu. It should look like this:

Web Developer
--------------
Zoom [slider control]
Full Screen
--------------
Sync Now
Exit
Any chance to see it in the Firefox 4 final?
(In reply to comment #24)
> Any chance to see it in the Firefox 4 final?

I hope so, with the current Firefox menu there is not even an option for zoom, so if a page is zoomed by ctrl-scroll, whether it be accidental or not there is no way to see the zoom level or reset the zoom level without already knowing the keyboard shortcut before hand, which most average users do not. Seems counter productive to have to open the old menu bar for such a common task.
If this is not finished in time for Firefox 4, perhaps the old zoom menu from the menubar view menu, should be copied into the Firefox button.
What about implementing this in the firefox menu? It's a basic function that users expect in a browser...Not nobody knows the keyboard shortcuts.
Alex Faaborg:
Since it is a long time since I posted the patch, do you know if I did anything wrong? Did I pick the wrong person to ask review from? I picked the email address from the hg logs of the files I changed.
You didn't do anything wrong, I've just been focusing on other work and failed to be responsive - sorry about that. I'll get to it soon.
Could someone push this to UX branch please?
Comment on attachment 477950 [details] [diff] [review]
patch

I apologize for the ridiculous delay in getting to this review request - I will be much more responsive to future requests.

I don't think you need to mirror ZoomManager properties on the FullZoom object, you can just access ZoomManager directly.

You should probably add a appMenuPopupShowing() function rather than adding a bunch of stuff to the onpopupshowing attribute.

I don't know whether it makes sense to try to localize the tooltip label. Probably not. Either way it seems like extra complexity that would be nice to avoid - can't updateUI just set tooltiptext on the menu item?
Attachment #477950 - Flags: review?(gavin.sharp) → review-
Posted patch patch v2 (obsolete) — Splinter Review
(In reply to comment #31)
> Either way it seems like extra complexity that would be nice
> to avoid - can't updateUI just set tooltiptext on the menu item?

I cannot find a way to make the tooltip show as described in the mockup when doing that. It hides as soon as I move the mouse.
Attachment #477950 - Attachment is obsolete: true
Attachment #542397 - Flags: review?(gavin.sharp)
Gavin, are you able to review this patch anytime soon?

(In reply to comment #31)
> Either way it seems like extra complexity that would be nice
> to avoid - can't updateUI just set tooltiptext on the menu item?

tooltipText only sets what appears when the mouse hovers and stays still over the element for a short while; the standard tooltip condition.
Comment on attachment 542397 [details] [diff] [review]
patch v2

>diff --git a/browser/base/content/browser-appmenu.inc b/browser/base/content/browser-appmenu.inc

>+        <scale id="appmenu-zoom"
>+               onchange="ZoomLevelAppmenuScale.change();"
>+               onmousedown="ZoomLevelAppmenuScale.focus();"
>+               onmouseup="ZoomLevelAppmenuScale.blur();"/>

These function names should match the event name (focus and blur are confusingly different events entirely).

>diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js

>+var ZoomLevelAppmenuScale = {
>+  updateUI: function()

>+    this._scale.pageIncrement = 1;

This can just be specified using "pageincrement=1" on the appmenu-zoom element.

>+    this._tip.label = Math.round(ZoomManager.zoom*100) + "%";

I wonder whether you can do something like:
  var thumb = document.getAnonymousElementByAttribute(this._scale, "class", "scale-thumb");
  this._tip.openPopup(thumb, "after_start", 0, 0, false, false);
here to have the tooltip track the thumb, rather than staying in the same place.

Don't have easy access to a windows machine at the moment, will look at this again when I do.
Any news on this one?
I haven't looked at the last review comments yet, as I have since found another bug to work on, which is more interesting to me. I might get a new patch up within the next week, but anyone else feel free to pick this bug up.
Posted patch Patch 3Splinter Review
I hope you don't mind, Jesper, I'd like to finish this off and check it in soon.

This addresses the comments and fixes a focus bug, where you can change the zoom level using arrow keys if the slider is focussed when the window is closed.
Attachment #542397 - Attachment is obsolete: true
Attachment #558421 - Flags: review?(gavin.sharp)
Attachment #542397 - Flags: review?(gavin.sharp)
Comment on attachment 558421 [details] [diff] [review]
Patch 3

> <menupopup id="appmenu-popup"
>-           onpopupshowing="if (event.target == this) {
>-                             updateEditUIVisibility();
>-#ifdef MOZ_SERVICES_SYNC
>-                             gSyncUI.updateUI();
>-#endif
>-                             return;
>-                           }
>-                           if (event.target.parentNode.parentNode.parentNode.parentNode == this)
>-                             this._currentPopup = event.target;">
>+           onpopupshowing="appMenuPopupShowing(this, event);"

>+function appMenuPopupShowing(appMenuPopup, event) {
>+  if (event.target == appMenuPopup) {
>+    updateEditUIVisibility();
>+    ZoomLevelAppmenuScale.updateUI();
>+#ifdef MOZ_SERVICES_SYNC
>+    gSyncUI.updateUI();
>+#endif
>+    return;
>+  }
>+  if (event.target.parentNode.parentNode.parentNode.parentNode == appMenuPopup)
>+    appMenuPopup._currentPopup = event.target;
>+}

This code changed since last September. There's no need to add this function now.
(In reply to Dão Gottwald [:dao] from comment #38)
> This code changed since last September. There's no need to add this function
> now.

Really? What was it replaced with? I took a quick look through the code and I don't see anything else that would ensure the Edit and Sync UIs remain up to date when the app menu is opened.
(In reply to Michael Ventnor from comment #39)
> (In reply to Dão Gottwald [:dao] from comment #38)
> > This code changed since last September. There's no need to add this function
> > now.
> 
> Really? What was it replaced with? I took a quick look through the code and
> I don't see anything else that would ensure the Edit and Sync UIs remain up
> to date when the app menu is opened.

What I was saying is that there's no need to introduce appMenuPopupShowing, as this code isn't as disastrously formatted as it used to be. Just add the line that you need to add.
Are there somebody working on this? Can I continue the work? Jesper and Michael, do you mind?
I am not working on it, and since the last comment is more than a month old, I think you can safely assume that no one else is. Please update the patch, if you want.
Yeah, I'm working on something else, so someone else can take this up.
Assignee: nobody → rogerio.rag
Posted video Zoom control button.
Attachment #588926 - Flags: review?
I did some modifications on the zoom control. I've maintained the Michael Ventnor implementation with the Slider on the Firefox Button. I also created the control directly on the toolbar, as suggested by broccauley.

Now we have three options:
1. keep only the slider in firefox button.
2. keep only the zoom button and pop-up at toolbar.
3. keep both controls.

I would like the ask for your opinion about this.

I've attached a video demonstrating the zoom controls.

I had some problems with the slider XUL component: I couldn't change its appearance, so the background is still not transparent.
(In reply to Rogério Gonçalves from comment #45)
I forgot to say that I'm working with Marcos Silvano in this bug.
Probably you should ask for feedback/ui-review from UX-team (maybe limi or shorlander)...
Comment on attachment 588926 [details]
Zoom control button.

We are working in this bug which is asking for a new feature about zoom controls. We send an attachment with a preview of the modification. Please read the last comments. Could you take a look at it please? 

https://bugzilla.mozilla.org/attachment.cgi?id=588926
Attachment #588926 - Flags: ui-review?
Attachment #588926 - Flags: review?
Attachment #588926 - Flags: feedback?(shorlander)
Attachment #588926 - Flags: feedback?(limi)
The toolbar button is overkill. We already provide zoom in/out buttons in the toolbar customization palette.
The problem with the in/out buttons in the toolbar customization palette is that there is no way to reset zoom level without going to the menu / Ctrl + 0.

Shouldn' the slider have a 100% zoom level mark btw?
Dão, the current zoom in/out buttons in the toolbar customization palette don't show the zoom level and don't allow to reset the zoom to 100%.

Heraldo, the current slider component (xul:scale) doesn't have this feature. According to the Bug 349545 "Provide ticks for xul:scale widget" (https://bugzilla.mozilla.org/show_bug.cgi?id=349545), it will have improvements and perhaps will be possible to set a mark at 100% zoom level. When this have happened, I will improve the zoom controls.
(In reply to Rogério Gonçalves from comment #51)
> Dão, the current zoom in/out buttons in the toolbar customization palette
> don't show the zoom level and don't allow to reset the zoom to 100%.

Sure, but in/out is ptobably what most users need. What you're proposing seems unnecessarily complex for those users. We can't provide built-in toolbar buttons for every function some users might want to use. It's a tradeoff.
Displaying the zoom level in the button or a tooltip will serve the purpose.
A long click (like the back button has) on the zoom in/out buttons could also serve for zoom level reset.
Comment on attachment 558421 [details] [diff] [review]
Patch 3

This looks good, assuming UX signs off on the general idea. Some theme tweaks are needed for gnomestripe, though - the menu item seems too tall, and the slider's background doesn't match the rest of the menu (as seen in the screencast posted by Rogério).

On Windows, the "make the tooltip follow the thumb" behavior doesn't quite work - the thumb moves once or twice and then otherwise seems to stay stationary as I drag back and forth. It's also a little odd that there's no indication of the initial zoom level until you drag the slider, but maybe that's OK - adding text there could look too "busy", I guess.
Attachment #558421 - Flags: review?(gavin.sharp) → review-
Comment on attachment 588926 [details]
Zoom control button.

Overall, this is too error-prone and complicated, and the slider just makes it more complicated to use.

There's a variation of this included in the Australis menu, so I'm assigning this to Stephen Horlander for feedback and clearing the review flags for now. I'll attach a mockup of the menu from that design, I'm sure tweaking this one to match that behavior shouldn't be very hard — looks like you have most of the functionality nailed — thanks for implementing this!

Stephen should be able to help you get this to a state where it's in line with the new designs. I'm pretty sure it can be landed in that same state even in the current menu style, as well as the future design.
Attachment #588926 - Flags: ui-review?
Attachment #588926 - Flags: ui-review-
Attachment #588926 - Flags: feedback?(shorlander)
Attachment #588926 - Flags: feedback?(limi)
How is that supposed to work interactively? Is the menu supposed to stay open while you click +/- multiple times?
(In reply to Alex Limi (:limi) — Firefox UX Team from comment #57)
> Created attachment 596195 [details]
> Example of how the zoom control looks like in the Australis design

Just a comment on this : the + and - button should be inverted since it makes more sense to zoom with the button on the right (as Chrome).
The Firefox button is going to be removed in bug 863753. The new menu button in development already contains zoom controls.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.