Open Bug 103454 Opened 19 years ago Updated 8 years ago

Javascript allows site to hide windowmanager window decorations


(Core :: Widget: Gtk, defect)

Not set





(Reporter: cesarb, Unassigned)




(Keywords: sec-low, Whiteboard: [sg:low spoof])


(1 file)

Offshot from bug 69290 as requested by

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;

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, and 
from your description it sounds like that isn't working correctly under 
Attached file Minimal testcase
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.  :)
Assignee: mstoltz → pchen
Component: Security: CAPS → XP Apps
Ever confirmed: true
QA Contact: bsharma → sairuh
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?
Assignee: pchen → jaggernaut
This could be a security issue because it makes for better content spoofing.
Upping the severity.
Severity: normal → major
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
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?
  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 @@
+  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"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 :-)
Assignee: jaggernaut → danm
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
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

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 =)
QA Contact: sairuh → jrgm
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.
Target Milestone: --- → mozilla1.0.1
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.
Target Milestone: mozilla1.0.1 → mozilla1.1beta
Blocks: useragent
See also bug 130872, "Always create new windows within screen boundaries" (Mac).
Update target milestone to 'Future' since this missed the 'mozilla1.1beta' train.
Target Milestone: mozilla1.1beta → Future
Product: Core → Mozilla Application Suite
Assignee: danm.moz → nobody
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.
Whiteboard: [sg:low spoof]
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.
Component: UI Design → Widget: Gtk
Product: SeaMonkey → Core
QA Contact: jrgmorrison → gtk
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.
Closed: 9 years ago
Resolution: --- → WORKSFORME only opens in a tab if the page doesn't specify a size for the window.
Resolution: WORKSFORME → ---
You need to log in before you can comment on or make changes to this bug.