Drag and drop link to Netscape 4.x is broken

NEW
Unassigned

Status

()

Core
Drag and Drop
--
minor
17 years ago
9 years ago

People

(Reporter: Ben Ruppel, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
mozilla1.2alpha
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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.

Comment 1

17 years ago
works on Mac; what url do you go to?
(Reporter)

Comment 2

17 years ago
Any url.  This bugzilla page creates the result.  Probably just a win32 thing then.

Comment 3

17 years ago
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

Comment 4

17 years ago
Works for me on win2k in today's build.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 5

17 years ago
Still broken for me on June 21 win32 build.  Please feel free to ignore this bug
since it's so darn trivial :)
(Reporter)

Comment 6

17 years ago
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 → ---

Comment 7

17 years ago
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.

Comment 8

17 years ago
usability/polish 0.9.4.
Status: REOPENED → ASSIGNED
Target Milestone: --- → mozilla0.9.4

Updated

17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Updated

17 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Updated

17 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Updated

17 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Updated

17 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Updated

17 years ago
Target Milestone: mozilla0.9.9 → mozilla1.2

Comment 9

16 years ago
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.

Comment 10

16 years ago
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!

Comment 11

16 years ago
Doesn't this depend on bug 106708?

Comment 12

16 years ago
qa contact -> pmac
QA Contact: tpreston → pmac

Comment 13

16 years ago
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?

Comment 14

16 years ago
Weird, CF_UNICODETEXT appears in your output twice, once in position 0 and again
in position 4.

Comment 15

16 years ago
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 ;-)

Comment 16

16 years ago
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 ;-)

Comment 17

16 years ago
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 ;-)

Updated

16 years ago
Depends on: 40608

Comment 18

16 years ago
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)
 

Updated

15 years ago
Keywords: nsbeta1
Summary: Drag and Drop Link to Netscape is broken → Drag and drop link to Netscape 4.x is broken

Comment 19

15 years ago
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Assignee: bross2 → nobody
Status: ASSIGNED → NEW
QA Contact: pmac
QA Contact: drag-drop
You need to log in before you can comment on or make changes to this bug.