Closed
Bug 25307
Opened 25 years ago
Closed 25 years ago
Browser doesn't support drag and drop from desktop
Categories
(SeaMonkey :: UI Design, defect, P3)
SeaMonkey
UI Design
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: bruceg33mail, Assigned: mikepinkerton)
References
Details
Later versions of the Mac OS include the ability to create desktop URL files
(Internet location files). These files work with Communicator 4.7. Dragging and
dropping these files on the Mozilla browser window does not appear to work.
Mozilla should support these files.
Comment 1•25 years ago
|
||
The same applies to dragging .URL files from the Win32 desktop to Mozilla.
Eli, rather than just making this a DUP of bug 10981, "[FEATURE] Drag and drop
hookup", does it make sense to keep this bug as a blocker for that, as a
specific part of full drag and drop support, for testing purposes?
(And presumably another for window-to-window d-n-d)
Changing Platform/OS to All/All.
Changing Summary from "Browser doesn't support Internet Location Files" to
"Browser doesn't support drag and drop from desktop"
Component: Browser-General → XPApps
OS: Mac System 8.5 → All
QA Contact: nobody → elig
Hardware: Macintosh → All
Summary: Browser doesn't support Internet Location Files → Browser doesn't support drag and drop from desktop
Comment 2•25 years ago
|
||
Thanks, Sean. Assigning to Mike Pinkerton (Mac Drag & Drop dude.)
I'm personally happy resolving this as a duplicate; have lots of drag & drop test
cases (will post in next week or two), and this case certainly wouldn't get
forgotten without this bug report. Mike?
Assignee: nobody → pinkerton
Assignee | ||
Comment 3•25 years ago
|
||
the code is actually there to do this. just turn set the pref:
xpfe.dragdrop.enable
to true. It is hidden behind the pref because of a bug on win32 that i may or may
not get to by m14. Eli, should we just close out this bug?
Comment 4•25 years ago
|
||
Your call; it's fine with me.
Assignee | ||
Comment 5•25 years ago
|
||
nya nya it does now ;)
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 6•25 years ago
|
||
Thanks! (Correcting resolution; I don't believe anything was actually fixed.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 7•25 years ago
|
||
[re-resolving as LATER, as this functionality will be present by default, well,
later. ;-]
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → LATER
Comment 9•25 years ago
|
||
reopening all latered bugs
Status: VERIFIED → REOPENED
Resolution: LATER → ---
Updated•25 years ago
|
Target Milestone: --- → M20
Comment 10•25 years ago
|
||
Moving all latered bugs to M20 as ordered by project manager. Although these
bugs are now open, assigned and targetted, XPToolkit has no plans to
fix/implement them in the current release cycle, if ever.
Comment 11•25 years ago
|
||
Mass move of all M20 bugs to M30.
Comment 13•25 years ago
|
||
*** Bug 34869 has been marked as a duplicate of this bug. ***
Comment 14•25 years ago
|
||
Looks like this is being worked on in bug 37003.
Comment 15•25 years ago
|
||
Or maybe that's just linux.
Assignee | ||
Comment 16•25 years ago
|
||
hrm, this should work now, or it's a dupe of other bugs. eli is out of the
office, so i'm just going to mark this INVALID since it is covered by other, more
specific bugs.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Updated•24 years ago
|
Status: RESOLVED → VERIFIED
Comment 17•24 years ago
|
||
Rubber-stamping as verified fixed (not re-opening to invalidate; it's a valid
bug), since other bugs are tracking this issue.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•