Open Bug 232919 Opened 21 years ago Updated 2 years ago

implement zoom to best size (OS X maximize)

Categories

(Core :: Widget: Cocoa, enhancement, P3)

Product:
Core
Component:
Widget: Cocoa
Platform:
All
macOS
Type:
enhancement

Tracking

()

Status:
REOPENED

People

(Reporter: asa, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Whiteboard: [safari parity][tpi:+]) 

Mike tells me that this will be implemented differently for SeaMonkey and for
Camino (which already has bug 155956 for this issue) so please do not dupe this
bug against any Camino bugs. 

MacOS applications should support "zoom to best size" which expands the window
only as much as is required by the window's contents. In SeaMonkey, we currently
do something much closer to Windows' "maximize" feature where we just blast the
window out to fill all the available space (minus 10% or something like that on
the right side).

I'm told that Gecko already has some support for this, that it can already tell
us how big the window needs to be to accommodate the content. Mike may be able
to elaborate further. 

Once we support this in SeaMonkey, we should change the default first window
launched to be zoomed like Safari.
Assignee: jag → sfraser_bugs
Component: XP Toolkit/Widgets → Widget: Mac
QA Contact: jrgmorrison
Summary: implement zoom to best size for SeaMonkey (macOS maximize) → implement zoom to best size (OS X maximize)
*** Bug 276586 has been marked as a duplicate of this bug. ***
*** Bug 303210 has been marked as a duplicate of this bug. ***
What's the status of this bug? Is there any chance that this will work before the next major firefox version after 1.5? 
Are you ever going to fix the green zoom-button?
*** Bug 358151 has been marked as a duplicate of this bug. ***
*** Bug 361208 has been marked as a duplicate of this bug. ***
Could we please either resize it to "best size" or at least properly to fullscreen (which does not work properly at the moment - bug 361208 - and leaves this annoying 10% border on wide-screen monitors)?
Assignee: sfraser_bugs → joshmoz
Component: Widget: Mac → Widget: Cocoa
QA Contact: cocoa
MacOS applications should support "zoom to best size" which expands the window
only as much as is required by the window's contents. Not the full screen but the best size. As this bug is already 3 years in the queue, maybe there is a chance to get result soon?
Assignee: joshmoz → nobody
It is already 2.0.0.8 and this is still open bug. Anybody to take it and fix it?
It won't be part of any Firefox 2.0.0.x release. Cocoa support was added for Firefox 3. That's why it will at least be part of Firefox 3 if anyone accept to work on that bug.
Hardware: Macintosh → All
Unlike in Windows, OS X can only resize windows by mouse at bottom right corner and green button is used quite frequently when the user encounters a large page (when I use Safari).

Lacking this feature makes internet experience of Firefox in Mac extremely bad.
This seems to be fixed in Firefox 3 beta 5.
No, it isn't fixed, it even got worse. In 2.x the green buttom at least didn't maximize the window to the full screen width, it left some room on the right hand, so you could at least get at your drive icons on the desktop (and on any recent screen the window is then still wider than any webpage requires). In 3b5 this was "fixed" by maximizing unconditionally to the full height and width of the screen!

There's been much praise over 3.x being more platform-specific and in many cosmetic things this is true. But there's not only "look", there's also "feel" and Firefox feels totally out of place when you click the green button. On the Mac you don't want to "maximize" windows, you want to have windows that get just large enough to display the window's contents without having to scroll, and not larger. This sucks without end, especially if you have a large (or wide) screen. Who has any use for a 1920 pixel wide browser window? This is madness.

How old is this bug and how many duplicates has it? It was there in 1.x, in 2.x and now in 3.x it got even worse. Is there any hope that this will ever be fixed? This bug is the main reason I use Safari for much of my day-to-day browsing. I *hate* to read text with lines 250 characters long as much as I hate horizontal scrolling and other than Safari (which does the right thing when you click the green button) Firefox just has nothing to offer here.
It's definitely not 'zoom to best size', although I prefer the present state of things to that. It can't be too difficult to zoom to the smallest dimensions avoiding scroll-bars when possible (and to leave some option in about:config for windows-style maximization, since it may often be preferred)?
Present state of things is actually not meeting Apple interface guidelines and is ultimately inconvenient. 
This is a pretty major usability and conformance shortcoming. If the similar feature on Windows was broken, I'd wager that it would be a top priority. I realize it's not equivalent in several ways, but it really is a shame to have this brokeness when so much else is finally getting "good enough" on Mac. 

3.1 drivers, I know it's late in the cycle, but please consider making this a priority.
Flags: blocking1.9.1?
As far as implementation of this feature goes, Safari deals with completely-liquid-layouts that can be resized down to 0 dimensions by making the minimum width and height of the viewport be 600x800. I've made a bookmarklet that I use that reproduces Safari's functionality exactly:

javascript:zoomWindow = function(){ window.resizeTo(480,10000); window.resizeTo(Math.max(800,document.documentElement.scrollWidth+20), Math.max(600,document.documentElement.scrollHeight + window.outerHeight - window.innerHeight)) }; void(zoomWindow());
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Thanks for the bookmarklet, lowbatteries.  Now if only it'd work with Ubiquity.

I am in favor of Lars' about:config setting proposal for the next possible FF release, and would like to add the use of the shift key as a toggle.  I've read somewhere that this is how Camino behaves.
My bookmarklet isn't perfect and fails on some sites (I've spent absolutely no time researching why or how to fix it, though).

I'm of the opinion that settings are a designer's crutch, this definitely needs to be default per Apple's HIG (even if they don't follow them all the time).

As for the shift key toggle - this is a good idea and I can confirm this is how Camino works.
One especially bad scenario on Mac happens when the display size changes.  For example, I have my MBP hooked up to an external 24" display (1920x1280) at work and when I go home I unplug it and sleep the machine, which resizes the display area to its native 1440x900.  If I have Firefox maximized before I unplug the screen the window is the larger size and the zoom button doesn't resize to the current 'viewport' (it won't shrink?) and the resize widget is offscreen so there's no way to make the window smaller, even manually.  The only workaround that I've found is to have an Internet connection and use SessionSaver to quit/restore the current tabset; upon re-launch the windows are correctly sized.
Bill, the part where the window doesn't resize to fit within the new screen size when the old screen disappears sounds like a separate bug (at a glance, I don't see anything already filed in Widget:Cocoa currently that looks like that bug); I believe other apps do that correctly, though I can't test atm.
And a quick and nice workaround is to hit the green '+' button again. It will resize the window to the current screen settings. Bill, how does Safari or other native apps behave?
Smokey: of the apps I've got handy only Safari actually resizes correctly its content windows and it doesn't manage to center those on the screen (half hanging off)  So, Firefox does no worse than most other apps.  I can file a bug but it's not too high a hurdle to click the green light.

Henrick:  yeah, that's quite obvious in retrospect, isn't it?  I just switched to the 'graphite' look on this account and I think I confused myself... nevermind!

lowbatteries' bookmarklet works in this case too.
Flags: wanted1.9.1+ → wanted1.9.1-
I prefer what Firefox does. Many Mac apps (iTunes is notorious) "wrong-size" esp. after display resolution change. My yuiconf keynote yesterday was hampered at first by Firefox zooming only in the vertical to the new display dimension, not to the horizontal limit -- it was over-wide and that left slide contents clipped on the right.

But what iTunes did was insane -- it downsized for the lower display res., then the maximize button would only minify it to its little wannabe-cdplayer window state. No way except dragging to get it back to the right size for the higher resolution, and it downsized too much for the lower res too (but I wasn't showing iTunes in my talk :-P).

I hope this bug doesn't get fixed in a way that breaks the "maximize per display resolution" use-case.

/be
(In reply to comment #21)
> As far as implementation of this feature goes, Safari deals with
> completely-liquid-layouts that can be resized down to 0 dimensions by making
> the minimum width and height of the viewport be 600x800. I've made a
> bookmarklet that I use that reproduces Safari's functionality exactly:
> 
> javascript:zoomWindow = function(){ window.resizeTo(480,10000);
> window.resizeTo(Math.max(800,document.documentElement.scrollWidth+20),
> Math.max(600,document.documentElement.scrollHeight + window.outerHeight -
> window.innerHeight)) }; void(zoomWindow());

Could you please update this to work with Firefox 3.5.4?  I just came up with an idea for a workaround that would use a keyboard command for Firefox via keyconfig and everything else via Quicksilver trigger (that would exclude Firefox).
(In reply to comment #32)

As I said, I spent absolutely no time making sure that bookmarklet was foolproof. It's been a while since I used Firefox (partly because of this bug), but the bookmarklet seems to work on 3.5.4 for me.
(In reply to comment #33)
> (In reply to comment #32)
> 
> As I said, I spent absolutely no time making sure that bookmarklet was
> foolproof. It's been a while since I used Firefox (partly because of this bug),
> but the bookmarklet seems to work on 3.5.4 for me.

You're right.  I guess some how "move or resize existing windows" became unchecked.
I don't think there's any specific defined behavior for this green button. Apple themselves seems to do different things with it.

Let's look at some Apple applications:

- Terminal: Green button maximizes the terminal window to completely fill the screen.
- Aperture: Green button maximizes the terminal window to completely fill the screen.
- iCal: Green button maximizes the terminal window to completely fill the screen.
- Finder: Green button increases window size so no scrollbars show
- Safari: Green button increases window size so no scrollbars show
- iTunes: (Option-click since regular click converts it into mini-player) Green button maximizes the terminal window to completely fill the screen.
- iPhoto: Green button maximizes the terminal window to completely fill the screen.
- TextEdit: Green button maximizes the terminal window to completely fill the screen.

I personally think the green button should make Firefox fill the entire screen. I use the button when I drag Firefox to a secondary display and want it to fit the entire screen. This is the behavior on other platforms, so I think it should be how it behaves on OS X too. Firefox is cross-platform, and even Apple mostly uses the green button for maximize.
Is there any story behind why this was set to maximize instead of zoom?  Surely, there was some reasoning behind it at the time.

Camino and Firefox are the only major browsers on the OS X platform that maximize instead of zooming.  For an application that deals with documents averaging widths less than the width of the screen, I believe it makes far more sense to adhere to the zoom behavior outlined in Apple's HIG.
I propose that since many of us disagree on this subject, that we simply make it a preference that the user can set. Then whatever default ends up being chosen won't upset anybody because it can be changed.
(In reply to comment #37)
> Camino and Firefox are the only major browsers on the OS X platform that
> maximize instead of zooming.

Camino has implemented zoom-to-best-size for quite a long time now (and a shift-click toggle for those days / cases the user want to maximise the window)
I stand corrected.  Camino does have this implemented already, leaving just Firefox.  I like the implementation of using shift+click as an alternative.
(In reply to comment #35)
> I don't think there's any specific defined behavior for this green button.
> Apple themselves seems to do different things with it.

This isn't true, Apple's applications consistently exhibit the same behaviour for this button, that behaviour is "Make window as large as possible until it reaches a point where making it any larger no longer results in additional information being displayed".

iPhoto is a good example, when you hit the zoom (green) button in iPhoto, it expands to fill the screen. This is because things like iPhoto events tile to fill all available space. Since the application fills whatever space it is given, the zoom button causes the window to fill the screen.

In Safari, if you're viewing a page which is 1024 pixels wide, the zoom button will cause the window to be 1024 pixels wide (and, unless you have a very tall screen resolution or a very short page, fill the screen vertically).

The behaviour is not inconsistent between Apple's own applications, only the result of the behaviour is as the applications respond to the type of content they are displaying.

In Firefox, when displaying a page with a fixed width/height, pressing the zoom button should resize the window to that width/height. When displaying a variable size page, the window should resize to whatever percentage of the screen the page is designed to occupy is.

This issue has prevented me from switching from Safari to Firefox on Mac OS X. I love Firefox and always use it on Windows, but this one thing prevents me from having a good user experience on Mac OS X.
I was just about to file a bug about OS X's zoom button behavior when I discovered this bug report. Are you really, after nearly eight years, still seeing this a non-issue? Each OS X program should look and behave as the native environment, imo. And in the case of the major browsers (Chrome and Safari) the zoom button's functionality is *not* to actually fill the screen, but to adapt the current page's max size.
Another concern is that we had *Lion's style of full screen* supported now, and we can leave the zoom button function as it should be- zoom to best fit size.
(In reply to Irvin (MozTW) from comment #43)
> Another concern is that we had *Lion's style of full screen* supported now,
> and we can leave the zoom button function as it should be- zoom to best fit
> size.

Yet, OS X's fullscreen button is conspicuously absent. Firefox for Mac is not nearly as Lion optimized as its counterparts.
(In reply to plic from comment #44)
> Yet, OS X's fullscreen button is conspicuously absent. Firefox for Mac is
> not nearly as Lion optimized as its counterparts.
Lion full screen support had landed on Aurora (14)
It is unfortunately true that the + button has varying behavior, even across Mac apps (iTunes is the worst offender where pressing + goes from a large window to a mini display !?!?!??!). Even so, the expected behavior is to be only as wide as necessary and, with a web browser, full height. The fullscreen option covers the current behavior well.

Alternatively, please at least provide an option for the requested behavior. Mac window management is cumbersome at best compared with other OSs (IMHO), so this option makes it much more tolerable!
This really needs to be worked on. Who is working on this currently, if anyone? I can take a look at it if necessary. But the zooming behavior should act more like Chrome and Safari, and only zoom enough to fill contents.
I strongly suspect the main reason this hasn't been worked on is that many of us Mac programmers who *have* been working on Firefox prefer the current behavior.  I certainly do.

And it probably won't be easy to implement zoom-to-best-size intelligently.

But you're more than welcome to give it a try.
I haven't done any development with Firefox, but I'm surprised to hear it would be difficult to implement this intelligently. Is it not fairly trivial to get the minimum required width to display a page without a horizontal scrollbar? The app has to know the width in order to correctly configure the scrollbars anyway (at least that's true with GTK applications).

If there are a lot of people that prefer the current behavior, perhaps an option so that it can behave more like a native Mac application would be appropriate?
I can try a little later, but as of now I am very busy. Either way, I would actually prefer the Safari-style zooming when it comes to web browsing. There is only a need for height, not width when browsing the web.
Chrome follows safari here. I do appreciate that mode as well. For whatever that is worth.
It's probably worth pointing out this bug was raised in some form as a far back as 1999 (https://bugzilla.mozilla.org/show_bug.cgi?id=13179) before OS X existed on the desktop. On Mac OS 9 the original described behavior was very common. I took a look at http://www.bbc.co.uk/news/ – it has an optimal width as do many other sites – and I'm both a little surprised and quite happy to say Safari is indeed behaving like I'd expect a traditional Mac OS 9 application, at least in width terms. (I don't have a large enough screen to comment on the height part).

So it's been 13 years and I don't expect anything to change unless an individual developer decides they want to work on this project, but I think the goal remains the same. Whether you argue consistency with Safari or Mac tradition, (+) should be zoom to right size.
(In reply to Andrew Thompson from comment #52)
> It's probably worth pointing out this bug was raised in some form as a far
> back as 1999 (https://bugzilla.mozilla.org/show_bug.cgi?id=13179) before OS
> X existed on the desktop. On Mac OS 9 the original described behavior was
> very common. I took a look at http://www.bbc.co.uk/news/ – it has an optimal
> width as do many other sites – and I'm both a little surprised and quite
> happy to say Safari is indeed behaving like I'd expect a traditional Mac OS
> 9 application, at least in width terms. (I don't have a large enough screen
> to comment on the height part).
> 
> So it's been 13 years and I don't expect anything to change unless an
> individual developer decides they want to work on this project, but I think
> the goal remains the same. Whether you argue consistency with Safari or Mac
> tradition, (+) should be zoom to right size.

Indeed. Height does not matter. I believe Safari just expands the windows as much as possible that direction. However width should be changed. Especially on larger monitors, the real multi-taskers aren't going to want Firefox to zoom to a whole ~2500 by X. It's annoying. They also won't want to manually adjust the window. This should be quickly implemented, but we need someone who understands C++ a little more to implement this functionality.
Since I see no way to do it myself somebody should take note that this should block bug 636455.
Never mind, my permissions have been changed.
Blocks: lion-compatibility
triage:  I see Firefox, Safari and Chrome all zoom to full screen with the green button.  None of them zoom to best size. iBook app zooms to full screen.  If talking about consistency within OS X, this bug appears to no longer be valid.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
(In reply to Tracy Walker [:tracy] from comment #56)
> triage:  I see Firefox, Safari and Chrome all zoom to full screen with the
> green button.  None of them zoom to best size. iBook app zooms to full
> screen.  If talking about consistency within OS X, this bug appears to no
> longer be valid.

This is not correct.  Since OS X 10.10, the green button puts the application into fullscreen mode by default instead of performing the "zoom" action.  Between OS X versions 10.7-10.9 there was a dedicated fullscreen button for this in the top right corner of the window.

The "zoom" action is still available though.  Hold down the Option key while clicking the green button.  Alternatively double click the title bar.  Applications that don't support fullscreen mode do "zoom" by default.

Both Chrome and Safari zoom to optimal size.  Firefox doesn't, it just zooms to cover the full screen (not enter fullscreen, which is something else).

The key point is that there is a difference between the "fullscreen" and the "zoom" actions.  Hover the green button to see which one will be activated.  Two triangles mean "fullscreen".  A + sign means "zoom".  Holding Option cases it to show +.

This bug is about the zoom action, not about the fullscreen action.
Ah, excellent, thank you for the clarification.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Whiteboard: tpi:?
Flags: needinfo?(twalker)
Priority: -- → P3
Whiteboard: tpi:? → tpi:+
Current (for OS X) STR's when this gets worked on:

1) While visiting this bug, reduce the browser width to small enough such that there is a horizontal scroll bar at the bottom of the window.
2) then zoom to fit by either:
  A) Double Click the title bar or any space above tabs
or
  B) Option + Click the green window control button (option will switch from full screen button to a (+) for zoom to fit.

Expected results:
The window will resize just enough to get rid of the horizontal scroll bar in step 1. Try Safari with same STR's to observe expected results in action.

Actual results:  The window expands to fill the screen from left to right.  (note: it will not expand to cover the Dock, if you have the Dock set on right or left side of the screen.
Flags: needinfo?(twalker)
Whiteboard: tpi:+ → [safari parity][tpi:+]
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 11 duplicates and 25 votes.
:spohl, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(spohl.mozilla.bugs)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(spohl.mozilla.bugs)
Severity: S3 → --
Type: defect → enhancement
Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.