Link dragging no longer working

RESOLVED FIXED

Status

()

Core
XUL
P2
major
RESOLVED FIXED
18 years ago
18 years ago

People

(Reporter: Blake Ross, Assigned: Blake Ross)

Tracking

({regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

18 years ago
Build ID: 2000091308

Steps to Reproduce:

(1) Go to any site in the browser.
(2) Try to drag a link

The drag is never initiated apparently (judging from the lack of cursor 
feedback...)

Comment 1

18 years ago
->pinkerton
Assignee: trudelle → pinkerton
fooook. i think this was my fix for 43258. links must apparantly be returning 
consume_noDefault on the mouseDown event.

joki: any ideas of why links would be doing this?
Severity: normal → major
Status: NEW → ASSIGNED
Keywords: nsbeta3, regression
OS: Windows 98 → All
Priority: P3 → P2
Hardware: PC → All
fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 4

18 years ago
*** Bug 52612 has been marked as a duplicate of this bug. ***

Comment 5

18 years ago
It works on linux 2000091508. (Fix ok)

Comment 6

18 years ago
Regression.
2000110208.MTrunk for MacOS.
No dragging of Link is possible.
regression is probably alecf, who has bugs already.

Comment 8

18 years ago
reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 9

18 years ago
*** Bug 58968 has been marked as a duplicate of this bug. ***
ooooooh alec ;)
Assignee: pinkerton → alecf
Status: REOPENED → NEW

Comment 11

18 years ago
now wait a minute.. I didn't break link dragging all together, and link dragging
seems to work on Linux..  I just backed out my other fixes, so let's see how
tomorrow's build looks...
Status: NEW → ASSIGNED

Comment 12

18 years ago
*** Bug 58944 has been marked as a duplicate of this bug. ***

Comment 13

18 years ago
BTW - Bug 58944 was about link dragging not working on platforms *including* Linux.
(Assignee)

Comment 14

18 years ago
OK, I have a fix for this, which is good, since I seem to have broken it :).  I 
changed the enclosingLink() function in navigator.js to a more general 
findParentNode(), but this was still calling enclosingLink().  I have no idea 
why no error appeared in the console (?)
Assignee: alecf → blakeross
Status: ASSIGNED → NEW
Keywords: nsbeta3
(Assignee)

Comment 15

18 years ago
Created attachment 18665 [details] [diff] [review]
use the right function

Comment 16

18 years ago
yay, this wasn't me :)
[s]r=alecf
(Assignee)

Comment 17

18 years ago
Fix checked in.  dr reviewed in #mozilla

cc'ing brendan so he can hopefully help me understand why we didn't get a 
console error.
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
I don't know why no error message was logged.  Cc'ing mccabe.

/be

Comment 19

18 years ago
Where was this fix checked in? I did a cvs rebuild of the trunk after seeing
that this had been fixed, but my build still exhibits this problem. Linux 2000110411

Comment 20

18 years ago
This was checked-in at 2:11 PST this afternoon by blake, on the trunk. If you 
pulled after that time you should see this fix, although if you pull from 
cvs-mirror.mozilla.org (anonymous CVS) there is sometimes a lag before the
change is mirrored. 

You should be able to see whether your pull picked up this fix by looking at 
mozilla/xpfe/browser/resources/content/ navigatorDD.js, line 326

Comment 21

18 years ago
OK thanks - it appears the lag to the cvs-mirror was the culprit, as I did have
the pre-patch code. I can verify that this fix works great on Linux.

You need to log in before you can comment on or make changes to this bug.