[Set Window Rect] Why result is integral & round down

[yezhizhen]

Continuing from #1909 (comment).
Based on test expectation, the set parameter can be floats. But the result is expected to floor down to integer.

The question is:

1. Why should the result be integral? https://github.com/web-platform-tests/wpt/blob/7da2887747da3ae5215b88e22d61a0fb69e13acb/webdriver/tests/classic/set_window_rect/set.py#L41
2. Why do we round down? https://github.com/web-platform-tests/wpt/blob/7da2887747da3ae5215b88e22d61a0fb69e13acb/webdriver/tests/classic/set_window_rect/set.py#L160

It seems neither is specified in Spec.

[whimboo]

When I check the definition on the Window interface I cannot see that the values can be float. They are defined as:

 [Replaceable] readonly attribute long outerWidth;
 [Replaceable] readonly attribute long outerHeight;

@jgraham why do you think that those can be float? Note that also window.moveBy() only accepts long and no float. So basically the browser should internally round the value so that no float is returned.

[yezhizhen]

When I check the definition on the Window interface I cannot see that the values can be float.

Thanks Henrik! That really makes sense.

2. Why do we round down? https://github.com/web-platform-tests/wpt/blob/7da2887747da3ae5215b88e22d61a0fb69e13acb/webdriver/tests/classic/set_window_rect/set.py#L160

But what do you think about the second question? I suggest we reopen #1909, and change above test expectation to "invalid args" instead.
cc @xiaochengh

[jgraham]

• @jgraham why do you think that those can be float?

Well I was assuming that the OS window size is specified in physical pixels, whereas the specs work in CSS Pixels. When you have a device pixel ratio > 1 that would allow non-integer window sizes. But maybe all browsers refuse to be resized to widths that are not whole CSS Pixels? It's hard to tell from CSSOM-view because all these APIs are from times when one CSS Pixel was always once device pixel for screens.

If you look at the gecko implementation it is in fact rounding a float value to an integer internally.

• Why do we round down?

The spec says that you should set to the nearest available size. I agree that doesn't necessarily mean rounding down from 0.5, but actually the spec is weaker than that; you're allowed to set the window size to anything as long as that's the nearest available size. So if you only allowed resizing in 10px increments then you'd set it to the nearest 10px. More plausibly, some browsers have a minimum window width which you can't resize below. So per the exact letter of the spec the only test you can really write here is to give a lot of inputs over a range and assert that for whatever outputs are possible, the one you get for any given input is the closest to that input value e.g. if your browser had a minimum window width of 500px and then supported 10px increments you could test every pixel size between 0 and 1000 and check that all values <505 resulted in outputs of 500, 506-514 resulted in 510 and so on. But it is still implementation-defined what happens with 505.

I suspect an earlier version of the spec tried to just set window.outerWidth, so it assumed the float-to-int conversion for long types: https://webidl.spec.whatwg.org/#js-long. That indeed ends up calling IntegerPart which means it always rounds down.

So I think the test as written is wrong, but writing a pedantically correct test is more effort than it's worth.

[gsnedders]

Well I was assuming that the OS window size is specified in physical pixels, whereas the specs work in CSS Pixels. When you have a device pixel ratio > 1 that would allow non-integer window sizes. But maybe all browsers refuse to be resized to widths that are not whole CSS Pixels? It's hard to tell from CSSOM-view because all these APIs are from times when one CSS Pixel was always once device pixel for screens.

I'm pretty certain WebKit can have non-integral window sizes, we just round-to-zero for outerWidth.

Filing an issue on CSSOM View for this isn't unreasonable, but from a WebDriver point-of-view it makes sense to just match CSSOM View.