Closed Bug 66347 Opened 24 years ago Closed 4 years ago

window.screenX & window.screenY return totally wrong values on Linux.

Categories

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

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INACTIVE

People

(Reporter: desale, Assigned: blizzard)

Details

(Keywords: dom0, testcase)

Attachments

(2 files)

BUILDS: 2001-01-17-17-MTEST STEPS TO REPRODUCE: 1] Please load testcase I'm attaching. [On Linux] 2] Click first button "Move window to X=0, Y=0". [You'll see alert showing screenX, ScreenY values] 3] Click button " Move window to X=50, Y=50" [You'll see alert again] 4] Click all the buttons one by one. [Everytime you'll se alerts with screenX and screenY values] EXPECTED RESULTS: ScreenX, and screenY values shown on alerts should match to X & Y values on buttons you are clicking. ACTUAL RESULTS ScreenX, and screenY values shown on alerts do not match to X & Y values on buttons you are clicking. ATTACHED TESTCASE FOLLOWING.
Attached file Testcase (deleted) —
WORKSFORME, there's a typo in the testcase tho, the 400x400 button moves the window to 400x300 and that's what the alert shows.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Johhney, I tested it again on RedHat 6.0, and with 2001-01-29-11-MTEST. And its happening again. did you try it on Linux ? Its there only on Linux. Re-opening. If you still don't see, please let me know. I'll have tolook into seetings of my computer.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Ok, I see this on linux, I was testing on windows earlier w/o realizing this was linux only. Reassigning to danm.
Assignee: jst → danm
Status: REOPENED → NEW
Keywords: dom0
->pavlov, cc blizzard. Test works if each operation is done separately, fails if done together in same function. Dan says that this sounds related to superwin stuff you guys did, are you deferring handling of window movement, or could you have introduced some latency into updating the current location?
Assignee: danm → pavlov
Sounds like some crack that I want to smoke!
Assignee: pavlov → blizzard
Attached patch patch (deleted) — Splinter Review
The problem was that when we moved the window the cached positions weren't being invalidated so you would get the old cached values. The reason that the cached values weren't updated is that it doesn't happen until you return to the mainloop. If you do a move() followed immediately by a getscreenbounds() it would never return to the mainloop in between. Works now. Adding bryner + pavlov for a quick review. Two line patch, guys. Should be easy.
Status: NEW → ASSIGNED
easy enough.. sr=alecf
r=dbaron
Target Milestone: --- → mozilla0.9
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Tested this one with 08-28-08 with Linux & its still not working. Reopening bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Fixing milestone. If the comment about a typo in the testcase is correct, only window.screenX is failing.
Keywords: testcase
Target Milestone: mozilla0.9 → mozilla0.9.7
bryner, is it possible that this was fixed with your scrolling fix in the last couple of weeks?
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Possible, but I can't say for sure. Needs to be tested again.
Nope, this bug is still here.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
<window id="main-window" xmlns:html="http://www.w3.org/1999/xhtml" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" persist="width height screenX screenY" title="&app.name.short;" windowtype="mozapp:messxula"> This code does not remember the X,Y positions when I quit the application (only tested on Linux). It always positions the window at 0,0 when i try to persist screenX and screenY. Is this a result of this bug?
Target Milestone: mozilla0.9.9 → ---
QA Contact: desale → general
Status: REOPENED → RESOLVED
Closed: 24 years ago4 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: