171482 - window.screenX and window.screenY do not function correctly before window is shown

Status: RESOLVED INVALID

(Core :: XUL, defect)

Description

[Brian Ryner (not reading)]

Spun off from bug 171459 (gtk only).  If you run the following js before a
window is shown:

window.screenX = 50;
dump(window.screenX);

you will get back 0.  This is because we always return 0,0 from
nsWindow::GetScreenBounds if it's called before mMozArea is mapped (visible). 
Note that the window _will_ appear at an x position of 50, because we call
gtk_widget_set_uposition with the coordinate.  However, if you do this:

window.screenX = 50;
window.screenY = 75;

the window will appear at (0, 75).  This happens because when screenY is set, we
call GetScreenBounds, fill in the new coordinate, then call Move(), making the
incorrect 0 coordinate from GetScreenBounds the new x position.

Comment 1

[Gérard Talbot]

It is my understanding that screenX and screenY window properties are read-only
and cannot be set. At least, the documentation converge on this:

http://developer.netscape.com/docs/manuals/js/client/jsref/window.htm#1203394

http://www.mozilla.org/docs/dom/domref/dom_window_ref104.html#1020670

http://www.bekkoame.ne.jp/~hamba/mozilla/Window/screenY.html

screenX and screenY can be used to set the position of a secondary popup child
window via the open method.

http://developer.netscape.com/docs/technote/javascript/window/index.html#meth_open

The usual and normal way to [re-]position a main parent window is to use the
moveTo method.

Comment 2

[Gérard Talbot]

There might be weaknesses or confusion in the listed documentations. After
trying attachment 93792 [details] , it appears that screenX and screenY are settable via
script.

Comment 3

[Gérard Talbot]

Is this bug still active? If so, can you try this meta-testcase and see if the
bug still exists?

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

Comment 4

[Brian Ryner (not reading)]

We should retest, this may have been fixed by a recent change to the window
coordinates cache.

Comment 5

[Gérard Talbot]

I do not use Linux, no testcase was submitted in this bug and this bug looks
pretty close to bug 160791.

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 6

[Brian Ryner (not reading)]

No, this is different.  Note that it doesn't matter _where_ you try to position
the window.  If you position it by setting screenX and screenY separately
_before_ the window is shown, the last-set coordinate will be what you set it
to, but the other coordinate will be incorrectly set to 0.

Comment 7

[Brian Ryner (not reading)]

Just retested by editing toolkit/content/customizeToolbar.js and changing:

  window.moveTo(screenX, screenY);

to

  window.screenX = screenX;
  window.screenY = screenY;

in repositionDialog().  (This is in a Phoenix build, obviously).

The bug still exists.

Comment 8

[Gérard Talbot]

Argh... I forgot to CC this bug to me. So, I just read your comment. 

FYI, I filed bug 176905 yesterday and I submited and documented there should be
no other way to reposition/relocate an existing window than by using moveTo or
moveBy.

Comment 9

[Jonathan]

Can this be closed now, seeing as https://bugzilla.mozilla.org/show_bug.cgi?id=176905 is resolved?

Comment 10

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

The bug assignee didn't login in Bugzilla in the last 7 months.
:enndeakin, could you have a look please?
For more information, please visit auto_nag documentation.