Javascript allows site to hide windowmanager window decorations

REOPENED
Unassigned

Status

()

Core
Widget: Gtk
--
major
REOPENED
16 years ago
5 years ago

People

(Reporter: Cesar Eduardo Barros, Unassigned)

Tracking

({sec-low})

Trunk
Future
x86
Linux
sec-low
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:low spoof], URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Created attachment 52368 [details]
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
Status: UNCONFIRMED → NEW
Component: Security: CAPS → XP Apps
Ever confirmed: true
QA Contact: bsharma → sairuh

Comment 3

16 years ago
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?

Comment 5

16 years ago
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
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.

Comment 19

16 years ago
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

Comment 20

16 years ago
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. :(
(Reporter)

Comment 22

16 years ago
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 =)
QA Contact: sairuh → jrgm

Comment 23

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

Comment 24

16 years ago
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.

Updated

16 years ago
Target Milestone: --- → mozilla1.0.1

Comment 25

16 years ago
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.

Updated

16 years ago
Target Milestone: mozilla1.0.1 → mozilla1.1beta

Updated

16 years ago
Blocks: 86194

Comment 26

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

Comment 27

15 years ago
Update target milestone to 'Future' since this missed the 'mozilla1.1beta' train.
Target Milestone: mozilla1.1beta → Future
Product: Core → Mozilla Application Suite

Updated

13 years ago
Assignee: danm.moz → nobody

Comment 28

9 years ago
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
Status: NEW → UNCONFIRMED

Comment 29

9 years ago
Do not close security bugs without testing them.
Status: UNCONFIRMED → NEW

Updated

9 years ago
Whiteboard: [sg:low spoof]

Comment 30

9 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME

Comment 32

6 years ago
window.open only opens in a tab if the page doesn't specify a size for the window.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Keywords: sec-low
You need to log in before you can comment on or make changes to this bug.