304017 - document.onmousemove returns different values in Firefox 1.0.6 and Deer Park Alpha 2

Status: RESOLVED INVALID

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

Description

[S. Ali Tokmen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+

My web page has a sort of "window manager", which works the following way: each
time a "window" is opened, it actually creates a DIV with a table and an iFrame
inside. The user can resize or move the windows, and this is possible since each
mouse movement generates a document.onmousemove message...

The onmousemove attribute is added in the main page but also in all the iFrames,
since when the mouse is in an iFrame it should (and is) captured by the iFrame
(not the parent).

The problem is that for iFrames that are placed in different DIVs (with
therefore different left and top offsets) Firefox 1.0.6 and Deer Park Alpha 2
return different values.

For the actual Firefox, the inside frame has the following "onmousemove" function:

function handlerMM(e){
	if(!e){
		x=parseInt(window.event.clientX)+parseInt(myself.left)+5
		y=parseInt(window.event.clientY)+parseInt(myself.top)+24
	}else{
		if(document.body.clientHeight){
			scrolledLeft=document.body.scrollLeft
			scrolledTop=document.body.scrollTop
		}else{
			scrolledLeft=pageXOffset
			scrolledTop=pageYOffset}
		x=parseInt(e.pageX)-parseInt(scrolledLeft)
		y=parseInt(e.pageY)-parseInt(scrolledTop)
		if(parent.resizing[0]!=myself && parent.dragging!=myself){
			x+=parseInt(myself.left)+5
			y+=parseInt(myself.top)+25
		}else{
			x+=parent.scrolledLeft
			y+=parent.scrolledTop}}
	return parent.MouseMoved(x,y)}

Whereas in the Deer Park Alpha 2 this code should be replaced by:

function handlerMM(e){
	if(!e){
		x=parseInt(window.event.clientX)+parseInt(myself.left)+5
		y=parseInt(window.event.clientY)+parseInt(myself.top)+24
	}else{
		if(document.body.clientHeight){
			scrolledLeft=document.body.scrollLeft
			scrolledTop=document.body.scrollTop
		}else{
			scrolledLeft=pageXOffset
			scrolledTop=pageYOffset}
		x=parseInt(e.pageX)-parseInt(scrolledLeft)
		y=parseInt(e.pageY)-parseInt(scrolledTop)
		x+=parseInt(myself.left)+5
		y+=parseInt(myself.top)+25}
	return parent.MouseMoved(x,y)}

I do believe it is a bug that's been fixed in the Deer Park release (since the
first code is "weird"). The real problem is that the identifiers are as follows:

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+

and

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

So the Gecko version for the Firefox is actually higher (even though it has a
"bug").

What I would like to see would therefore be the Gecko version to be strictly
superior for this changed behavior, so the code doesn't become "fully
browser-dependent"

Thank you

Reproducible: Always

Steps to Reproduce:
1. Go to www.alishomepage.com/?lang=en
2. Try to "move" the window with Firefox and Deer Park Alpha
3. The actual (2005.aug.09) version works with Firefox and Deer Park has issues
moving the "window". If I change the code (see the first message) it will work
with Deer Park but not with Firefox

Actual Results:  
In Deer Park, the window starts "shaking"

Expected Results:  
It should have followed the mouse movement (see -> what happens with Firefox)

Comment 1

[S. Ali Tokmen]

Some additional details about the bug:

I've received one e-mail telling that the problem doesn't occur in those two 
browsers... Actually, the bug is due to the mouse position being reported 
differently *inside* the iFrames, so to see the bug "in action" you need to 
move (or resize) the window and make sure the movement "goes into" the iFrame 
(so the "inside of the window").

Also, note that the "window being active" means that its container DIV has the 
greatest z-index, and a "window being inactive" means the inverse (its z-index 
is strictly lower to the active one). I therefore think: in Deer Park, the bug 
that's been fixed has a link with or:

- whether the iFrame is in a DIV that's on the highest or lower z-index
- whether the iFrame is in a DIV that's currently being moved or resized

The second hypothesis can be verified by dragging the clock image (in this 
case "parent.resizing[0]!=myself && parent.dragging!=myself" will be TRUE for 
all iFrames) and seeing if it follows the mouse or not. Again, please make 
sure you move it on some "windows" before making your final decision about the 
event.

Thank you

Comment 2

[S. Ali Tokmen]

Attachment: ZIP file containing the two versions: one that works with Firefox and the other one with Deer Park Alpha 2

Use:

	_index_firefox.htm to launch the system with Firefox-compatible windows
(_x_ff.htm)

	_index_deerpark.htm to launch the system with Deer Park Alpha
2-compatible windows (_x_dp.htm)

The samples only have a blank content. The clock image is there, but is static
(still is useful for testing).

The "web site" content is empty. It is just a message saying either "Firefox"
or "Deer Park Alpha 2"

Comment 3

[S. Ali Tokmen]

In the attached file, to see the bug "in action":

1) Open the _index_*.htm file
2) Open a "section" using the buttons on the down side. It should normally open
the new window a bit on the right-down side of the first one.
3) Now, click on the firstly opened window (to make it gain focus) and start
resizing it (quickly). You'll see that the _index_firefox.htm file acts weirdly
in Deer Park 2 Alpha 2 and that the _index_deerpark.htm file acts weirdly in
Firefox 1.0.6.

Comment 4

[S. Ali Tokmen]

Attachment: Fixed sample

I'M TERRIBLY SORRY

The first sample as well as the first comments are actually FALSE. I've just
discovered (when testing with two windows opened in the web page) that actually
Firefox and Deer Park Alpha 2 are acting the exact opposite way: to make the
Firefox code

       parent.resizing[0]!=myself && parent.dragging!=myself

compatible with Deer Park Alpha 2, it must be replaced with

       parent.resizing[0]==myself || parent.dragging==myself

Which actually is the total inverse. Please check the attachment for testing.

This comment obsoletes all past ones, and the bug becomes "the inside iFrames
report the mouse positions in an inversed way in Firefox and Deer Park Alpha
2". There actually is no "bug" that got "fixed" by Deer Park Alpha 2. It is
Firefox's behaviour that's partially inversed in Deer Park Alpha 2.

So, this *is* a bug :o

Comment 5

[Martijn Wargers (dead)]

Attachment: iframe needed for testcase

Comment 6

[Martijn Wargers (dead)]

Attachment: testcase

Comment 7

[Martijn Wargers (dead)]

See testcase. You can drag the white box.
Drag it quickly downwards.
When you're mouse comes into the iframe you'll see a number.
That number corresponds with the e.pageY of a mousemove event in the iframe
document.
There is the difference between Mozilla1.7 and latest trunk builds.
In Mozilla1.7, you get a much higher number (probably the pageX and pageY values
of the parent document, I think) than in the trunk build.
So I think trunk builds are doing it right here and Mozilla1.7 builds are doing
it wrong.
When I remove the drag stuff and let it always follow the mousemovement, then
Mozilla1.7 acts the same way as the latest trunk build ("shaking window"). I
think another evidence that current trunk builds are doing it correctly.

Comment 8

[Martijn Wargers (dead)]

Attachment: fix for iframe page

So basically, Ali, you have an error in your script.
This is sort of the right way for the iframe script to do (no guarantees that
it is completely correct). But this gives the same 'shaky' effect for
Mozilla1.7 (but the other way around) as current trunk build has, regarding
this bug.

So basically, you're screwed here, and you've to use some lame browser
detecting stuff to get yourself out of this mess. I've tried to circumvent it
with clientX and clientY properties, but they've got the same problem in
Mozilla1.7, it seems.
Maybe someone else has a bright idea?

Comment 9

[Martijn Wargers (dead)]

By the way, I've used the findPosX and the findPosY functions for the 'fix', at:
http://www.quirksmode.org/js/findpos.html

Comment 10

[S. Ali Tokmen]

(In reply to comment #8)
> Created an attachment (id=195130) [edit]
> fix for iframe page
> So basically, Ali, you have an error in your script.

Well, theoretical error made to make it work with the current Firefox :)

> This is sort of the right way for the iframe script to do (no guarantees that
> it is completely correct). But this gives the same 'shaky' effect for
> Mozilla1.7 (but the other way around) as current trunk build has, regarding
> this bug.

Excatly. No code works right for both (sniff!)

> So basically, you're screwed here,

( no comments )

> and you've to use some lame browser
> detecting stuff to get yourself out of this mess. I've tried to circumvent it
> with clientX and clientY properties, but they've got the same problem in
> Mozilla1.7, it seems.
> Maybe someone else has a bright idea?

The only bright idea I would suggest is if you can just give a higher Gecko 
engine number for the fixed version (if you see the first comment that 
actually was the main problem for me, the "fixed" version has a lower Gecko 
version!)

I don't have problems using "lame" mechanisms, the only problem would be 
someone else in the future doing her / his own code and then experiencing the 
problem the other way round

Comment 11

[S. Ali Tokmen]

(In reply to comment #9)
> By the way, I've used the findPosX and the findPosY functions for the 'fix', at:
> http://www.quirksmode.org/js/findpos.html

Actually, I had the idea for those functions but forgot about it when I've seen
that it doesn't actually work... Note that the offset may get confused by the
fact that the iFrame is in a table itself in a DIV...

Otherwise, the bug is now "fixed" for my side since the Firefox 1.5 browser has
a strictly greater Gecko id (so I can divide the code in two parts)... One
question: does this mean that other Gecko-based browsers will also act the same
way when they have the same Gecko versions as a corresponding Firefox?

Second question: why does the mouse event change when the window is being
dragged or resized? I don't see why it does so (and, in IE it doesn't -I'll say
this even thought you don't like such reflections)

Cheers

Comment 12

[Martijn Wargers (dead)]

(In reply to comment #11)
> Note that the offset may get confused by the
> fact that the iFrame is in a table itself in a DIV...
Mozilla should not get confused about this. If it gets confused, please file a
new bug on that (if there hasn't been filed any)

> Otherwise, the bug is now "fixed" for my side since the Firefox 1.5 browser has
> a strictly greater Gecko id (so I can divide the code in two parts)... One
> question: does this mean that other Gecko-based browsers will also act the same
> way when they have the same Gecko versions as a corresponding Firefox?
Yes, I think so, but I don't know much about useragent strings. But you know
these can be spoofed, right? So that's an unreliable detection method, in
general, see also:
http://developer.mozilla.org/en/docs/DOM:window.navigator.userAgent

> Second question: why does the mouse event change when the window is being
> dragged or resized? I don't see why it does so (and, in IE it doesn't -I'll say
> this even thought you don't like such reflections)
I'm not really sure what you mean here.
With native drag events, other mouse events, like mousemove, mouseover, mouseout
are indeed not triggered, instead you get dragenter, dragover, dragleave. But
those events can't be used in html in Mozilla.
Your script prevents those drag events from happening (and it should do that,
otherwise you couldn't have resizable/draggable dhtml windows.

Comment 13

[S. Ali Tokmen]

(In reply to comment #12)

> Yes, I think so, but I don't know much about useragent strings. But you know
> these can be spoofed, right? So that's an unreliable detection method, in
> general, see also:
> http://developer.mozilla.org/en/docs/DOM:window.navigator.userAgent

I know they can be, the best known and most widely used "spoofed browser" 
being Opera. But most configurations won't have such tweaks, I think (and 
hope).

> I'm not really sure what you mean here.

Don't think much about it... We'll see what happens with time :)

---

OK, based on your recommendations I've fixed the code as following:

First, I've seperated the old, bogus Gecko with the new, fixed one

	var is_Moz=parseInt(navigator.userAgent.substr
(navigator.userAgent.indexOf("Gecko")+6))>20030600
	var is_new_Moz=parseInt(navigator.userAgent.substr
(navigator.userAgent.indexOf("Gecko")+6))>20050900

And then, the code has been made conscious of the change

	if(document.body.clientHeight){
		scrolledLeft=document.body.scrollLeft
		scrolledTop=document.body.scrollTop
	}else{
		scrolledLeft=pageXOffset
		scrolledTop=pageYOffset}
	x=parseInt(e.pageX)-parseInt(scrolledLeft)
	y=parseInt(e.pageY)-parseInt(scrolledTop)
	if(parent.is_Moz && !parent.is_new_Moz){
		if(parent.resizing[0]!=myself && parent.dragging!=myself){
			x+=parseInt(myself.left)+5
			y+=parseInt(myself.top)+25
		}else{
			x+=parent.scrolledLeft
			y+=parent.scrolledTop}
	}else{
		x+=parseInt(r_myself.offsetLeft)+5
		y+=parseInt(r_myself.offsetTop)+24}}

Seems to work pretty well with Firefox 1.0 as well as 1.5 Beta 1 (and the 
other browsers I have installed -IE, Opera, Konqueror, ... ). I've made it 
online a few minutes ago.

In the meanwhile, now I'm pretty sure it's a big problem on the old Firefox 
side: if you open multiple windows, the scroll (and resize) are both "glided" 
of a few pixels in some cases (which I wasn't able of predicting, probably a 
problem with the "old" code)

I'm marking this bug as being "invalid", if you insist it could also 
be "already fixed"

Thank you