Closed
Bug 52541
Opened 25 years ago
Closed 25 years ago
Link dragging no longer working
Categories
(Core :: XUL, defect, P2)
Core
XUL
Tracking
()
RESOLVED
FIXED
People
(Reporter: bugzilla, Assigned: bugzilla)
References
Details
(Keywords: regression)
Attachments
(1 file)
|
639 bytes,
patch
|
Details | Diff | Splinter Review |
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 2•25 years ago
|
||
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
|
|
||
Comment 3•25 years ago
|
||
fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
|
||
Comment 6•25 years ago
|
||
Regression.
2000110208.MTrunk for MacOS.
No dragging of Link is possible.
|
|
||
Comment 7•25 years ago
|
||
regression is probably alecf, who has bugs already.
|
|
||
Comment 11•25 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•25 years ago
|
||
*** Bug 58944 has been marked as a duplicate of this bug. ***
|
|
||
Comment 13•25 years ago
|
||
BTW - Bug 58944 was about link dragging not working on platforms *including* Linux.
|
|
Assignee | |
Comment 14•25 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 | |
Comment 15•25 years ago
|
||
|
|
||
Comment 16•25 years ago
|
||
yay, this wasn't me :)
[s]r=alecf
|
|
Assignee | |
Comment 17•25 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
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
|
|
||
Comment 18•25 years ago
|
||
I don't know why no error message was logged. Cc'ing mccabe.
/be
|
|
||
Comment 19•25 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•25 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•25 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.
Description
•