Most of my programs I only use maximized. Firefox is no exception, I think it should start up maximized on first start or on a new profile. It saves me from having to do that myself.

Platform standard for Windows seems to be to start non-maximized - I've in fact never seen a program which would per default claim all screen space for itself. Besides, with increasing screen resolutions, people are less likely to run any app maximized - since that usually just leads to more blank/unused space. I'd rather vote for Firefox starting up in the platform's default size and position for new windows (Windows gives you those when you don't specify initial dimensions / location).

I have a 1440*900 monitor here, but I still have most programs maximized. Not sure how you found out that the platform standard for Windows is starting non-maximized. What is the default size and position in windows? Where can I find that out?

(In reply to comment #2) > how you found out that the platform standard for Windows Simply by trying out clean installations of a whole lot of different programs. None of them started maximized. So we wouldn't want to surprise new users by suddenly "hiding their desktop". > What is the default size and position in windows? As I said: those depend - among others - on the current screen dimensions. Windows will itself place your window correctly if you pass it the CW_USEDEFAULT flag for window size and position when creating the window (cf. http://msdn2.microsoft.com/en-us/library/ms632679.aspx ).

Seems that I haven't tested well enough... correcting myself: Opera 9, Acrobat Reader (5 probably later versions as well), and most Microsoft Office 2003 applications default to opening maximized at my screen resolution (1024 x 768).

Thanks for testing! I also did some testing now. Adobe Reader 8.1 doesn't start up maximised. Open Office 2.2 doesn't start up maximised. I was testing with a 1280*1024 resolution.

Ok, after 8 years, I totally got this bug. We need to just make this happen asap as we have data that shows screen resolution is negatively impacting conversion rates of the Firefox Accounts sign up flow on /firstrun/. Firefox Accounts is relatively new to /firstrun/ so there wasn't much of an issue before, but now that accounts is central to the cross-device platform, there is now emphasis on this bug. Why the asap nature? Because users who sign up for Firefox sync (even on a single device), are being retained much longer than people who don't. Also, this is a fairly simple patch and we just should do it. If it is low risk, we should also consider uplifting to take advantage of the better UX on /firstrun/ with a larger screen without other distractions. The last time the default size on an new profile was touched was in bug 719318. The logic is: // Very small: maximize the window Logic: <= 600px width Percentage: near 0% of /firstrun/ users // Portrait : use about full width and 3/4 height, to view entire pages Logic: width < height Percentage: < 0.01% // Widescreen: use about half width, to suggest side-by-side page view Logic: >= 2048px width Percentage: < 0.6% of /firstrun/ users // Otherwise : use 3/4 height and width Logic: catch-all else Percentage: 99% ---- Given the information above, let's focus on improving the UX for 99% of our new users. Code is here: http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#1027 I am going to suggest we take out the * .75 for the else condition: 1052 defaultWidth = screen.availWidth; 1053 defaultHeight = screen.availHeight; This will keep the /firstrun/ page maximized for 99% of users and keeps the edge cases in place for super wide screen, super small, and portrait screens to handle <=1% of users.

dolske/mattN: This is a bug that we decided together in the onboarding summit that we should just do. I also just talked about with Matt and I realized this is a really old bug (request) and that we finally have evidence that the smaller screen is negatively impacting the UX on /firstrun/. Looks to be a simple patch. Can one of you help?

The code is easy to change, and there's nothing sacred about the current logic (in fact I would say the opposite ;), but I don't think it's quite as trivial as just using the max available width/height. If we want to fill the screen, the window should probably just be placed in maximized mode. We'll still need to figure out an appropriate size for when it's returned to normal mode, and (modern) OS X is special in that it really only has full-screen and normal modes... A screen-filling window seems awkward there. I'd actually be very curious about what window size (and mode) users settle on after they've actively been using the browser for a while. I don't see anything in Telemetry to use, but since it's basically information exposed to web content this could be something we gather from a common page (whatsnew / download page)... Is there a sweet spot (in percentage of width/height) that users prefer, or correlation between small screens and maximizing? My browser happens to be 87% of the screen width and 97% of the (available) height, but I've no idea if that's normalish. That said, feels like the most obvious win here would would be to at least just increase the percentage of the most-constrained dimension (height, on landscape displays). And in general I think we should err on the side of being bigger -- the user is probably going to tweak the window size anyway, so let's at least make sure it doesn't feel cramped and hide content on the very first page we load. Aside: if firstrun conversion is important, the current page should be made responsive. It's currently a large, static page. So even if we maximize the window, it's still going to scroll on some displays. Anything under full-height on my 15" MBP is too small for that page. There's a huge amount of empty space at the top, which makes this all the more egregious. Changing the initial browser window size is really solving the wrong problem (and something we can only do because we're the browser vendor!). But this is all a bit moot, because I would still agree that the initial window isn't well-sized. I was also going to mention revisiting the Linux sizing hack, but that has since been limited to GTK2. Probably worth double-checking that we're _actually_ getting the right values for GTK3 (which is now the default, and so this can just be removed). 1058 #if MOZ_WIDGET_GTK == 2 1059 // On X, we're not currently able to account for the size of the window 1060 // border. Use 28px as a guess (titlebar + bottom window border) 1061 defaultHeight -= 28; 1062 #endif Dao, can you take this as part of the Windows QX work? And Philipp may have further thoughts.

Sounds good! 80% of window width or height seem to be a good choice.

Good insights, Justin! (In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #9) > Sounds good! > 80% of window width or height seem to be a good choice. So, we are going to change it from 75% of the width/height to 80% width/height? Not sure if 5% change is even worth doing this bug. What about if we just set it on Windows to maximize mode and keep it 75% width/height if they unmaximize it? Does that work? That way we don't have to really mess with any percentages and just set it to maximize on Windows and leave everyone else alone. We are going to work on making the /firstrun/ page be responsive down to smaller resolutions. The original design created wanted the content to be side-by-side, but I am pushing for a slimmer responsive page. Actually, I am pitching it today. Thoughts?

How about something like this: ≤ 1280px width --> 100% width > 1280px width --> 1280px width ≤ 1040px available height (window height- taskbar or window height - dock+menu bar) --> 100% height > 1040px available height --> 1040px height If it's Windows and the rule would result in 100% height & width then use maximized mode instead. We shouldn't use maximized on Mac since it's now full screen which seems to be a whole other thing. The result is something like this - https://www.dropbox.com/s/1lmy52cxcsa0qeq/screen-sizes.png?dl=0

(In reply to Verdi [:verdi] from comment #11) > We shouldn't use maximized on Mac since it's now > full screen which seems to be a whole other thing. FYI this isn't really true, the green button now does fullscreen but the "zoom" option, the OS X equivalent of maximize, is still in the "Window" menu of most applications, including Firefox.

This implements comment 11, mostly. I used 90% of the width / height since unmaximized windows that take up all the width or height seem potentially harmful (unless the user explicitly made it so). I think it's more user-friendly to leave some space around the window so it can be moved around, the user can glance at what's behind the window, etc.. As per comment 12, I haven't implemented any exception for OS X. This patch causes a failure in test_set_window_size.py's test_that_we_can_get_and_set_window_size: "UnsupportedOperationException: Invalid requested size, cannot maximize" I don't understand this yet, it doesn't seem to make sense at first glance.

(In reply to Dão Gottwald [:dao] from comment #13) > This patch causes a failure in test_set_window_size.py's > test_that_we_can_get_and_set_window_size: "UnsupportedOperationException: > Invalid requested size, cannot maximize" And that's only on Windows...

(In reply to Dão Gottwald [:dao] from comment #13) > This implements comment 11, mostly. I used 90% of the width / height since > unmaximized windows that take up all the width or height seem potentially > harmful (unless the user explicitly made it so). I think it's more > user-friendly to leave some space around the window so it can be moved > around, the user can glance at what's behind the window, etc.. As per > comment 12, I haven't implemented any exception for OS X. > 90% is awkward on something like a 1024px wide screen, leading to sideways scrolling on many websites. Here's another idea that avoids maximized windows altogether, leaving a small 10px buffer around the Firefox window: ≤ 1280px width --> 100% width - 20px > 1280px width --> 1280px width - 20px Available height (window height- taskbar or window height - dock+menu bar) --> 100% height - 20px Place the window 10px down from the top and 10px in from the left. The result looks like this https://www.dropbox.com/s/fzz44ulunm23m44/screen-sizes2.jpg?dl=0

(In reply to Verdi [:verdi] from comment #15) > (In reply to Dão Gottwald [:dao] from comment #13) > > This implements comment 11, mostly. I used 90% of the width / height since > > unmaximized windows that take up all the width or height seem potentially > > harmful (unless the user explicitly made it so). I think it's more > > user-friendly to leave some space around the window so it can be moved > > around, the user can glance at what's behind the window, etc.. As per > > comment 12, I haven't implemented any exception for OS X. > > > > 90% is awkward on something like a 1024px wide screen, leading to sideways > scrolling on many websites. No, we'd maximize the window on a 1024px wide screen. The 90% is what you'd get when explicitly unmaximizing it.

(In reply to Dão Gottwald [:dao] from comment #14) > (In reply to Dão Gottwald [:dao] from comment #13) > > This patch causes a failure in test_set_window_size.py's > > test_that_we_can_get_and_set_window_size: "UnsupportedOperationException: > > Invalid requested size, cannot maximize" > > And that's only on Windows... David, any idea what could be going on here? With my patch, the window's size is 1616*1176 when the test starts. I have no idea how that could be a problem.

The test tries to resize the window to 1500*1060, which should work just fine...

We ask Gecko what size the screen is that we can maximise and then if the values passed in are bigger than that we throw this error. see https://dxr.mozilla.org/mozilla-central/source/testing/marionette/driver.js#2671

(In reply to David Burns :automatedtester from comment #19) > We ask Gecko what size the screen is that we can maximise and then if the > values passed in are bigger than that we throw this error. > > see > https://dxr.mozilla.org/mozilla-central/source/testing/marionette/driver. > js#2671 Right, but the size the test wants to use, 1500*1060, is based on subtracting 100 from screen.availWidth and screen.availHeight. So how can this fail the driver.js check that also uses screen.availWidth and screen.availHeight?

I don't know what to say, perhaps windows is lying to Gecko or there is some kinda of race condition?

Rob, you originally wrote this test in bug 1045103. Any idea why it could fail with my patch? Please see comment 17 ff. Note that there was also a similar intermittent failure reported in bug 1207899.

(In reply to Dão Gottwald [:dao] from comment #16) > No, we'd maximize the window on a 1024px wide screen. The 90% is what you'd > get when explicitly unmaximizing it. Per our conversation yesterday, can we do this to avoid an awkwardly sized window on a 1024x768 screen? If the screen is ≤ 1024 x 768 make the unmaximized size: * Width: 100% width - 30px * Height: Available height (window height- taskbar or window height - dock+menu bar) - 30px * Place the window 15px down from the top and 15px in from the left.

(In reply to Dão Gottwald [:dao] from comment #22) > Rob, you originally wrote this test in bug 1045103. Any idea why it could > fail with my patch? Please see comment 17 ff. Note that there was also a > similar intermittent failure reported in bug 1207899. Hi Dão, I don't work on marionette anymore (I'm on a different team now) so I'm pretty rusty at this... I had a quick look at your patch and the test but I don't see anything obvious though, sorry. Good luck!

(In reply to Robert Wood [:rwood] from comment #24) > (In reply to Dão Gottwald [:dao] from comment #22) > > Rob, you originally wrote this test in bug 1045103. Any idea why it could > > fail with my patch? Please see comment 17 ff. Note that there was also a > > similar intermittent failure reported in bug 1207899. > > Hi Dão, I don't work on marionette anymore (I'm on a different team now) so > I'm pretty rusty at this... I had a quick look at your patch and the test > but I don't see anything obvious though, sorry. Good luck! *Sigh* ... anybody else feeling responsible for this test? jgriffin, bug 1207899's reviewer maybe? I'm fairly confident that my patch is fine, and the earlier reported intermittent failure suggests that there's indeed a flaw in the test, maybe a race condition. I'm afraid this will burn a lot of my time if I dig deeper, so if nobody else cares I think I'll just disable the test and move on. :/

What test are we talking about, I can't see any mention of one and the patch doesnt have one nor is there a try push for me to see the failing test

(In reply to Verdi [:verdi] from comment #23) > (In reply to Dão Gottwald [:dao] from comment #16) > > No, we'd maximize the window on a 1024px wide screen. The 90% is what you'd > > get when explicitly unmaximizing it. > > Per our conversation yesterday, can we do this to avoid an awkwardly sized > window on a 1024x768 screen? > > If the screen is ≤ 1024 x 768 make the unmaximized size: > * Width: 100% width - 30px > * Height: Available height (window height- taskbar or window height - > dock+menu bar) - 30px > * Place the window 15px down from the top and 15px in from the left. I did that in this patch, but I think it looks cramped and overall worse than using 90% of the width and height. I'll attach screenshots.

try run https://treeherder.mozilla.org/#/jobs?repo=try&revision=fda8157f0b2e

(In reply to David Burns :automatedtester from comment #31) > try run https://treeherder.mozilla.org/#/jobs?repo=try&revision=fda8157f0b2e This is green on Windows. I suspect what the test couldn't handle with the older patch was that the window was maximized when the test started. This means the test will still have issues when running on a system with a screen size small enough that we'd maximize the window by default.

(In reply to Dão Gottwald [:dao] from comment #27) > (In reply to Verdi [:verdi] from comment #23) > > (In reply to Dão Gottwald [:dao] from comment #16) > > > No, we'd maximize the window on a 1024px wide screen. The 90% is what you'd > > > get when explicitly unmaximizing it. > > > > Per our conversation yesterday, can we do this to avoid an awkwardly sized > > window on a 1024x768 screen? > > > > If the screen is ≤ 1024 x 768 make the unmaximized size: > > * Width: 100% width - 30px > > * Height: Available height (window height- taskbar or window height - > > dock+menu bar) - 30px > > * Place the window 15px down from the top and 15px in from the left. > > I did that in this patch, but I think it looks cramped and overall worse > than using 90% of the width and height. I'll attach screenshots. Verdi and Philipp, what's your take on this? Screenshots are attached.

(In reply to Dão Gottwald [:dao] from comment #33) > Verdi and Philipp, what's your take on this? Screenshots are attached. Here are the same window settings with the pages open on first run along with the bookmarks toolbar and data choices toolbar displayed. https://www.dropbox.com/s/7ldw4la16mo3a2f/comparisons.jpg?dl=0 I think, if we can do the larger window, it's better on this size screen.

Comment on attachment 8690346 [details] [diff] [review] patch v2 Review of attachment 8690346 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/base/content/browser.js @@ +1037,5 @@ > document.documentElement.setAttribute("width", defaultWidth); > document.documentElement.setAttribute("height", defaultHeight); > + document.documentElement.setAttribute("screenX", defaultX); > + document.documentElement.setAttribute("screenY", defaultY); > + window.moveTo(defaultX, defaultY); I'm not sure we want to center vertically since we lose the benefits of Fitts' law on non-OS X (IIRC it default to the top before) and on OS X I personally like all large windows against the titlebar (Not sure what other people prefer). This also wasn't mentioned in the comments yet from a quick skim. @@ +1040,5 @@ > + document.documentElement.setAttribute("screenY", defaultY); > + window.moveTo(defaultX, defaultY); > + > + if (defaultWidth == MAX_WIDTH && defaultWidth == MAX_HEIGHT) { > + document.documentElement.setAttribute("sizemode", "maximized"); With this patch we're not maximizing on low resolutions which I thought was one of the main objectives of this bug.

(In reply to Matthew N. [:MattN] from comment #36) > ::: browser/base/content/browser.js > @@ +1037,5 @@ > > document.documentElement.setAttribute("width", defaultWidth); > > document.documentElement.setAttribute("height", defaultHeight); > > + document.documentElement.setAttribute("screenX", defaultX); > > + document.documentElement.setAttribute("screenY", defaultY); > > + window.moveTo(defaultX, defaultY); > > I'm not sure we want to center vertically since we lose the benefits of > Fitts' law on non-OS X Fitt's law to what end? For moving the window? The top edge would be reserved for resizing the window vertically, not for moving it. Plus: > (IIRC it default to the top before) I don't think this is actually true. > and on OS X I > personally like all large windows against the titlebar (Not sure what other > people prefer). This also wasn't mentioned in the comments yet from a quick > skim. comment 23, last point > @@ +1040,5 @@ > > + document.documentElement.setAttribute("screenY", defaultY); > > + window.moveTo(defaultX, defaultY); > > + > > + if (defaultWidth == MAX_WIDTH && defaultWidth == MAX_HEIGHT) { > > + document.documentElement.setAttribute("sizemode", "maximized"); > > With this patch we're not maximizing on low resolutions which I thought was > one of the main objectives of this bug. Hmm, have I messed up the logic? This seemed to work as expected when I tested it. E.g. I had to unmaximize in order to take the two screenshots I attached.

(In reply to Dão Gottwald [:dao] from comment #37) > > With this patch we're not maximizing on low resolutions which I thought was > > one of the main objectives of this bug. > > Hmm, have I messed up the logic? This seemed to work as expected when I > tested it. E.g. I had to unmaximize in order to take the two screenshots I > attached. Looks like I broke it after taking the screenshots...

I dropped the explicit positioning, as I can't even get it to work reliably anymore...

(In reply to Verdi [:verdi] from comment #35) > (In reply to Dão Gottwald [:dao] from comment #33) > > Verdi and Philipp, what's your take on this? Screenshots are attached. > > Here are the same window settings with the pages open on first run along > with the bookmarks toolbar and data choices toolbar displayed. > https://www.dropbox.com/s/7ldw4la16mo3a2f/comparisons.jpg?dl=0 > > I think, if we can do the larger window, it's better on this size screen. The bookmarks toolbar isn't shown by default, so I'm not sure why you're including it here. Either way, I still think we should optimize the size for moving the window, interacting with other windows and the desktop, etc. when the user explicitly unmaximizes the window. Also, we should make those Mozilla-controlled pages more responsive.

Comment on attachment 8692011 [details] [diff] [review] patch v3 That's better

(In reply to Dão Gottwald [:dao] from comment #40) > The bookmarks toolbar isn't shown by default, so I'm not sure why you're > including it here. Btw. it is shown if the user imports more than N bookmarks from the toolbar of the source browser.

I'll land the reviewed patch as is (attachment 8689482 [details], not attachment 8689481 [details]), and I'll leave the needinfo request so we can file a new bug if needed.

Apparently automation amounts to a small screen, so there's a bunch of failures like https://treeherder.mozilla.org/logviewer.html#?job_id=5929092&repo=fx-team that make sense for being sizing, but also the rather surprising fact of https://treeherder.mozilla.org/logviewer.html#?job_id=5925985&repo=fx-team, that it produced a permanent Valgrind leak. Backed out in https://hg.mozilla.org/integration/fx-team/rev/b9e69115c832

This fixes browser_tilt_zoom.js. It's more of a workaround, though. There are more Windows-only failures: dom/html/test/test_bug369370.html dom/html/test/test_bug741266.html docshell/test/navigation/test_bug344861.html I've filed bug 1228724 on the leak.

Clearing the needinfo (sorry, was on PTO), since Michael already provided the information.

https://hg.mozilla.org/integration/fx-team/rev/9ad78f315cf7688e2f109061697a06fbfd8ed345 Backed out changeset 3cc8559d0d65 (bug 384336) on suspicion of causing test bustage

Fresh Firefox windows look quite bad and awkward on 1280x800 and OS X 10.11. It seems that this change was made for wrong and really unacceptable reasons "We need to just make this happen asap as we have data that shows screen resolution is negatively impacting conversion rates of the Firefox Accounts sign up flow on /firstrun/", "the green button now does fullscreen but the "zoom" option, the OS X equivalent of maximize, is still in the "Window" menu of most applications, including Firefox." I don't know if default window size should be changed, on what platforms Firefox should start maximized but this change should be reverted because optimal window size wasn't even properly considered. (and bloated Mozilla pages should be fixed on their side)

(In reply to Stefan Plewako [:stef] from comment #52) > Fresh Firefox windows look quite bad and awkward on 1280x800 and OS X 10.11. You were most likely hitting bug 1240085 where the screen calculations were wrong for HiDPI. Try again on today's Nightly. If the problem persists, please file a new bug blocking this one and include the output of window.screen.availWidth and window.screen.availHeight from a Fx console.

[bugday-20160323] Able to get expected results for: Status: RESOLVED,FIXED --> VERIFIED Component: Name Firefox Version 46.0b2 Build ID 20160314144540 Update Channel beta User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 OS Windows 7 SP1 x86_64 Actual Results: As expected Expected Results: Firefox is able to start maximized on first run. If I am restarting with restore down, it starts with same window size. In short, On first run, maximize while on restart, window size before restart.

Thanks