149077 - window.open produces incorrectly sized child-window

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[Philip Underwood]

At the above url observe that "child" or "sub" windows created using
window.open(URL,"display",'width=500,height=550') produce a smaller window than
requested.  For example, look at B & W photos and select San Francisco.  Note
the scroll bars.  Now try this in IE5.5, NN6.2.2, Opera 6.02, ... and see that
that a fixed size window opens and the photos (images) are fully displayed and
the controls to view different images are in the opened window.

Comment 1

[Daniel Wang]

*** Bug 165534 has been marked as a duplicate of this bug. ***

Comment 2

[Benjamin Smedberg]

from bug 165534:
***
The problem seems to be that IE takes the Javascript defined window size to be
the canas area of the window, excluding the width of scroll bars. Mozilla works
on the basis that the pop up window size is the Javascript defined window size
plus the size of scroll bars. This means than Mozilla always draws pop ups that
are about 20px too short and 20px too narrow, with ugly scroll bars. 
***

->DOM Level 0, because this is a function of the 'window' object.  How did NS4.x
compute the window size?  Mozilla should probably follow this behavior, unless
there is a w3c spec. for window.open()

(the URL given in the bug report is no longer valid)

Comment 3

[Gérard Talbot]

Can you try with this meta-testcase?

http://jibbering.com/du/MozPopupHelpTestcaseDebugger.html

width, innerWidth, height and innerHeight refer to the browser viewport, the
content area of the window and that includes scrollbars if present.

NS 4.x documentation, AFAIK, mentioned that scrollbars were part of the content
area. In all browsers I know, scrollbars are part of the content area of the
element which generates, creates scrollbars.

Canvas (W3C): "the space where the formatting structure is rendered; the canvas
is infinite for each dimension of the space." The canvas is the entire "surface"
on which the document is laid out.

Content area, viewing area, rendering area, client area (MSDN), viewport (W3C),
scrolling view, document view, browser window: all of these are loose synonyms
and generally refer to the same thing.

"Mozilla works on the basis that the pop up window size is the Javascript
defined window size plus the size of scroll bars. This means than Mozilla always
draws pop ups that are about 20px too short and 20px too narrow, with ugly
scroll bars." 
Sorry but that's not true.

Comment 4

[Gérard Talbot]

Attachment: An 181px width x 182px height image

This will be the image acting as the url of child secondary popup windows. Next
attachment is going to be the parent document.

Comment 5

[Gérard Talbot]

Attachment: Main parent window of the testcase

If the parent vs child interrelated windows work well on bugzilla.mozilla.org,
then I'll comment on the testcase later. I'm not sure this will work.

Comment 6

[Gérard Talbot]

I have another demo case which identifies in a reliable manner the browser
default values of margin, border, padding for the document root element and the
body element. When the image is loaded into child secondary popup window taking
into consideration these browser default values, then image is perfectly
centered and the popup is correctly sized, fitting the content.

The submitted testcase does not work on the server for MSIE 6 but you can try it
locally (you'll need to rename the image file).

Comment 7

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 8

[Steven Storey]

Attachment: same problem

Thanks from tendustvirzie1974.