Closed
Bug 107471
Opened 24 years ago
Closed 24 years ago
Popup Windows Automatically Resize to Fill Screen
Categories
(Core :: DOM: Events, defect)
Core
DOM: Events
Tracking
()
VERIFIED
FIXED
mozilla1.0
People
(Reporter: tommybee99, Assigned: danm.moz)
References
()
Details
(Keywords: helpwanted, regression)
Attachments
(1 file)
|
1.11 KB,
text/html
|
Details |
Mozilla 0.9.5, Mac OS 9.2.1
On many web sites (including the test case), popup windows are supposed to be
displayed but are not. They show up in the Tasks menu but cannot be made
visible by any means. In this particular case:
1) Load http://www.cbs.com/primetime/bigbrother2/
2) Click "Click here to watch the un-aired episode" (or something to that effect)
3) Watch as some activity takes place on screen but no window appears.
4) Check the Tasks menu to find a second window with CBS.com as a title. Try to
bring this to the front.
5) Close the existing CBS.com window. Notice that the other window still does
not show.
6) Check the Tasks menu again. The second window is still there but not visible
on screen.
This is a serious problem in that it prevents some sites from presenting valid
information. This problem was found both using a profile created by Netscape
6.1 and a clean one as well.
Reporter, did you add the line, 'user_pref("dom.disable_open_during_load", true);
' to your prefs.js file?
| Reporter | ||
Comment 2•24 years ago
|
||
Greg: I have yet to manually edit my prefs.js file. In addition, Netscape 6.2
has no problems rendering this and other popup windows using the same profile.
I may try a nightly in the next couple of days to see if the problem exists
there as well.
Comment 3•24 years ago
|
||
I am seeing this as well (actually mine are popping up in the lower right hand
corner with just the upper left hand corner of the box visible) but extensively
its the same..
I have added the no popups on loading preference.
Platform: PC
oS: Windows 98
Mozilla Build: 2001102903
Marking NEW.
Severity: major → critical
Status: UNCONFIRMED → NEW
Component: Browser-General → DOM Events
Ever confirmed: true
Keywords: regression,
ui
OS: Mac System 9.x → All
Hardware: Macintosh → All
Comment 4•24 years ago
|
||
I'm seeing a pop up window fail with Mozilla 0.9.5/Windows 2000 on the following
page:
http://www.techsoup.org/articlepage.cfm?ArticleId=208&topicid=6
Steps to reproduce:
Select one of the links from that page that intends to produce a pop up window.
Result:
No pop up, but 'Something happens' when the link is followed, and Mozilla is
mildly disturbed thereafter - eg the 'Stop' button vanishes for the tab
concerned, the tab title reports 'loading' until the vanished stop button is
pressed, the 'right mouse click' context sensitive menu's appearance is delayed
until the mouse cursor is moved subsequent to the click, other differently coded
pop-up windows, displayed in other tabs, are found to have ceased to work. eg on
this page:
http://www.bathspa.ac.uk/markhelp/fileman/file_index.html
I've not added the 'no pop ups on loading' preference.
Comment 5•24 years ago
|
||
Ignore my last comment - this works for me now. For some reason that wasn't
trapped Mozilla needed a restart using task manager to kill it, and recent
builds have been so good I'd not expected it to be ill at all.
Comment 6•24 years ago
|
||
reassign
Comment 9•24 years ago
|
||
I've been seeing this very frequently (Mozilla 0.9.5, Mac OS 9.1). The
new window is visible for a fraction of a second, then becomes invisible
and inaccessible (but the window still exists, and its scripts are still
running). Interestingly, the innerHeight and innerWidth properties are
often (but not always) set to 0. Maybe the window is invisible because
it's been resized to zero width!
I'm attaching a page that demonstrates the bug. If you have trouble
replicating it, try copying the URL of the attachment to your clipboard,
quitting and restarting Mozilla, and pasting the URL in the location bar
(because the bug sometimes seems to go away after surfing for a while).
| Reporter | ||
Comment 10•24 years ago
|
||
I just ran the attachment on build 2001121008 (Mac OS 9.2.2), and instead of
hiding the window, it filled almost the entire screen (718 x 915). I've seen
this problem with other pop-ups as well, and the URL provided initially with the
bug also exhibits this problem.
Revising summary to reflect new problem. I would file this as a separate bug,
but since it affects the same circumstances I don't think it warrants a new bug.
Summary: Popup Windows In Tasks Menu but Not On Screen → Popup Windows Automatically Resize to Fill Screen
Comment 11•24 years ago
|
||
Tested on windows 98 2002-02-02-08-trunk,
this time every time you open up the window the height becomes 50 less then it
was before...
On 2002-02-04-12-trunk linux build the testcase is working as described...
The reason for the height change is probably because the testcase uses
innerHeight to set the new height, and inner height does not include the menu
and title bar, while the height and width of window.open is the outer dimensions
of the window...
The correct code should have used outerHeight...
Anyhow the original report works for me.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Comment 12•24 years ago
|
||
Please undo the change to RESOLVED; this is still defective on Mac.
(I tried the attachment with build #2002020408, and the new window
had dimensions 715x913 instead of the expected 300x400.)
> the height and width of window.open is the outer dimensions
> of the window...
>
> The correct code should have used outerHeight...
Are you sure? The original specification states that "height=" and
"width=" are the same as "innerHeight=" and "innerWidth=" when used
in the windowFeatures parameter.
Has some standards body specified a new and non-backward-compatible
definition for "height=" and "width="?
Excerpted from
http://developer.netscape.com/docs/manuals/communicator/jsref/win1.htm#1152596:
innerHeight [...] replaces height, which remains for backwards compatibility.
innerWidth [...] replaces width, which remains for backwards compatibility.
Comment 13•24 years ago
|
||
yeah, in exactly the same place it says
innerHeight - "Specifies the height, in pixels, of the window's content area" :)
As opposed to
outerHeight - "Specifies the vertical dimension, in pixels, of the outside
boundary of the window"
Content area is where the content is being displayed, and does not include the
menues..
This works for me on Mac OS 9.x build 2002-02-04-08-trunk, very strange... What
is your mac OS?
| Reporter | ||
Comment 14•24 years ago
|
||
Testing this attachment with Mozilla 0.9.8 (build 2002020405) on Mac OS 9.2.2
still produces the full screen effect. I'll try it on a build I downloaded
today as well.
| Reporter | ||
Comment 15•24 years ago
|
||
Both the URL and the attached test case are still broken with build 2002022208
on Mac OS 9.2.2. Reopening and adding mozilla1.0 keyword.
| Assignee | ||
Comment 16•24 years ago
|
||
What is this bug, anyway? The summary sounds like bug 112230, which I fixed
March 18. The bug description and test cases seem unrelated. Still, with a
recent build, I don't see any of the problems mentioned. The original test case
opens a popup window; I couldn't find a link in the test case from comment 4
that tried to open a popup, not that I spent like ten minutes trying; the test
case from comment 9 works fine for me; and the summary bug, seemingly some other
bug, also works fine. Closing again.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Keywords: helpwanted
Resolution: --- → FIXED
| Reporter | ||
Comment 17•24 years ago
|
||
danm,
The bug started off to report an issue with popup windows not appearing at all,
with the test case in the URL field being an example. Once that issue went
away, the same example (as well as others) displayed the problem of popup
windows being maximized all the way, so I edited the summary and the bug went on
from there.
I don't feel like booting up my Mac tonight (I haven't even plugged it in since
I came back here -- was gone for Spring Break), and the weekend is supposed to
be stormy here, so I probably won't be able to verify the correction for another
couple of weeks, but it sounds like bug 112230 is practically identical, so I'm
hoping this will show up as fixed once I download a new build.
Thanks for tracking this one down!
Tommy
| Reporter | ||
Comment 18•24 years ago
|
||
YAY! Verified on trunk build 2002033008 on Mac OS 9.2.2! Good job, danm!
Tommy
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•