103454 - Javascript allows site to hide windowmanager window decorations

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect)

Description

[Cesar Eduardo Barros]

Offshot from bug 69290 as requested by [e-mail]

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.

Comment 1

[Cesar Eduardo Barros]

Attachment: Minimal testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.  :)

Comment 3

[R.K.Aa.]

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

Comment 4

[Boris Zbarsky [:bzbarsky]]

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?

Comment 5

[ron]

bug confirmed with twm

Comment 6

[sairuh (rarely reading bugmail)]

->jag? bryner?

Comment 7

[Mitchell Stoltz (not reading bugmail)]

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

Comment 8

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 9

[Brian Ryner (not reading)]

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

Comment 10

[Christopher Blizzard (:blizzard)]

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?

Comment 11

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 12

[Christopher Blizzard (:blizzard)]

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);
   }

Comment 13

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 14

[Christopher Blizzard (:blizzard)]

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

Comment 15

[Mitchell Stoltz (not reading bugmail)]

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

Comment 16

[Christopher Blizzard (:blizzard)]

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?

Comment 17

[Boris Zbarsky [:bzbarsky]]

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.

Comment 18

[Mitchell Stoltz (not reading bugmail)]

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

Comment 19

[jag (Peter Annema)]

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 :-)

Comment 20

[Dan M]

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.

Comment 21

[Christopher Blizzard (:blizzard)]

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. :(

Comment 22

[Cesar Eduardo Barros]

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 =)

Comment 23

[Jesse Ruderman]

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

Comment 24

[Jesse Ruderman]

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.

Comment 25

[Travis Crump]

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.

Comment 26

[Jesse Ruderman]

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

Comment 27

[Juan José Mata]

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

Comment 28

[Robert Kaiser]

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

Comment 29

[Jesse Ruderman]

Do not close security bugs without testing them.

Comment 30

[Robert Kaiser]

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.

Comment 31

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 32

[Jesse Ruderman]

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

Comment 33

[Andrei Purice]

Hey Cesar,
Can you still reproduce this issue or should we close it?

Comment 34

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:stransky, since the bug has high severity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 35

[Martin Stránský [:stransky] (ni? me)]

Should be fixed now.