firefox onmousemove and dragging issues

D

davefromalbury

I'm trying to create a basic slider and I'm having absolutely no luck
in firefox. Could someone please offer some hints as to what could be
wrong? I think it's to do with the focus change upon clicking, but I'm
not sure. It's just not dragging properly. It's at

http://users.tpg.com.au/sobey1/slide.html

Cheers
dave
 
P

Patient Guy

I'm trying to create a basic slider and I'm having absolutely no luck
in firefox. Could someone please offer some hints as to what could be
wrong? I think it's to do with the focus change upon clicking, but I'm
not sure. It's just not dragging properly. It's at

http://users.tpg.com.au/sobey1/slide.html


Seems to be dragging okay to me with the movement right to left to right of
the mouse. You might want some sort of onmouseout event to break the link
between the mouse and the slider knob when the cursor leaves any part of
the slider.


....
 
D

davefromalbury

i'm using firefox 1.5, is that what you checked it with? Maybe it's
just my browser being wierd, but I don't think so.

Cheers
dave
 
V

VK

davefromalbury said:
I'm trying to create a basic slider and I'm having absolutely no luck
in firefox. Could someone please offer some hints as to what could be
wrong? I think it's to do with the focus change upon clicking, but I'm
not sure. It's just not dragging properly. It's at

http://users.tpg.com.au/sobey1/slide.html

No it's not a focus issue. When you drag mouse over an part of your
page (thus passing mouse over with button pressed), you first fire
"selectstart" event (system is trying to select the text). It fails on
image and then fires "ondragstart" event (system is trying to move an
atomic object). It fails on it either - at this moment cursor changes
to "No-Drag" ("Unavailable" by Windows). You need to release the mouse
to let the call for mousemove to go through.

This is the standard consequence of events, but up to date the only
browser which asknowledges it is that terrible borken non-standard
Micro$oft IE :): here you have onselectstart and ondragstart event
handlers to cancel these events programmatically.

There are different tricks to kill ondragstart on different browsers.
Very well can be that there are some official documented ways for that
which I'm not aware of. Personally since NN4 I'm using "background
trick" for images: instead of making an image to be the content, I'm
making it background-image of an element w/o content. But I used it for
div/span only, so I do not know how will it behave on a table cell.
 
P

Patient Guy

i'm using firefox 1.5, is that what you checked it with? Maybe it's
just my browser being wierd, but I don't think so.

Yes, I develop with FF 1.5, and check with IE6. When the mouse cursor is
"attached" to the slider knob by a click of the cursor over the knob, it
slides with the cursor in its left-right-left movement. When the cursor
moves off the slider, the knob continues its left-right movement in FF1.5,
but not in IE6, from what I can see. Clicking on the slider knob again to
"detach" cursor movement from slider knob movement works in both browsers,
probably the effect you are looking for.
 
D

davefromalbury

i was just about to post the answer you suggested :) Yes, it works
perfectly: as you said, you simply make the image a background image
with css.

cheers
dave
 
G

Gérard Talbot

VK wrote :
No it's not a focus issue. When you drag mouse over an part of your
page (thus passing mouse over with button pressed), you first fire
"selectstart" event (system is trying to select the text). It fails on
image and then fires "ondragstart" event (system is trying to move an
atomic object). It fails on it either - at this moment cursor changes
to "No-Drag" ("Unavailable" by Windows).

selectstart and ondragstart are not standards event types and are not
supported by Firefox.
In Fx, the OP needs to cancel default action of the mousedown. Anyway,
the markup code is not that good either.

You need to release the mouse
to let the call for mousemove to go through.

He needs to register the mousemove event once and only once the
mousedown event has been triggered, fired.

This is the standard consequence of events, but up to date the only
browser which asknowledges it is that terrible borken non-standard
Micro$oft IE :): here you have onselectstart and ondragstart event
handlers to cancel these events programmatically.

Once he registered an event listener (DOM 2 Events) on the image,

evt.preventDefault()

http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-Event-preventDefault

so that default action of the mouse is neutralized.
There are different tricks to kill ondragstart on different browsers.
Very well can be that there are some official documented ways for that
which I'm not aware of. Personally since NN4 I'm using "background
trick" for images: instead of making an image to be the content, I'm
making it background-image of an element w/o content. But I used it for
div/span only, so I do not know how will it behave on a table cell.

I think if he could get rid of the table and cells, it would be better.

Gérard
 
V

VK

Gérard Talbot said:
selectstart and ondragstart are not standards event types and are not
supported by Firefox.

Which is a major flaw (one of) of the current Gecko architecture.
Once he registered an event listener (DOM 2 Events) on the image,
evt.preventDefault()

preventDefault of what? Default action on "mousedown" is not
selectionstart.
selectionstart starts when you move mouse for at least one pixel in any
direction *with mouse button down*. There is no such listener in Gesco
model which you could override. This is the main reason why even
semi-working drag solutions for Gesco are continuosly on the "border
line of selection" - you move mouse a bit quicklier or trickier and
voila - it starts select the content instead of dragging it.

I'm ready to believe that modern Gecko allows you to prevent selection
by canceling mousedown event (I did not play drag-drop scripts
recently). But in such case it just a non-standard way to fix W3C event
model flaw.
 
T

Thomas 'PointedEars' Lahn

VK said:
Which is a major flaw (one of) of the current Gecko architecture.

No, it is not. And even if they were standard event types, no UA would
be obliged to implement it, even if it implemented other W3C DOM Events.


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top