Closed Bug 461514 Opened 16 years ago Closed 16 years ago

Difference in event.layerX behavior Windows & Mac versions

Categories

(Firefox :: General, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: mathieu.maes, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

I've been struggling with a bug in one of my javascript projects. Eventually I noticed there's a difference in behavior between the PC and Mac versions, even though both are latest version...

This difference makes it hard to use event.layerX since the Mac-version is unusable.

Reproducible: Always

Steps to Reproduce:
This HTML code:
<div id="div1" style="width:150px" onmousemove="GetPosition(e);">
<div id="div2" style="width:1000px; overflow: hidden;">
<img src=""><img src=""><img src=""><img src=""><img src="">
</div>
</div>

The javascript
<script>
function GetPosition(e)
{
   var posX = e.layerX;
}
</script>
Actual Results:  
in Windows version, posX has the mouse position relative to div2 (note: strangely enough it's not relative to div1, where the even is triggered)

in Mac version, posX appears to be relative to every individual image inside div2, even though the numbers are still way off...

Expected Results:  
Although posX should be relative to div1 logicall (my personal oppinion), the least you could expect is that the javascript engine generates the same results in both PC and Mac version...

I used 2 simple test machines where no specific themes or addons were used.
Is this still a problem in current trunk nightlies (what will become Firefox 3.1)?

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
What did you mean by marking this FIXED?

If the problem no longer occurs in current Minefield nightlies, it
should be WORKSFORME -- since (as best I can tell) no changes were
made that specifically target this bug.
I have tested with the current trunk nightlies as you suggested, and the error seems to be solved.
You need to log in before you can comment on or make changes to this bug.