Open Bug 262411 Opened 20 years ago Updated 2 years ago

Popup shown too large if generated from OnLoad Event and document.write

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
REOPENED

People

(Reporter: mozilla_alt_support, Unassigned)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(2 files)

testcase misbehaves in Moz1.8a4-ish trunk builds
540 bytes, text/html
Details
Testcase
639 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a4) Gecko/20040927
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a4) Gecko/20040927

If I show a PopUp Window with a subroutine using document.write and given Size
it is shown too high if i call this subroutine from the OnLoad() Event in the
Body Statement. If i call the same subroutine with OnClick then everything is ok.

I found the Bug in Mozilla 1.8A4, The Version 1.8A2 and 1.73 is Ok, i have not
tried 1.8A3.



Reproducible: Always
Steps to Reproduce:
1. Disable PopUp Blocking if enabled
2. Enable JavaScript if disabled
3. Go to http://212.1.43.17/moz17bug.html

Actual Results:  
A Popupwindow is shown with an invalid height.
You can close it and call the same subroutine with a OnClick in the Page.

Expected Results:  
Correct (Same) Size if called from OnLoad() and OnClick()
Worksforme in a current trunk Linux build.
Curious. I see it too. Mozilla 1.8a2 and Firefox Aviary 20041005 builds both are
relatively well behaved, but the Mozilla 1.8a4 20041006-06 trunk build opens the
window to a different size depending on how the window was opened. A simpler
testcase goes like this:

<html><body>
<script>
function openWin() {
  var w = window.open("", "", "height=200,width=200");
  document.getElementById("size").firstChild.data =
    "outer: "+w.outerHeight+"x"+w.outerWidth+
    ". inner: "+w.innerHeight+"x"+w.innerWidth;
}
</script>
<a href="javascript:openWin()">href</a>
<a href="#" onclick="openWin()">click</a>
<a href="javascript:openWin()" onclick="openWin(); return true">combined</a>
<br>
<span id="size">size</span>
</body></html>

In Mozilla 1.8a4, a window opened in the load handler is sized the same as the
window opened by the href link: 118 pixels too tall, regardless of the requested
size *. All events I tested (mouseover, mouseup, mousedown, keypress, click)
size the window correctly. The "combined" case opens one window in each size.

(* Unless the requested size is very small. Then weird things start happening.
But that's been true for a longtime.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
see also bug 257036
*** Bug 262959 has been marked as a duplicate of this bug. ***
This bug still present on Mozilla 1.8a5 on Windows 2000.
Keywords: regression, testcase
Attached file Testcase — 
Ok, here is another testcase showing that the popup get the wrong height
(should be 300px), it contains a red div with height 300px, so you can easily
see if its correct or not.
Seing this on Mac os X as well.
Flags: blocking1.8b?
OS: Windows NT → All
Hardware: PC → All
Can somebody please tell me if my testcase is completly wrong here or not? 

Since the dimensions in it are wrong, but i dont use either onload or
document.write (well, actually the testcase uses that, but the dimensions will
be wrong anyway if i take it out)
The testcase didn't really add any new information, but I don't know why you'd
call it "wrong."
*** Bug 274696 has been marked as a duplicate of this bug. ***
(From update of bug 274696)
>You can make it get the width wrong by opening the sidebar.
>So for some reason it's not hiding the chrome when calculating the inner sizes.
So can someone narrow down when this regressed, using the 1.8a* milestones and
nightlies from http://archive.mozilla.org ?
This wfm: trunk build 20050128, windows xp, can anyone verify?
also wfm for me on: Mozilla 1.8b
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050128
First testcase works correctly in Firefox Windows nightly build 20040120, but
misbehaves in 20040119. We never answered Boris' question about when it began,
but we seem to know when it ended. Resolving.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Flags: blocking1.8b?
It is not completely fixed.

On my System with todays mozilla nightly build, it looks first fixed,
but if i try it 10 Times with the reload button,
one or two times it is wrong as before and 8 to 9 times it is fixed.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I can confirm it's still broken with 2005020106 (win2k).

This regressed between 1.8a2 (2004071408) and 1.8a3 (2004081709). I tried to
narrow it down further, but archive.mozilla.org doesn't have a single windows
build between those dates. Sorry. :(
Flags: blocking1.8b?
Seems like getting a testcase that reliably shows the problem would be needed
for this to be fixed.
Flags: blocking1.8b? → blocking1.8b-
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: