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

RESOLVED WORKSFORME

Status

()

Core
DOM: Core & HTML
RESOLVED WORKSFORME
16 years ago
14 years ago

People

(Reporter: Prashant Desale, Assigned: Dan M)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

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

BUILDS: 2002-08-02-06-1.0

STEPS TO REPRODUCE:
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".

EXPECTED RESULTS:
Alert shows values of Window.screenX & Window.screenY exactly what you entered 
in textboxes.
 
ACTUAL RESULTS:
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.
(Reporter)

Comment 1

16 years ago
Created attachment 93792 [details]
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)?
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
Oh, never mind, didn't realize this was Linux only...

Reopening...
Status: RESOLVED → REOPENED
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
Status: REOPENED → NEW

Comment 5

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

Comment 6

16 years ago
Testcase does not work for me inside the screen area too.
(Assignee)

Comment 7

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

Comment 8

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

http://developer.netscape.com/docs/technote/javascript/window/images/display_screen.gif

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.

Comment 9

16 years ago
Prashant D., please ignore comment #8. I did not read your comment #6. Sorry for
the spam

Comment 10

16 years ago
is this related to what is described in bug 171482?

Comment 11

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

Comment 12

16 years ago
If this bug is still active, then you can try this meta-testcase for positioning
popup windows.

http://jibbering.com/du/MozPopupHelpTestcaseDebugger.html

Comment 13

16 years ago
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 
"Security
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
http://developer.netscape.com/docs/manuals/js/client/jsref/window.htm#1202631

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 window.open() 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.

Comment 14

14 years ago
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
Status: NEW → RESOLVED
Last Resolved: 16 years ago14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.