Closed Bug 107471 Opened 24 years ago Closed 24 years ago

Popup Windows Automatically Resize to Fill Screen

Categories

(Core :: DOM: Events, defect)

defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: tommybee99, Assigned: danm.moz)

References

()

Details

(Keywords: helpwanted, regression)

Attachments

(1 file)

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?
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.
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
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.
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.
reassign
again
Assignee: asa → joki
QA Contact: doronr → vladimire
Actually popups are mostly danm's territory.
Assignee: joki → danm
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).
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
Target Milestone: --- → Future
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
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.
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?
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.
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.
Status: RESOLVED → REOPENED
Keywords: mozilla1.0
Resolution: WORKSFORME → ---
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 ago24 years ago
Keywords: helpwanted
Resolution: --- → FIXED
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
YAY! Verified on trunk build 2002033008 on Mac OS 9.2.2! Good job, danm! Tommy
Status: RESOLVED → VERIFIED
Target Milestone: Future → mozilla1.0
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: