Open Bug 303300 Opened 19 years ago Updated 4 years ago

Dragging within link follows the link on Mac but not on Windows

Categories

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P5)

defect

Tracking

()

People

(Reporter: jruderman, Unassigned)

References

Details

Steps to reproduce:
1. Find a link in a web page, such as the "Vote for this bug" link.
2. Drag within the link, e.g. from the 'o' in Vote to the 'u' in Bug.

Result: on Mac, the link is followed, but on Windows, the link is not followed.
Happens with both Firefox 1.0 and Firefox Aug 3 trunk.

Expected: consistency between platforms, unless there's a reason to be
inconsistent, such as platform standards.

Advantages of following the link:
* Links act more like buttons.
* If you drag a tiny bit (4-6 pixels) while clicking the link, the link is still
followed.  This happens often, especially for older users (?), and is somewhat
disorienting.

Advantages of not following the link:
* Consistency with IE on Windows and Safari on Mac.
Actually on windows it used to select the link text, apparently by design. I
remember a regression occuring on that which was fixed and apparently is now
broken again. It was actually a useful behavior if you discovered it.
(In reply to comment #0)

Are you saying that on a Mac, if you begin dragging a link, then drop it while
still over that link, the link will be followed?

If so, that certainly isn't correct.  D&D is a modal operation:  once commenced,
the only proper outcome is that the target will accept or reject the dropped
object.  Since nsContentAreaDragDrop explicitly rejects drops that originated in
the same content area, the result should be a no-op.  Any other outcome suggests
there's a bug in nsEventStateManager.

If you're concerned that people with shaky hands may inadvertently begin a drag
when all they meant to do is click, then this should be addressed as an
accessibility issue.  Each platform specifies the values used to determine when
a drag should start (nsILookAndFeel::eMetric_DragThresholdX and ...Y).  Perhaps
these should me made user-adjustable.
> Are you saying that on a Mac, if you begin dragging a link, then drop it while
> still over that link, the link will be followed?

Yes, that's exactly what I'm saying.

(In reply to comment #1)

>on windows it used to select the link text, apparently by design. I remember a 
>regression occuring on that which was fixed and apparently is now broken again

AFAICT, there hasn't been any regression.  When no keys are down, a link is
handled like an image:  nothing is selected and the drag begins immediately. 
OTOH, if you press Alt (or Option) the link will be treated as text, permitting
you to select part of it without starting a drag.  However, there's a fly in the
ointment:  if you release the mouse button while still over the link, it will be
followed.

I'd like to fix that so a minor feature I added would work properly.  Before
dragging a link to Bookmarks or the Desktop, you should be able to select the
portion of the link-text you want to use as its title (rather than getting the
whole thing when nothing is selected).  Until it's fixed, you can still limit
the title to the leading or trailing characters by extending your selection to
slightly beyond the beginning or end of the link.
(In reply to comment #3)
>> Are you saying that on a Mac, if you begin dragging a link, then drop it
>> while still over that link, the link will be followed?
> Yes, that's exactly what I'm saying.

I tested this on OS X v10.4.2 - event-handling in Firefox/Mac is clearly broken.  

Further evidence can be found in the Mac-only click-and-hold menu feature. After
a link's context menu is displayed, releasing the button while still over the
link will cause the link to be followed.  However, the menu will remain even
though the page below it has changed.

I've filed a new bug (#306918) which identifies this as a Mac-only event
handling error.  This bug should be closed.
Depends on: 306918
I think this is a bug.
QA Contact: drag-drop

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Severity: minor → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.