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.

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

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

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

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)

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

Ew, ugly bug.

(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.

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.

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.

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

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.

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

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.

Verified with post-landing trunk.