Closed Bug 160791 Opened 18 years ago Closed 16 years ago

window.screenX & window.screenY could not be set to accurate values.


(Core :: DOM: Core & HTML, defect)

Not set





(Reporter: desale, Assigned: danm.moz)





(1 file)

window.screenX & window.screenY could not be set to accurate values.

BUILDS: 2002-08-02-06-1.0

1] Please load testcase from URL or testcase I'm going to attach.
2] Please Enter window.screenX value & Please Enter window.screenY value.
3] Click button "Move Window to above cordinates".
4] Click button "Show values of Window.screenX & Window.screenY".

Alert shows values of Window.screenX & Window.screenY exactly what you entered 
in textboxes.
Alert shows values of Window.screenX & Window.screenY very different than you 
entered in textboxes. You can see, window also moves to wrong co-ordinates [you 
will notice if you enter 0,0 for X,Y].
This means window.screenX & window.screenY could not be set to accurate values.
Attached file testcase
WORKSFORME. Are you sure you don't have the pref "Move or resize existing
windows" unset (in Advanced->Scripts & Plugins in the pref panel)?
Closed: 18 years ago
Resolution: --- → WORKSFORME
Oh, never mind, didn't realize this was Linux only...

Resolution: WORKSFORME → ---
Punting over to danm so that he can have a look at why the Linux window code
doesn't move the window to the right coordinates.
Assignee: jst → danm
this doesn't seem to be as bad as reported with linux build 20020802, blackbox WM.

the testcase works as long as you don't try to move any part of the window off
the screen, with the exception that it doesn't seem to mind moving the statusbar
off the bottom of the screen (perhaps this is the desired behavior... I dunno)

0,0 works.  anything beyond a certain X and Y value move it to that particular X
and Y value.  negative values move the window to 0,0
Testcase does not work for me inside the screen area too.
What's the pattern of incorrect values? Is it off by the size of your window
borders, for instance? I suspect this is one of those window manager issues.
Related perhaps to bug 23779?

Note that I can't see this problem on my linux box. It's not exactly WFM.
Attempts to set any of the window position attributes return a JS error, and
it's not the same thing that happens when the pref to allow scripts moving
windows is false. I haven't been able to track down the source of the error.
Prashant D., I don't have/use Linux. 
Could you try first resizing the window so that a reposition of the window (via
screenX/Y) will not "push" any content out of the client area (browser inner
viewport) of the browser, and then try your test case? 

The test case under such circumstances WFM: XP Pro here, build 2002091808.

Also, please examine carefully this image coming from

There is a security issue implied regarding a window which is [re-]positioned
outside of the browser viewport.

Andrew S. in comment #5 described exactly what I noticed.

I can document further these questions if needed.
Prashant D., please ignore comment #8. I did not read your comment #6. Sorry for
the spam
is this related to what is described in bug 171482?
Re: comment #10:
Yes, it could be the case (same bug as this 160791 bug) but I can't be sure
since there are no test case in bug 171482 and I don't use/have Linux, so I
really can not say.

Nevertheless, let's say you try to set the screenX and screenY to 100 in the
following 2 cases.

a) If the window takes/uses/occupies the available width of the screen, then the
returned screenX value will be 0, not 100 and the window will not move to the right.

b) If the window takes/uses/occupies the available height of the screen, then
the returned screenY value will be 0, not 100 and the window will not move
toward the bottom.

XP Pro SP1 with build 2002100710 here.
If this bug is still active, then you can try this meta-testcase for positioning
popup windows.
I do not use Linux, no testcase was submitted in this bug and this bug looks
pretty close to bug 171482. Can someone update what is going on with this bug?

Note that 
Exceeding any of the boundaries of the screen (to hide some or all of a window)
requires signed JavaScript, so a window won't move past the screen boundaries."
found at

My findings lead me to believe that the browser always makes sure that

window.screenX + screen.outerWidth <= screen.availLeft + screen.availWidth

when creating a secondary child popup window via the method. And
if such equation is no longer valid, then the excess is taken away from the
requested window.screenX value. The same equation seems to be the case, rule
along the y-axis. Idem est the browser always tries to comply, respect the equation
window.screenY + screen.outerHeight <= screen.availTop + screen.availHeight

Bug 176342 nabs a subtility that bypass this experimentally discovered equation.
There has not been any activity in this bug for a long time and as far as I can
understand things, the bug was initially related to position correcting
mechanisms insuring that a secondary window would be completely displayed within
screen viewing area. 

Resolving as WORKSFORME
Closed: 18 years ago16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.