Offshot from bug 69290 as requested by jruderman@hmc.edu The site maximizes the window and moves it so the titlebar and the window borders are out of the screen with Enlightenment 0.16.5 (Debian package 0.16.5-4) using the default theme (BrushedMetal-Tigert). Relevant javascript: if (top.frames.length != 0) top.location = self.document.location; self.moveTo(0,0); self.resizeTo(screen.availWidth,screen.availHeight); Comment from original bug: > cesarb: please should file a bug on the fact that a window can become large enough to make the titlebar disappear. If a site did that and also told Mozilla not to display menus and toolbars, a site could create a full-screen browser window with no UI. Some porn sites *already* exploit a similar (but intentional) bug in Internet Explorer in order to make it hard for you to close their pop-up ads before reading them. Mozilla's policy is that web pages shouldn't be able to make their windows larger than a maximized window without chrome privs (see "JavaScript Features Requiring Privileges" on http://www.mozilla.org/projects/security/components/signed-scripts.html), and from your description it sounds like that isn't working correctly under Enlightenment.

Over to XP apps. It sounds like the problem here is us not getting the right maximal window size.... ccing blizzard who may know something useful about windowmanagers and the like. :)

with Sawfish WM the window does not exceed visible screen area when using the testcase. Screen size is estimated correct.

I see the problem with AfterStep. Maybe the window manager is just told "make this the size of the screen" or "make this maximized" and different WMs treat that differently?

bug confirmed with twm

->jag? bryner?

This could be a security issue because it makes for better content spoofing. Upping the severity.

You could actually state the problem even simpler...just do a window.moveTo(0,0) and you've pushed the titlebar off the screen. The problem is not with availWidth and availHeight, the problem is that moveTo appears to treat the bottom edge of the titlebar as the top of the window (Y=0 for the window). moveTo(0,5) puts the titlebar partially off the screen. We're using the wrong reference point.

I remember fighting with this awhile back. blizzard, how is this _supposed_ to work?

Well, from the standpoint of the MoveTo the corner is the corner of the window, not the window manager. At least, that's the way the code works. Should MoveTo() include the window manager bar?

Chris, That doesn't seem to be true on any other platform. On Mac and Windows, the corner of the window is at the top edge of the OS-generated titlebar, not the top of our chrome. MoveTo() should include the window manager's titlebar in order to prevent moving the titlebar off the screen.

X sucks? Seriously, though, this is a hard problem to solve in a global way and it's highly window manager dependent. Using the example in this bug my window manager won't hide the decorations. Others might, though. Here's a possible patch that might fix other window managers: Index: nsWindow.cpp =================================================================== RCS file: /cvsroot/mozilla/widget/src/gtk/nsWindow.cpp,v retrieving revision 1.351 diff -u -r1.351 nsWindow.cpp --- nsWindow.cpp 2001/09/28 20:11:18 1.351 +++ nsWindow.cpp 2001/10/12 19:43:36 @@ -2723,6 +2723,9 @@ InvalidateWindowPos(); } } + else if (mIsToplevel) { + gtk_widget_set_uposition(mShell, aX, aY); + } else if (mSuperWin) { gdk_window_move(mSuperWin->shell_window, aX, aY); }

I just noticed that window.open("someurl","name","screenX=0,screenY=0"); does not put the titlebar off the top edge of the screen, but moveTo(0,0) does. So they're using different points of reference on the window.

Not with my window manager. Like I said, this is very window manager dependent. Have you tried my patch? Does it help?

I tried the patch above; on my Linux system it does not fix the problem.

Ugh. I completely screwed that up. It turns out the code that's right above it already checks for the mIsToplevel and uses set_uposition. So the answer is that you can't get it right if it isn't working now. What window manager are you using?

Chris, comments in this bug mention twm and AfterStep (which is twm-derived, if I recall correctly). Chances are this affects fvwm (which is twm-derived) as well.

I'm using Enlightenment (in Redhat 6.1) and I'm seeing the problem.

I don't think this is something we can fix on our end (other than trying to figure out which windowmanager is running and having some kind of blacklist or something for the ones we need to clean up after). I suggest wontfix, but -> danm for another look. Just bounce it back if you don't want it :-)

Expected behaviour from, like, Windows Navigator 1.0 days, is that javascript:moveTo(x,y) coordinates are in reference to the top-left, outside most extreme corner of the OS's window. But as has already been pointed out, different window managers treat this differently. I have Sawfish and Enlightenment on my box. One works with us the way you'd hope, the other doesn't. Sounds like my Window Manager guru Blizzard has already decided this is simply unfixable. Gonna close this "won't fix" soon unless someone has a clever idea.

Yeah, this is bad. Just as an example, Sun's JVM tries to do this so you can tell what is an applet window and what isn't. It gets it so wrong it's amazing. Sometimes windows are moved offscreen entirely, sometimes they aren't depending on the window manager. It's impossible to get right. :(

Clever idea: hidden prefs for the size of the four sides, so a power user can specify the size of the titlebar and window borders. Clever idea 2: the blacklisting someone mentioned. It's possible to detect Enlightenment (it has a plugin API) Clever idea 3: Find out why is Enlightenment doing that, and fix it in Enlightenmnet, or maybe add a window hint to tell mozilla the size of the four sides. Clever idea 4: Don't allow sites to get "full screen" (if my screen is 1024x768, there's no way a site can get bigger than that without being at least partially out of the screen). Clever idea 5: I'm out of clever ideas for today =)

See also bug 104303, "script can make a window larger than the screen (Linux)".

Does Mozilla's window-cascading code keep the window manager decorations on the screen? If it does, maybe we could borrow some of that code. If we can't fix this, we should discuss this problem with window manager makers and/or file bugs against the buggier window managers.

Just like to point out a workaround for Enlightenment if that affects the severity. The original post stated that "If a site did that and also told Mozilla not to display menus and toolbars, a site could create a full-screen browser window with no UI." However regardless of what is done to the window, the UI of Alt-(left-click) to move the window, and Alt-(right-click) to get the Close/Annihilate/Iconify/Raise/Lower....Window Size->... menu will still exist and allow the user to sufficently manipulate the window.

See also bug 130872, "Always create new windows within screen boundaries" (Mac).

Update target milestone to 'Future' since this missed the 'mozilla1.1beta' train.

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

Do not close security bugs without testing them.

1) It WFM (KDE4), and I'd actually see this as a window manager bug, not even a Mozilla one (see comment #19 and comment #20 that even propose to WONTFIX it), but 2) it's surely NOT a SeaMonkey-specific problem so it's misfiled nowadays in any case. I'll throw this at Widget:GTK for now, as it's apparently happening only on Linux.

It doesn't look this is very easy to exploit this anymore. You can only moveTo() windows that were opened by the page, and these end up in tabs by default. If someone still has this problem they should reopen the bug.

window.open only opens in a tab if the page doesn't specify a size for the window.