897160 - Set a minimum width for the Firefox window

Status: VERIFIED FIXED

(Firefox :: Theme, defect)

Description

[Mehmet]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20130722 Firefox/25.0 (Nightly/Aurora)
Build ID: 20130722040202

Steps to reproduce:

1.) Run UX Build on OSX
2.) Shrink window to a smaller state
3.) Take a look at the right side of the Location Bar


Actual results:

The Location Bar is clipped. Maybe too early.


Expected results:

It should not be clipped too early.

Comment 1

[Mehmet]

Attachment: clipped_Location_Bar.png

+ screenshot

Comment 2

[:Gijs (he/him)]

I think this is somewhat by design. Jared?

Comment 3

[Mehmet]

Thanks for the feedback. If this is by design, maybe there could be a min-width of the window to avoid clipping. Most native applications on Mac has a window min-width. Thanks.

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

Yes, this is by design because we don't want the location bar to become super tiny, however we can adjust the minimum width of the location bar. It's currently set to 50ch.

I tried setting it to lower values like 25ch, 30ch, and 40ch. 25ch and 35ch proved to be too small to view an HTTPS+EV site and still see the domain name in the location bar. 40ch seemed like something that we could do, but it's not going to buy us a ton of space here.

Gijs, what do you think about switching the min-width to 40ch?

We could set a minimum width for the browser, but I fear that will break some use cases of people who are trying to use the browser in very narrow situations and are OK with having some of the primary UI clipped as a trade-off.

Comment 5

[:Gijs (he/him)]

(In reply to Jared Wein [:jaws] from comment #4)
> Yes, this is by design because we don't want the location bar to become
> super tiny, however we can adjust the minimum width of the location bar.
> It's currently set to 50ch.
> 
> I tried setting it to lower values like 25ch, 30ch, and 40ch. 25ch and 35ch
> proved to be too small to view an HTTPS+EV site and still see the domain
> name in the location bar. 40ch seemed like something that we could do, but
> it's not going to buy us a ton of space here.
> 
> Gijs, what do you think about switching the min-width to 40ch?

Sure, but that just makes the problem smaller, I guess.

> We could set a minimum width for the browser, but I fear that will break
> some use cases of people who are trying to use the browser in very narrow
> situations and are OK with having some of the primary UI clipped as a
> trade-off.

We could set the min-width only if toolbars=yes (which implies the navbar is showing, which implies that the min-width needed for the navbar is there, etc. etc). I guess it's sort of up to UX to what extent we're OK with this? If you agree that this would be an option and/or feasible, please pass the hot potato to madhava. :-)

Comment 6

[Jared Wein [:jaws] (please needinfo? me)]

Setting a min-width on the browser window when toolbars=yes seems like a good move to make. Thank you for thinking about that.

Madhava, this is what it looks like when the browser is at its narrowest: http://screencast.com/t/tkS9so5ANiXf What do you think about restricting this so we have a sensible minimum width for the browser window?

Comment 7

[Dão Gottwald [::dao]]

(In reply to :Gijs Kruitbosch from comment #5)
> > We could set a minimum width for the browser, but I fear that will break
> > some use cases of people who are trying to use the browser in very narrow
> > situations and are OK with having some of the primary UI clipped as a
> > trade-off.
> 
> We could set the min-width only if toolbars=yes (which implies the navbar is
> showing, which implies that the min-width needed for the navbar is there,
> etc. etc).

The nav bar is always showing. What does this have to do with toolbars=yes?

Comment 8

[Justin Dolske [:Dolske]]

It seems a bit surprising that we clip the reload widget instead of more of the URL. Release behaves as I'd expect (or am at least used to!).

I think a minimum window size would be a fine way to sidestep this issue (unless we clip such a large size that it's not a useful fix here). On OS X, Chrome's minimum size is 400x270, and Safari is 400x280. IE10/Win7 goes down to about 250px wide, with a height limited to the toolbar + ~16px extra. But the UI stops adjusting at 360px, and going down to the minimum size clips the icons on the right side of the toolbar. Chrome will smoosh down to 190px wide, but it's not terribly useful. It's min-height works the same as IE.

With a stock Australis (Win7), our UI starts to clip things at 390px we start to get wonky at ~315px. On OS X it starts clipping a 425px, and gets wonky at 255px. We're ok with min heights.

So, I'd suggest making a minimum width of 425px on OS X, and 390px on Windows. Cheap way to fix the most common issues, and we can deal with improvements to make things smaller/better/faster in followups.

Comment 9

[:Gijs (he/him)]

I'd like to check how bug 899587 affected this; I suspect that not setting widths on the URl and search bars might make this better.

Comment 10

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #9)
> I'd like to check how bug 899587 affected this; I suspect that not setting
> widths on the URl and search bars might make this better.

This doesn't seem to have helped.

Comment 11

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch

Using the values recommended in https://bugzilla.mozilla.org/show_bug.cgi?id=897160#c8.

Comment 12

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 790842 [details] [diff] [review]
Patch

Review of attachment 790842 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/base/content/browser.css
@@ +6,5 @@
>  @namespace html url("http://www.w3.org/1999/xhtml");
>  
> +#main-window {
> +%ifdef XP_MACOSX
> +  min-width: 425px;

What about pop-up windows? I thought we said that we can't have such a minimum on pop-up windows?

Comment 13

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 790842 [details] [diff] [review]
Patch

Oh, embarrassing! I forgot.

Comment 14

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch v2

Comment 15

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 790863 [details] [diff] [review]
Patch v2

Review of attachment 790863 [details] [diff] [review]:
-----------------------------------------------------------------

This looks fine - but I think I want to see a try push with green results. Or at least some assurance that tests dealing with window size still pass (I know there are several SocialAPI tests, for example, that resize the window).

Comment 16

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Mike Conley (:mconley) from comment #15)
> Comment on attachment 790863 [details] [diff] [review]
> Patch v2
> 
> Review of attachment 790863 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This looks fine - but I think I want to see a try push with green results.
> Or at least some assurance that tests dealing with window size still pass (I
> know there are several SocialAPI tests, for example, that resize the window).

https://tbpl.mozilla.org/?tree=Try&rev=fbc5556db651

Comment 17

[Jared Wein [:jaws] (please needinfo? me)]

https://hg.mozilla.org/integration/fx-team/rev/707307cc53a6

Comment 18

[Jared Wein [:jaws] (please needinfo? me)]

Backed out in https://hg.mozilla.org/integration/fx-team/rev/ae177d0849f5 for timing out browser_tabview_bug625269.js. I'll adjust the test and repush.

Comment 19

[Jared Wein [:jaws] (please needinfo? me)]

https://hg.mozilla.org/integration/fx-team/rev/c0471a86a81a

Comment 20

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/c0471a86a81a

Comment 21

[Ricardo]

So, now with this "fix" web developers will have more complications to test responsive designs for small screens??

This is truly a unnecessary fix at all.

Comment 22

[Matthew N. [:MattN]]

(In reply to Ricardo from comment #21)
> So, now with this "fix" web developers will have more complications to test
> responsive designs for small screens??

We have a responsive design view that makes this easier than resizing the whole browser window. See https://developer.mozilla.org/en-US/docs/Tools/Responsive_Design_View

Comment 23

[Ricardo]

Ofc I know, but it doesn't help to test multiple tabs at the same size, and reloading pages with it on very often causes css3 animation weirdness.

Comment 24

[Thomas Weber]

This "fix" is a total nightmare when it comes to developing responsive designs, and no the "responsive design view" is not a real alternative to resizing the viewport when it comes to checking liquid layouts and their breakpoints.
If this absolutely minor problem has to be addressed by a min-width of the browser window, that min-width should not be larger than 300px.

Comment 25

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Thomas Weber from comment #24)
> the "responsive design view" is not a real alternative to
> resizing the viewport when it comes to checking liquid layouts and their
> breakpoints.

Why? If this is the case, what can be changed about the responsive design view so that it works better for your use case?

Comment 26

[Ricardo]

> what can be changed about the responsive design view so that it works better for your use case?

For me, I like how it behaves with its mobile-alike scrollbars, but it needs some fixes, for example, CSS3 animations are executed twice while in "responsive design view".
Other than that, when using windows at correct size, there's no need to open a special mode every time a new tab/window is needed. Also:
1) the toolbar it includes might be better placed in another position, maybe below visible area so it doesn't spend vertical space before content (tab bar + address bar + rdv toolbar + menu bar(for some people) is a lot).
2) Resizing the rdv space with mouse relies on dragging the 'arrows' close to the bottom of the screen, where very often there is not enough space to expand vertically the area without first resizing the main window (especially on typical wide screens).

Comment 27

[Bob]

This is more than slightly annoying. I like to keep a small chat window open in a mobile-sized view, and the new minimum width is absurdly large, making it look ugly and take up considerably more screen real-estate. A clipped/hidden location bar due to resizing does not significantly impair the functionality of the browser (you can always expand it again), while this 'fix' does - the 'fix' is worse than the problem!

At the very least, please include a property accessible via about:config, like many other width settings in the browser (e.g. tabClipWidth).

---

At least as a temporary measure, the below will work in userChrome.css to revert this change:

> @namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
> @namespace html url("http://www.w3.org/1999/xhtml");
> 
> #main-window:not([chromehidden~="toolbar"]) {
> 	min-width: 10px !important;
> }

Comment 28

[Bob]

Looks like other width settings I was referencing were actually exposed by addons, and the tab one isn't quite the same thing - still, if at all possible, could this be a more easily configurable option?

Comment 29

[Kohei Yoshino]

Added a note for Web developers:
https://developer.mozilla.org/en-US/Firefox/Releases/26/Site_Compatibility

Comment 30

[Kohei Yoshino]

And tweeted: https://twitter.com/MozWebCompat/status/412593997832785920

Comment 31

[Ricardo]

(In reply to Kohei Yoshino [:kohei] from comment #29)
> Added a note for Web developers:
> https://developer.mozilla.org/en-US/Firefox/Releases/26/Site_Compatibility

How will it revert the side effects of this change?

Anyway, initial reporter was talking about clipping in his Mac OS X, but this 'fix' has been applied to all OSes. Make him happy and keep this for Mac users only.

Furthermore, importance should be put over content display and browser versatility, instead of address bar not being clipped for cosmetic.

Comment 32

[Jared Wein [:jaws] (please needinfo? me)]

While the initial comment mentions OSX, this bug affected all platforms. The minimum width of the browser window is not applied to popup windows, so this shouldn't affect content display.

Comment 33

[Kohei Yoshino]

(In reply to Jared Wein [:jaws] (Away 20 Dec to 2 Jan) from comment #32)
> The minimum width of the browser window is not applied to popup windows, so 
> this shouldn't affect content display.

Mentioned it on the compatibility doc.

Comment 34

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Kohei Yoshino [:kohei] from comment #33)
> (In reply to Jared Wein [:jaws] (Away 20 Dec to 2 Jan) from comment #32)
> > The minimum width of the browser window is not applied to popup windows, so 
> > this shouldn't affect content display.
> 
> Mentioned it on the compatibility doc.

Thanks!

Comment 35

[Ricardo]

(In reply to Jared Wein [:jaws] (Away 20 Dec to 2 Jan) from comment #32)
> is not applied to popup windows, so this shouldn't affect content display.

Sorry, but what do you understand by "content"? For me it is everything you browse on the web using a browser.

And, yes, this unwanted change you call by "fix" affects web contents display, whose width is now superficially limited by your change.

Thank you Bob, for finding a way to revert it, at least while software developers don't understand why it is better for web designers to resize a windows than a "Responsive Design View".

> CSS3 animations are executed twice while in "responsive design view".

Comment 36

[Kohei Yoshino]

Which content has been affected in particular?

Comment 37

[Ricardo]

Any content I want to test for widths smaller than the one you set. Let's suppose I need to test many versions of a mobile design for a screen of 100x150px, each one in one tab or window, the need to open "responsive design view" every time is not nice and is disruptive.

Also, that feature has some quirks as I said and repeated above.

And more, especially because the default behavior for resizing windows since the beginning of the web didn't need another tool for resizing windows past a certain width.

Furthermore, I consider that a location bar being cut is not enough reason for limiting the width of the main window. Instead, if it is really a problem for you, that bar should be redesigned for being more flexible.

Comment 38

[Kohei Yoshino]

So this change only affects your own test environment, not a real-world Web site.

I'm also a Web developer but I understand the resizable desktop browser window is NOT a mobile simulator. Unfortunately, you can/should not rely on it anyway when you test mobile sites. Other better tools are available instead, including:

* Responsive Design View https://developer.mozilla.org/docs/Tools/Responsive_Design_View
* Emulation Panel in Chrome DevTools
* Android Emulator
* iOS Simulator in Xcode
* Firefox OS Simulator https://developer.mozilla.org/docs/Tools/Firefox_OS_Simulator
* Physical mobile devices

If you have encountered bugs in the Responsive Design View, you are highly encouraged to report it here on Bugzilla.

Comment 39

[Bob]

It's not just mobile *development*, though. As I stated above, I like to *use* some mobile sites on a desktop, because that allows me to have more on the screen at once (along with optimisations for lower resource usage and lower network usage when on slow networks). This requires the entire window to be resized - responsive design view is completely useless if the intention is to save screen space. This isn't an exceptionally rare thing to do.

Of course, there are workarounds - either launching a popup window or overriding the chrome CSS. But workarounds *should not be necessary* - it's an overkill solution with many side effects for what was a small problem.

Comment 40

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Ricardo from comment #26)
> For me, I like how it behaves with its mobile-alike scrollbars, but it needs
> some fixes, for example, CSS3 animations are executed twice while in
> "responsive design view".

I don't see a bug on file for this in the Responsive Mode component ( https://bugzilla.mozilla.org/buglist.cgi?product=Firefox&component=Developer%20Tools%3A%20Responsive%20Mode&resolution=---&list_id=8946543 ). Can you please file a bug there with some steps to reproduce?

Comment 43

[Kohei Yoshino]

Bob: you might want to use a Firefox add-on like https://addons.mozilla.org/firefox/addon/tile-tabs/

Comment 44

[Ricardo]

(In reply to Kohei Yoshino [:kohei] from comment #43)
> Bob: you might want to use a Firefox add-on like
> https://addons.mozilla.org/firefox/addon/tile-tabs/
&&
> Other better tools are available instead, including [...]

Why create more complication and instability rather than keep the default width behavior that existed since Mosaic Netscape?

Where have this been discussed before this "fix" being applied everywhere with high priority?

While some critical and very shameful bugs take more than 9 years to get fixed (eg: https://bugzilla.mozilla.org/show_bug.cgi?id=261037), this kind of (false)bug is 'corrected' in a blink of eyes.

If this is not reverted, I will fill bugs just to revert this when I have time and patience to lost with such unnecessary issues. I have more to do, and you 2 defenders of this path should too. Go fix needed things.

Comment 45

[Kohei Yoshino]

I'm not involved in this change, but all I can say is the desktop browser window (or Mosaic in you-speak) is not intended to display/test mobile sites. You should find a better tool for such a purpose.

Comment 46

[Kohei Yoshino]

(In reply to Ricardo from comment #44)
> Why create more complication and instability rather than keep the default
> width behavior that existed since Mosaic Netscape?

Because the mobile Web is complicated and instable. It's a relatively new concept that Mosaic Netscape didn't expect. That's why we need appropriate tools.

Comment 47

[Bob]

Thanks for the tiling suggestion - definitely could be useful, but it would only work where the whole screen was a maximised FF window, and is yet another workaround that shouldn't be necessary.

We're getting a little bogged down in whether mobile sites should be supported. As I see it, any standards-compliant mobile site should be fully usable in a standards-compliant desktop browser - to say it *shouldn't be a supported use* just because it's targeted towards mobile is just wrong, when the underlying technology is identical (moreso with desktop browsers increasingly being used on touch-capable machines).

But that's not the point. We're getting a little bogged down in whether mobile sites should be supported. And mobile sites are just an example - there are other uses, such as status windows, or even something like a news ticker.

Simply put, the minimum width is set too wide. It takes up over a third of the width of some non-widescreen monitors still in use (yes, they exist!). It looks ugly with narrow vertical content, requiring the window be even higher to keep a pleasing aspect ratio.

The original complaint was the clipping of the location bar - that could have been dealt with in another way, such as allowing the bar to shrink smaller, without affecting everything else. In fact, if you have a lot of addons/icons some clipping still happens - but fixing that by setting minimum window width would be completely broken, considering how many some people have. In short, this fix is inconsistent, has side effects, and really should have been handled in some other way.

There are workarounds, yes. My opinion is they shouldn't be necessary. Unfortunately, at this point I seriously doubt that anything will be changed.

Comment 48

[Kohei Yoshino]

(In reply to Bob from comment #47)
> And mobile sites are just an example - there are other uses, 
> such as status windows, or even something like a news ticker.

Such content is usually displayed in a popup window, so it should not be affected as :jaws explained in Comment 32. Do you know any affected site?

Comment 49

[Bob]

(In reply to Kohei Yoshino [:kohei] from comment #48)
> Do you know any affected site?

Not off the top of my head, no - they are things I've seen in the past (and used as examples). And web devs can always open popup windows. This has more of an effect on people who wish to resize existing windows, e.g. to only show part of one on the side of the screen while they work on other things.

Comment 50

[Dão Gottwald [::dao]]

Loading some content in a normal window and reducing its size so you can keep it in your peripheral vision along another window, or something like that, seems like a valid use case. What are we doing about this? Users can't open popups manually.

I agree that this solution seems worse than the original problem. The original problem (if we think it's necessary to address) could be approached differently, like allowing the location bar to shrink further. It also seems that the clipping behavior is an Australis-specific regression that should be addressed separately.

Comment 51

[Dão Gottwald [::dao]]

(In reply to Dão Gottwald [:dao] from comment #50)
> I agree that this solution seems worse than the original problem. The
> original problem (if we think it's necessary to address) could be approached
> differently, like allowing the location bar to shrink further. It also seems
> that the clipping behavior is an Australis-specific regression that should
> be addressed separately.

Bug 951928 suggests that the original problem isn't even fixed.

Comment 52

[:Gavin Sharp [email: [e-mail]]]

We should have a minimum window size that prevents the default UI from looking "obviously wrong". That's what this bug was intending to do - if it didn't quite do that, we should fix that (in a followup bug, like bug 951928).

If we can reduce the minimum window size by adjusting some UI styling, we should also investigate that, though it's probably quite low priority.

Comment 53

[Ricardo]

(In reply to :Gavin Sharp (email [e-mail]) from comment #52)
> We should have a minimum window size that prevents the default UI from looking "obviously wrong".

LOL, guy.
You should redesign the part of the UI that is looking wrong, but not limit the window size in any axe.

(In reply to Kohei Yoshino [:kohei] from comment #46)
> (In reply to Ricardo from comment #44)
> Because the mobile Web is complicated and instable. It's a relatively new
> concept that Mosaic Netscape didn't expect. That's why we need appropriate tools.

That is why you have Firefox for Mobile, as you like extra tools for doing jobs you could do with no extra tools.

Comment 54

[Ricardo]

(In reply to Kohei Yoshino [:kohei] from comment #45)
> I'm not involved in this change, but all I can say is the desktop browser
> window (or Mosaic in you-speak) is not intended to display/test mobile
> sites. You should find a better tool for such a purpose.

You are involved because you are defending it.

And, yes, is is intended to test these sites, because:
1. It is the environment we work on.
2. If the smartphone has the same pixel aspect and DPI as the desktop monitors, there are absolutely *NO* differences between mobile and desktop web navigators.

Can you please get true arguments to this discussion? Or just let it to the original reporter and assigned coder. Ok?

Comment 55

[Kohei Yoshino]

Ricardo: I was just curious what are you guys were talking about, because I'm the lead writer of the Firefox site compatibility documents. If this change doesn't affect real-world Web sites and developers, that's fine with me. I think your usage is a sort of "unintended use" of the product, so I don't consider this change as a backward compatibility issue.

Comment 56

[Bob]

(In reply to Kohei Yoshino [:kohei] from comment #55)
> Ricardo: I was just curious what are you guys were talking about, because
> I'm the lead writer of the Firefox site compatibility documents. If this
> change doesn't affect real-world Web sites and developers, that's fine with
> me. I think your usage is a sort of "unintended use" of the product, so I
> don't consider this change as a backward compatibility issue.

It is not the job of the browser to determine whether a site's intended audience matches its own. There is no technical difference, as far as the browser should be concerned, between a standards-compliant "mobile" site and any other standards-compliant site. The only thing really determining whether a site is "mobile" or not is the designer's original intention, which a browser should not, and CANNOT, guess. As long as a site is standards-compliant, calling it an unintended use is wrong.

We even have convertible tablets running x86 OSes, with x86 browsers, with full touch support the same resolution as phones. Heck, my laptop that I'm typing this on has a lower resolution than quite a few phones now. And you can take one website, and load it in a tablet or a desktop or a phone, and it will *work the same way*. How can you distinguish them? **You can't.** I could have a website that's literally plain text (to use a contrived example), and load it on a phone. Is it now a "mobile site"? Is it now an "unintended use" if I load it in desktop Firefox? Do you see the problem?

What would you consider a "real-world" site? I am very much affected as a user of certain chat sites that are mostly vertical and lend themselves very well to being adjusted to a narrow width and put along the side of the screen - much like the Windows 8 Metro 'snap', actually, except I'm arranging traditional desktop windows. These sites may or may not be originally designed for mobile use - but I could easily design my own, slap a "chat for narrow-width desktop browsers" sticker on it, and, there, it's no longer a "mobile" site. Hey, now it doesn't work on Firefox! It used to! It even works on Chrome and Internet Explorer going back as far as anyone can remember! And you don't think that's a backwards compatibility issue? I'm not the only one using websites and browsers in this manner, that I can guarantee. How is this not "real-world"?

But my goal in these comments isn't to debate mobile vs non-mobile (though there's NO (significant?) difference from a web-standards perspective, and I find your claims otherwise to be quite dangerous, especially as the lead writer for compatibility documents). I'm saying this change is bad, that it affects "real-world" uses of the browser, and that it doesn't even properly fix the original issue.

Comment 57

[Dão Gottwald [::dao]]

(In reply to :Gavin Sharp (email [e-mail]) from comment #52)
> We should have a minimum window size that prevents the default UI from
> looking "obviously wrong". That's what this bug was intending to do - if it
> didn't quite do that, we should fix that (in a followup bug, like bug
> 951928).
> 
> If we can reduce the minimum window size by adjusting some UI styling, we
> should also investigate that, though it's probably quite low priority.

Users who want to resize a window to a certain point and then complain about the UI looking broken aren't going to be more pleased by not being allowed to get to that size at all. At least I think this is true for users who have a real use case here and care more about the web content than the reload button. It may not be true for e.g. nightly testers who check out edge cases to see what breaks.

The brokenness is also self-made and as already established in comment 8, there's an Australis-specific regression. We can't just raise the limit whenever we break something. The first initiative should be about fixing the breakage.

I'll see if I can approach this more liberally in bug 951928.

I the meantime I think we should back this out from aurora and beta where the Australis bug isn't present. Jared, does this make sense?

Comment 58

[Jared Wein [:jaws] (please needinfo? me)]

I don't think we should back this out from Aurora or Beta. 

We've had issues where our UI is broken by this resizing for years (see bug 391981 for example). There never seemed to be an intention to allowing the window to scale to arbitrarily small sizes such as 50x20 pixels. The ability to do that stemmed from the fact that previously we didn't have the capability to set a minimum size for XUL windows.

Comment 59

[:Gavin Sharp [email: [e-mail]]]

I concur - we can discuss what the size restriction should be exactly, but we shouldn't remove it entirely.

Comment 60

[Ricardo]

Nothing above proves the real need or reason to limit the width.

On the opposite, however, there are and we have presented here many reasons.

We hate artificial limitations.

Comment 61

[Bob]

(In reply to :Gavin Sharp (email [e-mail]) from comment #59)
> I concur - we can discuss what the size restriction should be exactly, but
> we shouldn't remove it entirely.

IE11 on Win7 goes down to about 220x20 for the content, about 250x100 for the entire window. (with both scrollbars) It happily hides all tabs and starts eating into the location bar.

Chrome 31 on Win7 goes down to about 162x0 for the content, about 193x90 for the window. (both scrollbars) It seems to have the sanest behaviour of all three, despite also having the smallest size. The tabs shrink until only the close button is shown, and the location bar shrinks until the text is pretty much invisible - but no visible clipping or otherwise that might be considered bugs. It is also the only one that preserves the reload button. This is probably the best one to emulate - it looks nice and smooth, doesn't really hide anything important, and gets the absolute minimum size possible while doing so.

I don't have a previous version of Firefox to test at the moment, but I can get the window down to about 210 across before the Firefox button starts overlapping the minimise button, with the modified userChrome.css as in comment 27. Absolute minimum seems to be 132 across with the x of the close button barely visible. The current vertical minimum seems to be about 20 for the content and 125 for the window. The minimum in my copy of Aurora with default styles is 406 across, same with Nightly.

I would suggest a minimum for the entire window to be no more than 250 across, which is what IE11 uses. The Firefox button doesn't exist in Australis, but it seems to start eating the vertical scrollbar around the same width of 210 across, so that's probably the lowest we can practically go.

Australis seems to be able to go down to about 310 before it starts eating the single tab. I would suggest lowering the width of the location bar and the tabs, much like Chrome, rather than making it that wide.

---

All measurements taken with Greenshot on the same Windows 7 machine with Aero theme. They're approximations, and may be off by a few pixels.

Comment 62

[Bob]

(In reply to Bob from comment #61)
> Australis seems to be able to go down to about 310 before it starts eating
> the single tab. I would suggest lowering the width of the location bar and
> the tabs, much like Chrome, rather than making it that wide.

Actually, it seems that, unlike previous Firefox and IE, and more like Chrome, the tabs do fit under the minimise/maximise/close buttons, leaving less space for them. They also don't reach the top of the window when not maximised, so this seems rather pointless - it might be useful to just let it fit under. Even if not, Chrome seems to handle that just fine with smaller widths.

Comment 63

[Dão Gottwald [::dao]]

(In reply to Jared Wein [:jaws] (Away 20 Dec to 2 Jan) from comment #58)
> I don't think we should back this out from Aurora or Beta. 
> 
> We've had issues where our UI is broken by this resizing for years (see bug
> 391981 for example). There never seemed to be an intention to allowing the
> window to scale to arbitrarily small sizes such as 50x20 pixels. The ability
> to do that stemmed from the fact that previously we didn't have the
> capability to set a minimum size for XUL windows.

Bug 391981 is ancient, we're in no rush to do something about this expect for Australis, hence the suggestion to figure this out on central and back it out from non-Australis release trains where the limit seems arbitrary and too high.

Comment 64

[Dão Gottwald [::dao]]

(In reply to Dão Gottwald [:dao] from comment #63)
> (In reply to Jared Wein [:jaws] (Away 20 Dec to 2 Jan) from comment #58)
> > I don't think we should back this out from Aurora or Beta. 
> > 
> > We've had issues where our UI is broken by this resizing for years (see bug
> > 391981 for example). There never seemed to be an intention to allowing the
> > window to scale to arbitrarily small sizes such as 50x20 pixels. The ability
> > to do that stemmed from the fact that previously we didn't have the
> > capability to set a minimum size for XUL windows.
> 
> Bug 391981 is ancient, we're in no rush to do something about this expect
> for Australis,

*except* for Australis

Comment 65

[[e-mail]]

Hi, After reading this issue carefully I would like to comment on this issue.
Is it possible to keep both sides happy by, e.g. example:

- change it to 300px (or perhaps 250 px), so we can test 320X480 res.(comment #24 Thomas Weber )
- include a property accessible via about:config.(comment #27 Bob)
- find the real bug and fix it instead of "patching" it wrongly. Gavin

I think this quote summons it al:
Users who want to resize a window to a certain point and then complain about the UI looking broken aren't going to be more pleased by not being allowed to get to that size at all.

Good day and stay positive.

Comment 66

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Dão Gottwald [:dao] from comment #63)
> (In reply to Jared Wein [:jaws] (Away 20 Dec to 2 Jan) from comment #58)
> > I don't think we should back this out from Aurora or Beta. 
> > 
> > We've had issues where our UI is broken by this resizing for years (see bug
> > 391981 for example). There never seemed to be an intention to allowing the
> > window to scale to arbitrarily small sizes such as 50x20 pixels. The ability
> > to do that stemmed from the fact that previously we didn't have the
> > capability to set a minimum size for XUL windows.
> 
> Bug 391981 is ancient, we're in no rush to do something ...

How did you determine that we were under no rush to do something? Fixing this bug only became possible relatively recently.

Not having a minimum window size becomes a usability problem. It is easy to get the window size too small by accident, and the user can lose the window, never finding it again on their cluttered desktop.

Comment 67

[Dão Gottwald [::dao]]

(In reply to Jared Wein [:jaws] (Away 20 Dec to 2 Jan) from comment #66)
> > Bug 391981 is ancient, we're in no rush to do something ...
> 
> How did you determine that we were under no rush to do something? Fixing
> this bug only became possible relatively recently.

5 months from getting the possibility to setting a min-width in front-end code doesn't seem like it was urgent. Also, we always controlled the whole stack. It just wasn't a priority before.

> Not having a minimum window size becomes a usability problem. It is easy to
> get the window size too small by accident, and the user can lose the window,
> never finding it again on their cluttered desktop.

This sounds very constructed and hypothetical to me. Is there any evidence that this was a common problem for a notable amount of people?

Comment 68

[:Gavin Sharp [email: [e-mail]]]

Backporting bug 956260 seems like a better option than backing this patch out.

Comment 69

[Kohei Yoshino]

Added to the 29 compatibility doc. Again, this is not actually a compatibility issue but it's worth drawing developer's attention.
https://developer.mozilla.org/en-US/Firefox/Releases/29/Site_Compatibility

Comment 70

[Andrei Vaida [:avaida]]

I was able to confirm the fix for this specific scenario on Mac OS X 10.9.1 [1], using:
- the latest Nightly (Build ID: 20140306030201),
- the latest Aurora (Build ID: 20140306004001),
unfortunately Bug 980879 seems to depict a very similar issue and is most likely related. Adding it as a dependency.

[1] Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Firefox/30.0