Closed
Bug 592147
Opened 14 years ago
Closed 12 years ago
Add zoom controls to the Firefox menu
Categories
(Firefox :: Menus, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: faaborg, Assigned: rogerio.rag)
References
Details
Attachments
(6 files, 2 obsolete files)
237.72 KB,
image/png
|
Details | |
29.94 KB,
image/png
|
Details | |
125.61 KB,
image/png
|
Details | |
5.94 KB,
patch
|
Gavin
:
review-
|
Details | Diff | Splinter Review |
3.10 MB,
video/ogg
|
limi
:
ui-review-
|
Details |
307.44 KB,
image/png
|
Details |
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.
Reporter | ||
Comment 1•14 years ago
|
||
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%>
Comment 3•14 years ago
|
||
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.
Comment 4•14 years ago
|
||
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?
Comment 6•14 years ago
|
||
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).
Comment 7•14 years ago
|
||
(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.
Reporter | ||
Comment 8•14 years ago
|
||
>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.
Reporter | ||
Comment 10•14 years ago
|
||
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.
Comment 11•14 years 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.
Comment 12•14 years ago
|
||
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
Comment 13•14 years ago
|
||
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.
Comment 14•14 years ago
|
||
If we want to use a slider, the slider should be fixed first. bug 590453
Depends on: 590453
Comment 15•14 years ago
|
||
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 16•14 years ago
|
||
Reporter | ||
Comment 17•14 years ago
|
||
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+
Reporter | ||
Comment 18•14 years ago
|
||
>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.
Updated•14 years ago
|
Attachment #477950 -
Flags: review?(gavin.sharp)
Comment 19•14 years ago
|
||
(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.
Comment 20•14 years ago
|
||
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
Comment 21•14 years ago
|
||
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.
Comment 22•14 years ago
|
||
(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.
Comment 23•14 years ago
|
||
(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
Comment 24•14 years ago
|
||
Any chance to see it in the Firefox 4 final?
Comment 25•14 years ago
|
||
(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.
Comment 26•14 years ago
|
||
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.
Comment 27•14 years ago
|
||
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.
Comment 28•14 years ago
|
||
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.
Comment 29•14 years ago
|
||
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.
Comment 30•13 years ago
|
||
Could someone push this to UX branch please?
Comment 31•13 years ago
|
||
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-
Comment 32•13 years ago
|
||
(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)
Comment 33•13 years ago
|
||
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 34•13 years ago
|
||
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.
Comment 35•13 years ago
|
||
Any news on this one?
Comment 36•13 years ago
|
||
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.
Comment 37•13 years ago
|
||
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 38•13 years ago
|
||
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.
Comment 39•13 years ago
|
||
(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.
Comment 40•13 years ago
|
||
(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.
Comment 41•13 years ago
|
||
Are there somebody working on this? Can I continue the work? Jesper and Michael, do you mind?
Comment 42•13 years ago
|
||
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.
Comment 43•13 years ago
|
||
Yeah, I'm working on something else, so someone else can take this up.
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → rogerio.rag
Assignee | ||
Comment 44•13 years ago
|
||
Attachment #588926 -
Flags: review?
Assignee | ||
Comment 45•13 years ago
|
||
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.
Assignee | ||
Comment 46•13 years ago
|
||
(In reply to Rogério Gonçalves from comment #45)
I forgot to say that I'm working with Marcos Silvano in this bug.
Comment 47•13 years ago
|
||
Probably you should ask for feedback/ui-review from UX-team (maybe limi or shorlander)...
Assignee | ||
Comment 48•13 years ago
|
||
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)
Comment 49•13 years ago
|
||
The toolbar button is overkill. We already provide zoom in/out buttons in the toolbar customization palette.
Comment 50•13 years ago
|
||
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?
Assignee | ||
Comment 51•13 years ago
|
||
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.
Comment 52•13 years ago
|
||
(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.
Comment 53•13 years ago
|
||
Displaying the zoom level in the button or a tooltip will serve the purpose.
Comment 54•13 years ago
|
||
A long click (like the back button has) on the zoom in/out buttons could also serve for zoom level reset.
Comment 55•13 years ago
|
||
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 56•13 years ago
|
||
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)
Comment 57•13 years ago
|
||
Comment 58•13 years ago
|
||
How is that supposed to work interactively? Is the menu supposed to stay open while you click +/- multiple times?
Comment 59•13 years ago
|
||
(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).
Comment 60•12 years ago
|
||
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: 12 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•