window.open to screen.availHeight and screen.availWidth Dimensions

[Robert Liao]

I've got http://crbug.com/527506 where a user would like to open a Chrome Window using window.open(url, context, features).

Specifically, they want to size the window at (screen.availWidth x screen.availHeight) like so:

window.open(

    'http://www.google.com', 

    '', 

    'width=' + screen.availWidth + ',height=' + screen.availHeight);

My reading of the CSSOM View Spec is that width and height apply to the viewpoint or client area. Window decorations like the frame, tab strip, and other whatnot are not included so Chrome for Windows is doing "the right thing" when the window opens larger than the expected bounds.

Chrome for Mac, on the other hand, does not do the right thing in that it sizes to the window rather than the viewport.

It seems that a workaround is to do a window.resizeTo(screen.availWidth, screen.availHeight) which is spec'ed to include the window decorations.

Is this reading correct and is there a better way?

Thanks!

Robert

[Daniel Cheng]

In this sort of situation, it's usually useful to see how IE/Firefox/Safari handle it.

Daniel

[Simon Pieters]

On Tue, 10 Nov 2015 03:46:36 +0100, Robert Liao <rob...@chromium.org>
wrote:

> I've got http://crbug.com/527506 where a user would like to open a Chrome
> Window using window.open(url, context, features).
>
> Specifically, they want to size the window at (screen.availWidth x
> screen.availHeight) like so:
> window.open(
> 'http://www.google.com',
> '',
> 'width=' + screen.availWidth + ',height=' + screen.availHeight);
>
> My reading of the CSSOM View Spec

> <https://drafts.csswg.org/cssom-view/#the-features-argument-to-the-open()-method>

> is that width and height apply to the viewpoint or client area. Window
> decorations like the frame, tab strip, and other whatnot are not included
> so Chrome for Windows is doing "the right thing" when the window opens
> larger than the expected bounds.
>
> Chrome for Mac, on the other hand, does not do the right thing in that it
> sizes to the window rather than the viewport.
>
> It seems that a workaround is to do a window.resizeTo(screen.availWidth,
> screen.availHeight) which is spec'ed to include the window decorations.
>
> Is this reading correct and is there a better way?

Note that the spec allows clamping of the dimensions to make the window
fit the available space, and also allows moving the window so that it
doesn't appear completely or partially outside the available space.

If the spec is wrong on something, I'm happy to fix it.

https://www.w3.org/Bugs/Public/enter_bug.cgi?product=CSS&component=CSSOM%20View&short_desc=&comment=https%3A%2F%2Fdrafts.csswg.org%2Fcssom-view%2F%0A%0A

--
Simon Pieters
Opera Software

[Robert Liao]

Simon: What would the recommendation be for developers who want to perfectly size a window to cover the available work area of the screen (Windows: The work area is the full screen size minus things like the task bar).

It seems like devs can't do this directly if all they control is the viewport. There isn't a way to determine the non-client area without first creating the window, doing some outerHeight/outerWidth math, and then sizing the window based off of that.

dcheng: IE does the same thing we do with respect to window.open. I didn't check firefox, but instead went to the spec.

[Simon Pieters]

On Tue, 10 Nov 2015 19:00:30 +0100, Robert Liao <rob...@chromium.org>
wrote:

> Simon: What would the recommendation be for developers who want to
> perfectly size a window to cover the available work area of the screen
> (Windows: The work area is the full screen size minus things like the
> task
> bar).
>
> It seems like devs can't do this directly if all they control is the
> viewport. There isn't a way to determine the non-client area without
> first
> creating the window, doing some outerHeight/outerWidth math, and then
> sizing the window based off of that.

I think it should just be exactly the code that was posted in the first
message in this thread, but that the browser would clamp the size so that
the outer edges of the window fit inside the available space, and move the
window if necessary. The spec's algorithm is intended to allow for this.

> dcheng: IE does the same thing we do with respect to window.open. I
> didn't
> check firefox, but instead went to the spec.

As far as I can tell, Firefox (on Mac, don't know about other platforms)
does what I think should happen: attempt to open a window with the
viewport having the specified dimensions, and if the resulting window is
larger than the available space, shrink it so it fits.

Chrome on Mac seems to behave this way as well. No?

See http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3745

[Simon Pieters]

On Tue, 10 Nov 2015 03:46:36 +0100, Robert Liao <rob...@chromium.org>
wrote:

> It seems that a workaround is to do a window.resizeTo(screen.availWidth,
> screen.availHeight) which is spec'ed to include the window decorations.

It's not, FWIW:

https://drafts.csswg.org/cssom-view/#dom-window-resizeto

> 5. Optionally, clamp x and y in a user-agent-defined manner so that the
> window does not get too small or bigger than the available space.
>
> 6. Resize target’s window by moving its right and bottom edges such that
> the distance between the left and right edges *of the viewport* are x
> CSS pixels of target and the distance between the top and bottom edges
> *of the viewport* are y CSS pixels of target.

Step 5 here is intended to let the UA shrink the window to make it fit the
available space.

[Robert Liao]

Sorry for the delayed reply! Somehow this thread go got muted.

Mac simply passes screen.availWidth and screen.availHeight straight to [NSWindow setFrame:display:]

* thread #1: tid = 0x139e4d, 0x00007fff830d8851 AppKit`-[NSWindow setFrame:display:], name = 'CrBrowserMain', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1

  * frame #0: 0x00007fff830d8851 AppKit`-[NSWindow setFrame:display:]

    frame #1: 0x00000001057f2e7f libchrome_main_dll.dylib`BrowserWindowCocoa::SetBounds(this=0x000000010041efa0, bounds=0x00007fff5fbf9c10) + 879 at browser_window_cocoa.mm:218

    frame #2: 0x00000001057faff4 libchrome_main_dll.dylib`-[BrowserWindowController initWithBrowser:takeOwnership:](self=0x000000013febb010, _cmd="initWithBrowser:takeOwnership:", browser=0x000000013febea00, ownIt=YES) + 2308 at browser_window_controller.mm:297

    frame #3: 0x00000001057fa6be libchrome_main_dll.dylib`-[BrowserWindowController initWithBrowser:](self=0x000000013febb010, _cmd="initWithBrowser:", browser=0x000000013febea00) + 62 at browser_window_controller.mm:218

(lldb) print cocoa_bounds

(NSRect) $0 = (origin = (x = 0, y = 68), size = (width = 1680, height = 959))

These are the same dimensions for screen.availWidth and screen.availHeight.

Robert

[Simon Pieters]

On Tue, 17 Nov 2015 17:21:10 +0100, Robert Liao <rob...@chromium.org>
wrote:

> Sorry for the delayed reply! Somehow this thread go got muted.
>
> Mac simply passes screen.availWidth and screen.availHeight straight to
> [NSWindow setFrame:display:]
>
> * thread #1: tid = 0x139e4d, 0x00007fff830d8851 AppKit`-[NSWindow
> setFrame:display:], name = 'CrBrowserMain', queue =
> 'com.apple.main-thread', stop reason = breakpoint 1.1
>
> * frame #0: 0x00007fff830d8851 AppKit`-[NSWindow setFrame:display:]
>
> frame #1: 0x00000001057f2e7f
> libchrome_main_dll.dylib`BrowserWindowCocoa::SetBounds(this=0x000000010041efa0,
> bounds=0x00007fff5fbf9c10) + 879 at browser_window_cocoa.mm:218
>
> frame #2: 0x00000001057faff4
> libchrome_main_dll.dylib`-[BrowserWindowController
> initWithBrowser:takeOwnership:](self=0x000000013febb010,
> _cmd="initWithBrowser:takeOwnership:", browser=0x000000013febea00,
> ownIt=YES) + 2308 at browser_window_controller.mm:297
>
> frame #3: 0x00000001057fa6be
> libchrome_main_dll.dylib`-[BrowserWindowController
> initWithBrowser:](self=0x000000013febb010, _cmd="initWithBrowser:",
> browser=0x000000013febea00) + 62 at browser_window_controller.mm:218
>
>
> (lldb) print cocoa_bounds
>
> (NSRect) $0 = (origin = (x = 0, y = 68), size = (width = 1680, height =
> 959))
>
> These are the same dimensions for screen.availWidth and
> screen.availHeight.

Yes, sure. But this doesn't say anything about the behavior of
window.open() or window.resizeTo() when the specified size is bigger than
what will fit. If it helps, forget about screen.availWidth and use the
number 42000 instead, the result should be the same. :-)