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)
Core
Layout
Tracking
()
REOPENED
People
(Reporter: mozilla_alt_support, Unassigned)
References
()
Details
(Keywords: regression, testcase)
Attachments
(2 files)
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()
|
||
Comment 1•20 years ago
|
||
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
|
||
Comment 4•20 years ago
|
||
see also bug 257036
*** Bug 262959 has been marked as a duplicate of this bug. ***
|
||
Updated•20 years ago
|
Keywords: regression,
testcase
|
|
||
Comment 7•20 years ago
|
||
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.
|
|
||
Comment 8•20 years ago
|
||
Seing this on Mac os X as well.
Flags: blocking1.8b?
OS: Windows NT → All
Hardware: PC → All
|
|
||
Comment 9•20 years ago
|
||
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)
|
||
Comment 10•20 years ago
|
||
The testcase didn't really add any new information, but I don't know why you'd
call it "wrong."
|
|
||
Comment 11•20 years ago
|
||
*** Bug 274696 has been marked as a duplicate of this bug. ***
|
||
Comment 12•20 years ago
|
||
(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.
|
|
||
Comment 13•20 years ago
|
||
So can someone narrow down when this regressed, using the 1.8a* milestones and
nightlies from http://archive.mozilla.org ?
|
|
||
Comment 14•20 years ago
|
||
This wfm: trunk build 20050128, windows xp, can anyone verify?
|
||
Comment 15•20 years ago
|
||
also wfm for me on: Mozilla 1.8b
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050128
|
|
||
Comment 16•20 years ago
|
||
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
|
|
||
Updated•20 years ago
|
Flags: blocking1.8b?
|
Reporter | |
Comment 17•20 years ago
|
||
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 → ---
|
||
Comment 18•20 years ago
|
||
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. :(
|
||
Comment 19•20 years ago
|
||
Seems like getting a testcase that reliably shows the problem would be needed
for this to be fixed.
Flags: blocking1.8b? → blocking1.8b-
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•