Closed Bug 37410 Opened 25 years ago Closed 24 years ago

[feature] create internet shortcut when dragging url to desktop

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: mikepinkerton, Assigned: mikepinkerton)

References

Details

(Keywords: helpwanted, relnote, Whiteboard: [nsbeta2+] [6/22] 1 day)

In 4.x, when you drag a link to the desktop, an internet shortcut file is created. Need to do this in mozilla. Mac/linux just do the right thing by default, but win32 needs its little hand held and needs to be told to create a file. This means clients need to add an extra data flavor (or something!) to indicate to the win32 drag service that it needs to advertise the "create a file" flavor, and that the data should be an internet shortcut.
furthermore, on linux this flavor probably needs to be translated into _NETSCAPE_URL so other apps know what we're giving it, besides just plain text. accepting for m16.
Status: NEW → ASSIGNED
Whiteboard: tfd 5/2
Target Milestone: --- → M16
pushing out, the code is written but the shell won't accept the drag. i don't know what i'm doing wrong.
Keywords: helpwanted
Whiteboard: tfd 5/2 → tfd 5/5
win32
dean and i are struggling with this...
Whiteboard: tfd 5/5 → tfd 5/12
Did it. Long time ago. For some reason the shell is never calling IDataObject->QueryGetData(). Other apps call QueryGetData() and the shell calls IDropSource->QueryContinueDrag() and IDropSource->GiveFeedback(), but not QGD. At least that's as far as I was able to get. Mike, did you get any further?
adam suggested looking into EnumFormatEtc(), and how strange it is that it's not being called....ever. Not even when I ask the data object viewer to enum the formats does this get called.....weird.
I noticed that this wasn't getting called on a drag, but I thought that it was because QueryGetData() wasn't being called. Is there a problem with the IEnumFE class perhaps?
declaring failure.
Whiteboard: tfd 5/12
Target Milestone: M16 → M18
I'll give 'er another shot by the end of the weekend. But my next comment on this may be very similar to pink's latest.
pink - what was the internal drag type name that you guys decided on to get xlated into _NETSCAPE_URL? Can we at least add those bits? I can if you don't want to.
I looked at IEnumFE and it looks OK. That leads me to chime in with pink and say that I'm completely stumped.
the mime type is text/x-moz-url right now, the proxy icon has it registered, but nothing else.
Once we understand this, it needs a good task description and estimate.
Whiteboard: We're stumped. Need to buy a vowel.
Blocks: 37004
once it works, it should be about 1 day of work.
Whiteboard: We're stumped. Need to buy a vowel. → We're stumped. Need to buy a vowel. (1 day)
Whiteboard: We're stumped. Need to buy a vowel. (1 day) → 1 day
Whiteboard: 1 day → We're stumped. Need to buy a vowel. 1 day? (after the epiphany)
Putting on [nsbeta2-] radar. Put on release note to Save As... for workaround.
Keywords: nsbeta2, relnote
Whiteboard: We're stumped. Need to buy a vowel. 1 day? (after the epiphany) → [nsbeta2-] We're stumped. Need to buy a vowel. 1 day? (after the epiphany)
I think I understand why external drag and drop isn't working. The object that gets passed to DoDragDrop is a nsDataObjCollection, not a nsDataObj. nsDataObjCollection maintains its own list of flavors; it doesn't delegate to its children. That explains why nsDataObj::EnumFormatEtc doesn't get called. nsDragService::InvokeDragSession constructs a nsDataObjCollection and calls AddDataObject for each data object. However nsDataObjCollection::AddDataObject does not update the format list that nsDataObjCollection::EnumFormatEtc returns, and nsDataObjCollection::AddDataFlavor never gets called. So the reason that external drag and drop doesn't work at all is because nsDataObjCollection::EnumFormatEtc hands out empty format lists to drop targets. A possible solution is to modify nsDataObjectCollection::AddDataObject to call EnumFormatEtc on the passed data object, enumerate the formats and call m_enumFE->AddFE for each one. nsDataObjCollection::AddDataFlavor can then be removed, since mDataFlavors isn't even used.
hrm, that doesn't sound good...i wonder why the collection object is being sent when we're only dragging one item... thanks, I'll look into that.
Target Milestone: M18 → M20
pushing back for re-evaluation. i think i have a good lead on why this doesn't work (thanks to Chris Hill) and this sucker is goin' down. *female backup singers shout, "Shaft!"*
Whiteboard: [nsbeta2-] We're stumped. Need to buy a vowel. 1 day? (after the epiphany) → 1 day
If ya knock this mutha off, first round's on me.
Phil said today that module owners may checkin externally-contributed patches for non-'+' bugs. Perhaps Chris or another Mozillian would care to code this up?
Mike, if you're not working on this right now then I may be able to take a look at it sometime soon. Let me know.
[nsbeta2+] checkin by [6/22]
Whiteboard: 1 day → [nsbeta2+] [6/22] 1 day
It seems there are several issues involved in fixing this bug: 1) Pass a single data object instead of a collection 2) If the data is a shortcut, make sure DRAGDROP_ACTION_LINK is specified (I think this is to be done from the js code) 3) Finish implementing nsDataObject::GetFileDescriptorInternetShortcut by constructing an appropriate filename (needs to be a VALID filename ["http://www.mozilla.org" isn't] and use the title of the page if available) and ensuring TYMED_HGLOBAL is set on the STGMEDIUM 4) Finish implementing nsDataObject::GetFileContentsInternetShortcut by using the actual URL and ensuring TYMED_HGLOBAL is set on the STGMEDIUM I don't feel comfortable enough with the mozilla data transfer stuff or the x-moz-url format to implement this. I just know what the problems are as they relate to calling the Windows DnD API. Is there a way to associate a title with a link? I can do my best if nobody else is able to work on this. Beyond internet shortcuts (this bug), it sure would be nice to enable support for dropping images as normal files (from the cache?) and DIB data.
working on this today (sunday), hopefully i'll have this done by tomorrow. thanks for your help chris!
Target Milestone: M20 → M19
ok, it works! now the only part missing is what to name the file. right now it's a temp name. i'll check this in tonight. thanks again guys for all your help! chris, your comments were right on the money.
Looks good! Are you planning to add use the title of the page for the filename? This is what 4.x did. Now that this bug is nearly fixed, its evil brother 37412 needs to be fixed to make the shortcuts useful. At this point does mozilla offer the option to associate mozilla with URL shortcuts? (double click to launch mozilla)
Oh, sure, of course it all makes sense now. Good job, Pink! If you're ever up in Edmonton, or I'm down your way, I'll be buying that first round.
Just tried this in this morning's build. Looks pretty good. Just a couple of minor things that I noticed: 1. The "\n" coded into shortcutPrefix in nsDataObj::GetFileContentsInternetShortcut() doesn't produce a linefeed in the file. My guess (don't have a hex editor handy) is that it adds \10 to the file, when \13\10 is needed. 2. Mozilla loses focus on the drop. Is there a way to avoid this? Actually, I just tried this on NS4.72 and it loses focus as well. Probably not a major thing, then.
reshuffle
Target Milestone: M19 → M17
modulo the bug commented on in navigatorDD.js with window.title, this all works. other bugs have been filed to cover that, my work here is done.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
What about the newline in the prefix issue Dean raised? Should the title be converted to a valid filename if it contains invalid characters? The following characters could be converted to a safe character like a space: < > : " / \ | and any character < 32. There are more extensive tests that could be done to ensure a valid filename, but checking these would cover most of the problems.
ok, open a new bug on the < > : " / \ | characters. the \n problem doesn't seem to be a problem as Nav4's shortcuts do the exact same thing (i tested it).
Opened bug 42009 on valid filename issue. I guess if a \n works, it works. I'm not sure if the URL file format is actually documented.
Odd, though. Shouldn't \n to a file add whatever the OS considers a linefeed to the file?
No, escape sequences shouldn't be expanded to more than one character (as would be required to make a "real" newline on DOS/WIN) AFAIK \n has a specific meaning no matter what system you are using, it's just the system newline conventions that change. Most software can deal with \n alone. Notepad can't but wordpad can for example. If you are writing to the console it doesn't really matter.
Testing with 2000-08-01-04-M17 on WinNT, working internet shortcuts are reliably created when the page proxy is dropped on the desktop. The "( TEMP TITLE )" title problem is bug 41985, which will be a trivial fix, but is waiting on bug 41984, "window.title is empty", nsbeta3+. The "relnote" keyword should go away when this bug is VERIFIED.
this works with the page proxy, but it doesn't work with links in the content area, or does it? benG still has to hook that up, but that's out of the scope of this feature i guess.
I think that's in-scope, actually. Your original description was "In 4.x, when you drag a link to the desktop, an internet shortcut file is created." Or should we break that out into a separate bug (if it isn't one already) ?
verified fixed, win95/win2k for dragging the proxy icon to the desktop Anyone know if there is a separate bug for the dragging of links? I will look for it and file the bug if I don't find it.
Status: RESOLVED → VERIFIED
There is a problem on Windows that the present fix does not address. When creating a title for the shortcut that is dragged to a folder, Mozilla follows IE behavior and uses information from the Web page's TITLE tag. However, if the tag surrounds a colon (e.g., <title>This is : a bug</title>), then creating a shortcut called "This is : a bug" violates Windows filename requirements (because the colon is a reserved character). This results in pop-up errors from Windows (W2K on my test box). The existance of this bug should also require QA to check whether Mozilla does any filename monitoring on Windows for other reserved characters as well as reserved filenames (e.g., COM1, LPT2, CON, AUX, PRN, etc.). This may relate to similar issues on other platforms.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
dear lord, file another bug. this one is fixed and long dead. don't zombify bugs.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Jack, this was already discussed in this bug on 2000-06-08, and bug 42009 was filed on 2000-06-09. Please make sure to read through the comments in a bug report before adding to it, especially if you're going to reopen it.
re-verifying
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.