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)
Core
DOM: Copy & Paste and Drag & Drop
Tracking
()
NEW
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.
Comment 1•19 years ago
|
||
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.
Comment 2•19 years ago
|
||
(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.
| Reporter | ||
Comment 3•19 years ago
|
||
> 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.
Comment 4•19 years ago
|
||
(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.
Comment 5•19 years ago
|
||
(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.
Updated•15 years ago
|
QA Contact: drag-drop
Comment 7•4 years ago
|
||
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.
Description
•