296064 - Dragging link whose text contains non-ASCII chars to BM bar results in bookmark titled with URL, not link text

Status: RESOLVED FIXED

(Camino Graveyard :: Drag & Drop, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This is the "bug" follow-on to bug 294001 (which fixed only the regression from
0.8.x).

1.  Go to URL above
2.  Drag the link "Français" to bookmarks bar
3.  Observe the bookmark is titled "http://www.os9forever.com/os9helperFR.html"
4.  Now drag "Deutsch"
5.  Observe bookmark entitled "Deutsch"

If you ctrl-click on "Français" and select "Bookmark this link...", "Français"
is correctly pre-filled as the title.

Comment 1

[Chris Lawson (gone)]

What's happening here, as I understand it, is that nsDragService::GetDataForFlavor() is putting URL data on the clipboard using the MacRoman encoding somehow.

Stuart and I looked at this -- along with Wevah -- for a *very* long time over the past 24 hours, and here's what Stuart said just before he left IRC today:

>Hm.  So the storage is UTF-16 sans BOM. I wonder if the right answer
>is to change it to convert to UTF-8 and put that on the clipboard?
>But I'm not sure if it's considered kosher for urld to have unicode.
>Someone who knows something needs to look at this, my brain is done.

CCing smfr to see if he has any advice here.

Pink, Simon? Any ideas?

cl

Comment 2

[Chris Lawson (gone)]

Oh, this is also very likely the root cause of bug 188432.

cl

Comment 3

[Chris Lawson (gone)]

Also, this is really a Core bug, but Firefox isn't affected because it doesn't try to turn the pasteboard data into an NSString. Forcing creation of an NSString from the NSData on the pasteboard, encoded as MacRoman, fixes this bug, but totally breaks any non-Roman charsets.

cl

Comment 4

[Stuart Morgan]

It's not necessarily MacRoman--it's whatever ConvertFromUnicodeToScriptCodeRun decides is a good encoding to use.  Going from some unknown encoding back to an NSString is not well defined, so somehow the unicode needs to get put in (if not in urld, then somewhere else)

Comment 5

[Simon Fraser [no longer active]]

Right, and it'll have to be somewhere else, since lots of other apps assume 'urld' data is 8-bit.

Comment 6

[Håkan Waara]

Ew, ugly bug.

Comment 7

[Stuart Morgan]

(In reply to comment #5)
> Right, and it'll have to be somewhere else, since lots of other apps assume
> 'urld' data is 8-bit.

Couldn't we just use UTF-8? It seems like existing apps would be no worse off, and if anything some would be better off since guessing UTF-8 is a reasonably common thing to do.

Comment 8

[Chris Lawson (gone)]

Branch-only now that bug 363577's regression has totally broken this on trunk.

Is comment 7 a viable option to fix this on branch? It sort of sucks that we're stuck with this in 1.6 otherwise.

Comment 9

[Chris Lawson (gone)]

If it's not a viable option, I guess this is going to have to be a WONTFIX unless someone comes up with an option that *is* viable for the branch.

Comment 10

[Stuart Morgan]

Why would we wontfix a bug that we could fix on the trunk?

Comment 11

[Chris Lawson (gone)]

Because this bug, as described, only happens to the branch now, and trunk appears that it will require a different solution? Maybe I'm looking at things the wrong way, or just not understanding something, but it seems doubtful that a solution for branch will also fix trunk, or vice versa.

Comment 12

[Chris Lawson (gone)]

Erm, despite the fact that this is superficially related to bookmarks/menus, this is really a D&D issue ;)

Comment 13

[Stan Shebs]

I think this is fixed by my patch for 393609; at least I was able to fill the bookmark bar and menu with freaky languages that have Wikipedias, and Camino was displaying and using all of them correctly.

Comment 14

[Stan Shebs]

Verified with post-landing trunk.