Closed Bug 309226 Opened 20 years ago Closed 1 year ago

Dragging IDN url to Finder fails to create location file (webloc)

Categories

(Camino Graveyard :: Drag & Drop, defect)

Product:
Camino Graveyard
Component:
Drag & Drop
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: sugar.waffle, Unassigned)

References

(
URL
)

Details

(Keywords: intl)

In Camino, the location file is not generated with the web page of IDN. Reproducible: Always Steps to Reproduce: 1. open URL 2. URL drag and drop to desktop. Actual Results: The location file is not generated. Expected Results: The location file is generated with the name of the title of the web page. Mac OS X 10.3.9 trunk Camino 2005091722 (v1.0+)
How odd. I'm not sure it's IDN per se, because the page title is actually specified in the <title> tag (rather then Camino putting the URL as the title for a <title>-less page or something). I would have expected the behavior in bug 188432 instead. This bug also reproduces on the branch under 10.3.9. FWIW, Fx 1.5b1 creates a text clipping rather than a webloc (the normal Fx behavior is to create a webloc whose filename is the server and domain of the page/url).
Blocks: 301740
Keywords: intl
Can we get a valid URL please? Bugzilla doesn't seem to like non-ascii urls in the url field.
Summary: The location file cannot be made with URL of IDN. → Dragging IDN url to Finder fails to create location file
The URL looks (and works) fine here (I seem to still have auto-detect enabled, and it autodetected UTF-8).
(In reply to comment #1) > FWIW, Fx 1.5b1 creates a text clipping rather than a webloc (the normal Fx > behavior is to create a webloc whose filename is the server and domain of the > page/url). As for Fx, it is bug309225.
One problem I see right off the bat is that the domain gets percent-escaped for the NSURLPasteboardType, which shouldn't happen.
It looks like NSURL doesn't like non-ASCII domains. :/
We need to spit out the Punycode-encoded domain for the URL, I think (which, for 日本語.jp is xn--wgv71a119e.jp). This is what Safari does. I have an NSString category that does this, but we might be better off using the encoder we already have in the core.
Of course, I just realized that this might not be why the Finder is rejecting the drag, but it's probably worth a look.
Wevah: Care to look at this further? Is there any way you can have a patch for this before 1.0?
Summary: Dragging IDN url to Finder fails to create location file → Dragging IDN url to Finder fails to create location file (webloc)
Mass-reassign of bugs still assigned to pinkerton to nobody; filter on "NoMoPinkBugsInCamino".
Assignee: mikepinkerton → nobody
QA Contact: drag.drop
Comment 7 still sounds like the correct solution to this bug, based on my investigation with Pasteboard Inspector. Safari punycodes the URL in NeXT plain ASCII, NSString, public.utf8.plain-text, Apple URL, WebURLsWithTitles, and BookmarkDictionaryList pasteboard types (but, curiously, not in either public.url or 'url ').
Hardware: PowerPC → All
(In reply to comment #6) > It looks like NSURL doesn't like non-ASCII domains. :/ http://www.openradar.me/6923664
(In reply to comment #7) > We need to spit out the Punycode-encoded domain for the URL, I think (which, > for > 日本語.jp is xn--wgv71a119e.jp). This is what Safari does. I have an NSString > category that does this, but we might be better off using the encoder we > already have in the core. Wevah, do you still have that code? We do have code that uses the core punycoder (e.g. http://mxr.mozilla.org/seamonkey/source/camino/src/formfill/KeychainService.mm#1116), but it looks like that, well, pulls in a lot of Gecko, and the places we do drag stuff, like http://mxr.mozilla.org/seamonkey/source/camino/src/browser/TabButtonView.mm#487 and I think http://mxr.mozilla.org/seamonkey/source/camino/src/browser/PageProxyIcon.mm#102 don't look like they want to know about Gecko at all, or at least not very much.
We could probably just %encode, too, if that's easier; that seems to work, and to produce a valid webloc (though applications are buggier about handling %encoded URLs than punycode ones).
Note that dragging a URL link, like the URL field in this bug, will create a webloc; the URL inside is %-encoded, which of course results in a webloc that still won't work in Camino because of bug 565253 ("applications" in comment 14 includes us :P ). I think that's Core code, so we probably can't fix it :( Drags from the location bar/tab site icon still fail to create weblocs, presumably because the WebURLsWithTitlesPboardType (which is the first flavor in the drag, isn't %-encoded or punycoded). So, we really need to punycode at least WebURLsWithTitlesPboardType, I think.
(In reply to comment #13) > (In reply to comment #7) > > We need to spit out the Punycode-encoded domain for the URL, I think (which, > > for > > 日本語.jp is xn--wgv71a119e.jp). This is what Safari does. I have an NSString > > category that does this, but we might be better off using the encoder we > > already have in the core. > > Wevah, do you still have that code? > > We do have code that uses the core punycoder (e.g. > http://mxr.mozilla.org/seamonkey/source/camino/src/formfill/KeychainService. > mm#1116), but it looks like that, well, pulls in a lot of Gecko, and the > places we do drag stuff, like > http://mxr.mozilla.org/seamonkey/source/camino/src/browser/TabButtonView. > mm#487 and I think > http://mxr.mozilla.org/seamonkey/source/camino/src/browser/PageProxyIcon. > mm#102 don't look like they want to know about Gecko at all, or at least not > very much. There's also apparently http://files.iconfactory.net/sean/NSURL+IFUnicodeURL/ now, but that's 29 files and nearly 1 MB of code :-( There's https://github.com/simonb/SBPunyCode, which is a nice Cocoa wrapper, but that requires you build and ship libidn, too. Apparently WebView's URLFromPasteboard: is the only public Cocoa method that does IDN encoding (per http://www.vienna-rss.org/?p=215), but that of course requires us to pull in some or all of WebKit :P which is not a good solution for now ;-) WordPress has NSURL-IDN for its iOS apps; that category adapted code from OmniNetworking.framework (specifically from ONHost, https://github.com/omnigroup/OmniGroup/blob/master/Frameworks/OmniNetworking/ONHost.m); WP's adaptation is GPL-only, but the original ON source is MIT. Making our own fork of ONHost is probably a viable solution, but I'd really like to see Wevah's code ;-) (Don't ask me why I ended up in this bug tonight; I have no idea how I got here.)
(In reply to comment #16) > There's also apparently > http://files.iconfactory.net/sean/NSURL+IFUnicodeURL/ now, but that's 29 > files and nearly 1 MB of code :-( FWIW, I discovered today looking for something else entirely that Firefox Home apparently used that: http://mxr.mozilla.org/services-central/source/fx-home/Sources/NetworkAndStorage/NSURL+IFUnicodeURL.m I still think either Wevahcode or making our own fork of ONHost's IDN support is the best way to go, although either of NSURL+IFUnicodeURL or SBPunyCode are probably more "complete" solutions.
I'm working on getting my code up on GitHub, but it's probably not the most polished solution available.
(In reply to Wevah from comment #18) > I'm working on getting my code up on GitHub, but it's probably not the most > polished solution available. https://github.com/Wevah/Punycode-Cocoa :D
It's a bit of a mess: a lot of the comments are still there from the reference C, things are commented out, etc. But this current version hasn't choked on anything for me that I can remember…
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.