1595962 - Make window.{innerWidth,innerHeight} compliant with the spec

Status: NEW

(Core :: DOM: CSS Object Model, task)

Description

[Hiroyuki Ikezoe (:hiro)]

Currently it is writable in chrome privilege but as far as I can tell, we have no longer code which mutates the property in our tree. Some of automated tests still change them though.

Comment 1

[Hiroyuki Ikezoe (:hiro)]

FWIW, I just tried to do this bug for bug 1598487. A try result looks reasonable other than browser_roundedWindow_open_max_inner.js. The test supposes that resize events are fired on window.innerHeight changes, but apparently it shouldn't.

Here is the try.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=fd532959b632fb0d58d39abe238c2cbcc96e2812

That's said, some codes in comm-central rely on the fact that window.inner{Width,Height} is writable. So it's not yet the time to this change to me (I might be able to take time to change the comm-central code in some day).

Comment 2

[Hiroyuki Ikezoe (:hiro)]

Attachment: The patch I used in the try

Just for reference.

Comment 3

[Hiroyuki Ikezoe (:hiro)]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #1)

That's said, some codes in comm-central rely on the fact that window.inner{Width,Height} is writable. So it's not yet the time to this change to me (I might be able to take time to change the comm-central code in some day).

Filed bug 1601811 and bug 1601812.

Comment 4

[Botond Ballo [:botond]]

If comm-central call sites are the only thing holding this up, perhaps we could have conditional logic that uses the ICB size for Thunderbird/Seamonkey and the minimum scale size for Firefox?

Comment 5

[Hiroyuki Ikezoe (:hiro)]

That's actually possible, but that means we still keep window.inner{Width,Height} writable, it will be messy. Of cource Firefox doesn't mutate the value to change window sizes though. We could probably ifdef in webidl for comm-central but it would be more messy.