From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8.1) Gecko/20010312 BuildID: 2001031204 Since Mozilla doesn't work with everything yet, sometimes I have to revert to Netscape 4. I used to be able to drag the link icon from the urlbar or links from the web page into netscape, and it would open the page. Now what happens is, on the first try the netscape urlbar is filled with %3F's (or ??????). If you try again, the url goes through, but with some strange characters and it is followed by the web page's title. For some reason this causes some pages to load improperly. While this is not a major problem, it may be a symptom of something more serious being broken. Reproducible: Always Steps to Reproduce: 1.open mozilla and netscape browser windows. go somewhere in mozilla. 2.drag link from urlbar or from webpage to netscape window from mozila. Actual Results: First time, Netscape gets a urlbar full of "???????" (or %3F) Second time, Netscape gets a corrupted url as described above. Expected Results: Netscape goes to Url. This used to work.
works on Mac; what url do you go to?
Any url. This bugzilla page creates the result. Probably just a win32 thing then.
I'm seeing this as well. The behavior I'm seeing on 3/14 win32 builds is that the page title is being carried with the drag and so the URL in Netscape's URL field becomes "http://www.somesite.com|pagetitle" and can't be resolved. updating component and setting status to New
Assignee: asa → blakeross
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps: Drag and Drop
Ever confirmed: true
QA Contact: doronr → tpreston
Works for me on win2k in today's build.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
Still broken for me on June 21 win32 build. Please feel free to ignore this bug since it's so darn trivial :)
Uhm, sorry if I'm overstepping my bounds, but this is still here and I'm going to reopen it.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I see this problem when I drag a link from one application into another (for example, NS6 to NS4). I don't see this when dragging a link from one NS6 browser window to another NS6 browser window.
Status: REOPENED → ASSIGNED
Target Milestone: --- → mozilla0.9.4
I do not agree that this bug is Usability/Polish. We are using a tool to organize bookmarks (aka "knowledge"). The tool allows to simply drag a link to it and to open a browser window by clicking on such a link. It works well with Netscape, IE and even Opera but not with Mozilla. Please raise the Priority.
Creating a link using D&D from an the address field requires 8 times the amount of work as D&D from a link. When you drag from the address field all you don't get the page title. You only get the URL. In NS 4.75 you get the page title too. To fix this the user must (1) go back to the page (2) View Source. (3) Find the title. (4) Copy it. (5) Go back to the composer page. (6) Paste the title into the middle of the link. (7) Delete the extra URL "http" text from the left and right. THIS MAKES COPYING A LINK EIGHT TIMES MORE DIFFICULT!
Doesn't this depend on bug 106708?
qa contact -> pmac
QA Contact: tpreston → pmac
Created attachment 106091 [details] Dump of OLE Drop Information CT: The fix for bug 106708 doesn't fix this. Looking at the attachment (which is a dump of this bugs' URL when drag-n-dropped) it seems that Mozilla's default drag-n-drop format is TEXT/UNICODE for some bizarre reason! Surely TEXT/PLAIN and TEXT/UNICODE should be the LAST resort, not first?
Weird, CF_UNICODETEXT appears in your output twice, once in position 0 and again in position 4.
Dean, I'd noticed ;-) What I can't work out is WHERE this first lot of CF_UNICODETEXT comes from? Is Windows acting "helpful" by trying to convert the clipboard data (which is the URLdata) into other flavours automatically when we don't want it to? I'm assuming that Netscape stops checking for flavours as soon as it finds one it understands, which in this case is this first CF_UNICODETEXT. I'll do more digging when my Debug build finishes compiling ;-)
Found this in mozilla/widget/src/windows/nsClipboard.cpp lines 111/112: else if (mimeStr.Equals(kURLMime)) format = CF_UNICODETEXT; This would explain why the first thing Mozilla exports is Unicode Text. I wonder how much of Mozilla breaks if I change CF_UNICODETEXT to CFSTR_SHELLURL ;-)
This is starting to look like a side-effect of (or even DEPENDS ON) Bug 40608, which states that DND should NEVER be Unicode. Making the change mentioned in comment 16 turns the initial CF_UNICODETEXT into a UniformResourceLocator (which is logical, and would make the patch for bug 106708 obsolete), but breaks DND between Mozilla windows. I get "www.(loads of chinese characters).com could not be found" errors, and the status line shows "resolving host www.%e7%91%a8%e7%81...". DND with other apps is unaffected. It looks like Mozilla is assuming the DND is Unicode, and is doing some sort of (unnecessary) conversion. IMHO the format should have been CFSTR_SHELLURL from the start, but it might be too late to change it now - changing this could have knock-on effects in other areas (such as DND to Bookmarks/Sidebar/Personal Toolbar etc. which might then have cross-platform implications). I'm leaving this to the experts ;-)
I think <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=89538">89538</a> contains the reverse of this problem: from Application to Netscape (Windows)
Summary: Drag and Drop Link to Netscape is broken → Drag and drop link to Netscape 4.x is broken
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Assignee: bross2 → nobody
Status: ASSIGNED → NEW
QA Contact: pmac
You need to log in before you can comment on or make changes to this bug.