Bug 26588
| Summary: | r43791 corrupts uri with named anchor | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Daniel Macks <dmacks> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | UNCONFIRMED | ||
| Severity: | Normal | CC: | bugs-noreply, jmalonzo |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Mac | ||
| OS: | OS X 10.5 | ||
| URL: | http://bugzilla.gnome.org/show_bug.cgi?id=586559 | ||
Daniel Macks
The following change to webkit/webkitwebview.cpp webkit_web_view_open():
- gchar* fileUri = g_strdup_printf("file://%s", uri);
+ gchar* fileUri = g_filename_to_uri(uri, NULL, NULL);
webkit_web_view_load_uri(webView, fileUri);
causes corruption of the uri if it contains a named anchor ("/foo/bar#quux") rather than just a filename ("/foo/bar"). The use of named anchors with local filenames is common in devhelp, and this change thus breaks devhelp (reverts much of the problem solved in Bug #17176). If the given uri contains a named anchor, that needs to get carried as a named anchor (i.e., "#foo") into webkit_web_view_load_uri(). However, g_filename_to_uri() doesn't respect named anchors...it treats the whole given string as the pathname and uri-encodes it, thus converting the "#" to %23. The result is that w_v_l_uri gets "/foo/bar/%23quux", which is obviously not the intended filename.
The solution is to parse apart the given uri: do g_filename_to_uri on the pathname part only and then re-append the anchor if there is one.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Jan Alonzo
(In reply to comment #0)
> The following change to webkit/webkitwebview.cpp webkit_web_view_open():
>
> - gchar* fileUri = g_strdup_printf("file://%s", uri);
> + gchar* fileUri = g_filename_to_uri(uri, NULL, NULL);
> webkit_web_view_load_uri(webView, fileUri);
>
> The solution is to parse apart the given uri: do g_filename_to_uri on the
> pathname part only and then re-append the anchor if there is one.
webkit_web_view_open is a deprecated API. Please use webkit webkit_web_view_load_uri.
Daniel Macks
Given that this function keeps changing how it behaves and is deprecated vs newer functions, should it be shielded by WEBKIT_DISABLE_DEPRECATED or a similar token in the public webkitwebview.h header?
Jan Alonzo
(In reply to comment #2)
> Given that this function keeps changing how it behaves and is deprecated vs
> newer functions, should it be shielded by WEBKIT_DISABLE_DEPRECATED or a
> similar token in the public webkitwebview.h header?
Yup. Tagging this as deprecated will be included in the fix for bug #26726.