66483 - window.screenX does not work on first window (Linux)

Status: RESOLVED WONTFIX

(Core :: Widget: Gtk, defect)

Description

[Dan]

What happens:

I created an example package and tried to set window.screenX but the window's 
position always starts out at the left edge of the screen but setting 
window.screenY works as expected with the Y position following the setting of 
window.screenY. This behaivor only effects the very first window and not any of 
it's children. Source code for the example package is below:

Expected result:

The starting position of the very first window in X would follow the setting of 
window.screenX.

Example.xul:

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin" type="text/css"?>

<!DOCTYPE window> 

<window id="Example"
        title="screenX Example"
        xmlns:html="http://www.w3.org/TR/REC-html40"
        xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
		onload="InitiallizeExample();"
		orient="vertical"
		width="720"   height="80"
		>
		
	<script language="JavaScript" 
src="chrome://example/content/example.js"/>

	<text id="mytext" value="Nothing has set my value yet"/>

</window>

Example.js:

function InitiallizeExample()
{
	window.screenX = 500;
	window.screenY = 590;
}

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

->XPToolkit/Widgets

Please try in a build more recent than M18.

Comment 2

[Blake Ross]

-> danm
jst, thoughts?

Comment 3

[John Morrison]

This does work in a current build on win2k. But it will never work on Linux, 
since we defer to the WM for the positioning of new windows, I do believe. 
danm?

Comment 4

[Dan M]

The capability to move a window isn't disconnected on *nix builds; just that one 
place where it's used to restore the window's persistent position when first 
shown. The sample code above should work.

I'm getting the same behaviour with my current build using Redhat/Enlightenment. 
That is, as written, it moves in the Y direction, but not the X. If you swap the 
order of movement in InitiallizeExample(), then it picks up the X but not the Y. 
So it's just missing the first movement. In fact I believe I can see the window 
flashing in the requested position but then settling for good in the half wrong 
position.

It looks to me like perhaps the window manager is kicking in just after we start 
executing the onload JS, and overriding the first quick move. Kinda unfortunate. 
(Also unfortunate, my common lament these days: I'm the guy to hold on to this 
one, but I won't have time to get to it soon. Futuring and helpwanting.)

Comment 5

[:aceman]

This still exists, even on Gtk3.

The point is to run the code from onload handler. Only Y position is restored, not X.
If you run the code from the onload handler but via onTimeout(code(), 0), both positions are restored properly. BUT the movement of the window is visible. It restores on some initial position and then is moved to the new position. On e.g. Windows the code can be run without setTimeout and the window seems placed at the wanted position on first appearance.

Also, if I reference window.outerWidth in that onload handler, sometimes it produces an error in the console: Warning: ReferenceError: reference to undefined property window.outerWidth
In cases when it does not produce that error, both .outerWidth and .outerHeight return a value of 1 (which is bogus).

Comment 6

[:aceman]

So why will this not be fixed?

Comment 7

[Jim Mathies [:jimm]]

Well, it's been open for over fifteen years and no one has felt compelled to work on it. I think if you want to get this fixed you should consider working on it yourself. We can leave the bug open but that's not really going to change anything.