Closed
Bug 257036
Opened 20 years ago
Closed 20 years ago
window.open sets wrong vertical size, depending on event-source
Categories
(Core Graveyard :: GFX: Win32, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: ken2006, Unassigned)
References
()
Details
Attachments
(4 files)
Snapshot of toolbar with too many firefox decorations
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040824
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040824
The example URL contains 3 pop-up event methods:
1) in-page (inline) executed
2) A-tag inline onclick invocation
3) A-tag onclick function call
All of them call excatl;y the same window.open command, however, only #2
generates the correct verical dimension of the new window (for me anyway). The
others generate a size that is too large (roughly 2x).
Reproducible: Always
Steps to Reproduce:
1.Load given URL
2.Click on sample links.
this only started sometime into the 1.8 builds. 1.7 is okay.
I'm rating this major for two reasons: app-programmers (me) depend on correctly
sized windows, and, I feel it may point to a lower level problem (that may have
other un-anticipated / yet-unknown event/DOM consequences).
ps - this is truly a bizarre problem :-)
|
Reporter | |
Comment 1•20 years ago
|
||
Changed sample to add two variants of function call:
onClick="testFunc"
onClick="testFunc()"
Example two *does* work, but one does not (behaves same as page-inline sample).
|
|
Reporter | |
Updated•20 years ago
|
Flags: blocking1.8a4+
|
||
Comment 2•20 years ago
|
||
worksforme with linux trunk 2004091107
only drivers can set blocking flags(+). you can request(?) them.
Flags: blocking1.8a4+
|
||
Comment 3•20 years ago
|
||
Not sure if this is the same or not, but with
Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10
on http://demo:guide@nddemo.peregrine.com/nm/
the toolbar is taller by about the height of the status bar as compared to
previous versions (eg Firefox 0.8.x, 0.9.x, etc...)
You will notice a white band at the bottom of the window that should not be there.
|
||
Comment 5•20 years ago
|
||
Worksforme on Linux as well. Over to Win32 GFX.
Assignee: general → win32
Component: DOM: Level 0 → GFX: Win32
|
|
Reporter | |
Comment 6•20 years ago
|
||
Hmm, the behavior on this changed slightly after I deleted panels.rdf and
restarted... now, only link number two on the demo URL opens with the wrong
size.. the body-inline script (runs on page load) works fine, so does link
number 1 and three...
This bug may be related to bug #260098, who behavior also changed after I
deleted panels.rdf.
|
|
||
Comment 7•20 years ago
|
||
I still see the issue at http://demo:guide@nddemo.peregrine.com with
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041026
Firefox/1.0RC1
The code to open the window is:
var toolbar_height = 100;
var toolbar_width = 400;
var tool_x = (screen.width - toolbar_width) / 2;
var tool_y = 15;
var attr = "width=" + toolbar_width + ",height=" + toolbar_height +
",resizeable=no" + ",left=" + tool_x + ",top=" + tool_y;
self.ktoolbar = window.open("", ktoolbarName, attr);
If I remove 20 from the toolbar_height, it comes out at the right height. Or
is the status bar supposed to fill in that space?
This has worked properly for years. Not sure why it is breaking now.
Flags: blocking-aviary1.0?
|
||
Comment 8•20 years ago
|
||
I'm unable reproduce this problem on windows XP on today's build. Is this win2K
only?
|
|
||
Comment 9•20 years ago
|
||
I will try today's build in Win2k.
|
|
||
Comment 10•20 years ago
|
||
Today it is worse than my last update. Using:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041105
Firefox/0.9.1+
I am attaching a screenshot.
|
|
||
Comment 11•20 years ago
|
||
unable to reproduce with the latest windows builds. If you can reproduce, please
provide a testcase that fails with the latest branch build. thanks.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Resolution: --- → WORKSFORME
|
|
Reporter | |
Comment 12•20 years ago
|
||
Matthew, try deleting your panels.rdf file with 'er shut down then restart Moz -
does that work?.... You could also try deleteing compreg.dat and XUL.MFL - these
files seem exteremly vulnerable to corruption during a crash and cause all kinds
of ... problems.
|
|
||
Comment 13•20 years ago
|
||
I deleted everything in
C:\Documents and Settings\mdarwin\Application Data\Mozilla
before I ran the last test case.
Re: Comment #11
- Please see http://demo:guide@nddemo.peregrine.com/nm/
- Unblock popup windows
- Then press reload
- Screen shot from Comment #10 is produced
|
||
Comment 14•20 years ago
|
||
This is ok with IE6 and NS7.2, just with Firefox 1.0, there is an extra white
bar at the bottom.
|
|
||
Comment 15•20 years ago
|
||
I have simplified this test case as much as possible and put it at
http://www.mdarwin.ca/test/toolbar.html
<HTML>
<SCRIPT LANGUAGE="Javascript">
window.open("", "foo", "width=400,height=100");
</SCRIPT>
<TITLE> Window opening test </TITLE>
<BODY>
Enable pop-ups to see this test case.
</BODY>
</HTML>
In Mozilla 1.7.3 it opens the correct height.
In Firefox 1.0 it opens ~25 pixels too big.
|
||
Comment 16•20 years ago
|
||
The initial comment in this bug sounds like bug 262411, which is still open and
for good reason. Subsequent comments seem unrelated -- an observation that
Mozilla has a minimum window size? Please don't take this comment as an
invitation to similarly confuse the issue in 262411. I'm merely trying to
reassure Ken about his closed bug.
Matthew: are you referring to the fact that Mozilla has a minimum window size?
It always has. If it's a bit larger in Firefox than in Moz 1.7.3, it doesn't
seem like cause for alarm. Try the attached testcase. With Firefox 1.0 I get
results like these:
spec: 85x400, actual inner: 150x400, outer: 154x406
spec: 95x400, actual inner: 150x400, outer: 154x406
spec: 105x400, actual inner: 150x400, outer: 159x406
spec: 115x400, actual inner: 150x400, outer: 169x406
spec: 125x400, actual inner: 150x400, outer: 179x406
spec: 135x400, actual inner: 150x400, outer: 189x406
spec: 145x400, actual inner: 150x400, outer: 199x406
spec: 155x400, actual inner: 155x400, outer: 209x406
spec: 165x400, actual inner: 165x400, outer: 219x406
spec: 175x400, actual inner: 175x400, outer: 229x406
As you can see the overall window height is pinned to at least 100 pixels, and
the content window to 150. A little funny stuff happens at sizes in between. As
it's always been.
Differences between Mozilla and Firefox could be related to chrome. You'll
certainly get different numbers if you have adjusted, for example, your
dom.disable_window_open_feature.* prefs.
|
|
||
Comment 17•20 years ago
|
||
Ever since Netscape 3.x, the minimum visible window hight has always been
~100 pixels. The code I wrote 5 years ago worked just fine until Firefox .10.
I want to create a window with the absolute smallest vertical height.
It makes no sense that the minimum window height is 20 pixels larger now,
according to your test case:
Firefox 1.0:
spec: 85x400, actual inner: 150x400, outer: 122x400
spec: 95x400, actual inner: 150x400, outer: 122x400
spec: 105x400, actual inner: 150x400, outer: 127x400
spec: 115x400, actual inner: 150x400, outer: 137x400
spec: 125x400, actual inner: 150x400, outer: 147x400
spec: 135x400, actual inner: 150x400, outer: 157x400
spec: 145x400, actual inner: 150x400, outer: 167x400
spec: 155x400, actual inner: 155x400, outer: 177x400
spec: 165x400, actual inner: 165x400, outer: 187x400
spec: 175x400, actual inner: 175x400, outer: 197x400
Mozilla 1.7.3:
spec: 85x400, actual inner: 150x400, outer: 102x400
spec: 95x400, actual inner: 150x400, outer: 102x400
spec: 105x400, actual inner: 150x400, outer: 107x400
spec: 115x400, actual inner: 150x400, outer: 117x400
spec: 125x400, actual inner: 150x400, outer: 127x400
spec: 135x400, actual inner: 150x400, outer: 137x400
spec: 145x400, actual inner: 150x400, outer: 147x400
spec: 155x400, actual inner: 155x400, outer: 157x400
spec: 165x400, actual inner: 165x400, outer: 167x400
spec: 175x400, actual inner: 175x400, outer: 177x400
|
|
||
Comment 18•20 years ago
|
||
Just for curiosity, I tried running your test case on IE and Netscape
Communicator 3.04 Neither loads test test case javascript properly, so I've
attached as screenshot instead.
This is under Windows 98.
|
|
||
Comment 19•20 years ago
|
||
here are the results under Mozilla 1.8a5 Windows 2000:
spec: 85x400, actual inner: 100x400, outer: 128x408
spec: 95x400, actual inner: 100x400, outer: 128x408
spec: 105x400, actual inner: 105x400, outer: 133x408
spec: 115x400, actual inner: 115x400, outer: 143x408
spec: 125x400, actual inner: 125x400, outer: 153x408
spec: 135x400, actual inner: 135x400, outer: 163x408
spec: 145x400, actual inner: 145x400, outer: 173x408
spec: 155x400, actual inner: 155x400, outer: 183x408
spec: 165x400, actual inner: 165x400, outer: 193x408
spec: 175x400, actual inner: 175x400, outer: 203x408
|
|
||
Comment 20•20 years ago
|
||
Finally I've reached the bottom of this. Yes there is a problem with short
windows in Firefox 1.0. Because of bug 259192, a window opened given an inner
height (as in 'height=100') will be padded by the height of a statusbar (22
pixels in my case). A very short window will not display the statusbar (bug
255388) though space is still allocated for it. Rumour has it this has all been
fixed on the trunk in bug 217477, but not in Firefox 1.0.
Alrighty then. *This* bug, 257036, still lives on as bug 262411: something very
odd is happening with window sizes under certain conditions. Comments in this
bug from comment 7 onward are actually about that other problem, and to those
three bugs I scatter thee.
|
||
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•