Bug 10796 – [DOM 0] height and innerHeight (parameters in window.open() call) should correspond to the same measurement

• Status: NEW
• Component: DOM

[Gérard Talbot (no longer involved)]

Back in April 2006, I noted this wrong, incorrect behavior of Safari 2.02 (416.13). I forgot to file a bug on this.

Description:
------------
height and innerHeight should equate to the same measurement. Right now, in Safari 2.02 (416.3), height and outerHeight equate, correspond to the same measurement: that's wrong.

width and innerWidth should equate to the same measurement. Right now, in Safari 2.02 (416.3), width and outer Width equate, correspond to the same measurement: that's wrong.

Steps to reproduce:
-------------------
1- Load provided URL
2- With the form, define a height for a sub-window and then, in the sub-window, compare/verify that the outerHeight is equal to the height value which is wrong

Actual results:
---------------
height and outerHeight are the same value. height and innerHeight are not the same value.

Expected results:
-----------------
height value and innerHeight value should be the same in a sub-window. outerHeight should always be different (and greater than) from height value.

More documentation on this precise issue:
-----------------------------------------

"height: Specifies the height of the content area, viewing area of the new secondary window in pixels. The height value includes the height of the horizontal scrollbar if present."
http://www.gtalbot.org/BugzillaSection/Bug195867GDR_WindowOpen.html#GrpPositionSizeFeatures

Diagram:
http://www.gtalbot.org/BugzillaSection/Bug195867GDR_WindowOpen.html#OuterHeightVersusHeightOrInnerHeight


"height: Specifies the height of the content area, viewing area of the new secondary window in pixels. The height value includes the height of the horizontal scrollbar if present."
http://developer.mozilla.org/en/docs/DOM:window.open#Position_and_size_features

Diagram:
http://developer.mozilla.org/en/docs/DOM:window.open#Note_on_outerHeight_versus_height

https://bugzilla.mozilla.org/show_bug.cgi?id=232531#c3

https://bugzilla.mozilla.org/show_bug.cgi?id=174314#c4

{
Backwards compatibility:
    * open(height,width) equates to the new open(innerHeight,innerWidth)
(...)
Note: innerHeight and innerWidth options replace the height and width options,
but they remain for backwards compatibility."
JAVASCRIPT 1.2 NEW WINDOW METHODS AND PROPERTIES
http://web.archive.org/web/20040603142741/http://developer.netscape.com/docs/technote/javascript/window/index.html#meth_open

The given definition/description of width/height at this page
http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/window.html#1202786
is not sufficiently explicit, precise.
}

[Gérard Talbot (no longer involved)]

.

[Ahmad Saleem]

I am able to reproduce this bug in Safari 15.6 on macOS 12.5 using URL field test case.

** STEPS TO REPRODUCE **

1) Open URL
2) Type '700' in height
3) Click on "Create Pop-up Window according to these settings"

<< EXPECTED RESULT >>

In pop-up window, innerheight would be same as type of 700.

<< ACTUAL RESULT >>

Safari 15.6 showed innerheight of 900

NOTE - For other browsers, only Firefox Nightly 106 showed innerheight matched with the typed value of "Height". While Chrome Canary 106 was similar to Safari 15.6 and showed different innerheight.

I am going to change status to "New" but if this is something where Firefox need to change their behavior to align with DOM3 or DOM4 spec then please mark this bug accordingly. Thanks!

[Radar WebKit Bug Importer]

<rdar://problem/98215028>

[Gérard Talbot (no longer involved)]

{
(...)
For legacy reasons, there are some aliases of some feature names. To normalize a feature name name, switch on name:

"screenx"
    Return "left". 
"screeny"
    Return "top". 
"innerwidth"
    Return "width". 
"innerheight"
    Return "height". 
(...)
}

coming from
HTML5 / 7.3 The Window object
7.3.1 APIs for creating and navigating browsing contexts by name
https://html.spec.whatwg.org/multipage/window-object.html#normalizing-the-feature-name

There are also many tests on window legacy size features inside
http://wpt.live/html/browsers/the-window-object/open-close/
e.g.

http://wpt.live/html/browsers/the-window-object/open-close/open-features-tokenization-innerheight-innerwidth.html

Results:
https://wpt.fyi/results/html/browsers/the-window-object/open-close/open-features-tokenization-innerheight-innerwidth.html?label=experimental&label=master&aligned

Firefox fails that test most probably because of a preset (about:config)
dom.disable_window* property. Chrome and Edge pass this test, I'd say (402 ~= 401) .

The original author of such test commented:
<!-- user agents are not required to support open features other than `noopener` and on some platforms position and size features don't make sense -->

Anyway... this should be a low priority kind of bug report... even 16 years later :)