GNOME Bugzilla – Bug 586559
Unable to view any search results
Last modified: 2009-08-06 12:24:45 UTC
devhelp-0.23 on OS X 10.4, using fink to supply all dependencies at least to the the level of GNOME2.26 with x11 GUI display mode. configures, compiles, installs, starts up okay. Badly broken behavior: 1. Click to Search tab 2. Enter something that gets results (example: "g_module_open", assuming glib gtk-doc is present) 3. Click an entry in the results list. Display pane says Unable to load page Problem occurred while loading the URL file:///sw/share/gtk-doc/html/glib/glib-Dynamic-Loading-of-Modules.html%23g-module-open Error stating file '/sw/share/gtk-doc/html/glib/glib-Dynamic-Loading-of-Modules.html#g-module-open': No such file or directory In fact, /sw/share/gtk-doc/html/glib/glib-Dynamic-Loading-of-Modules.html does exist and does contain an <a name="g-module-open"> anchor. But the anchor-name (the "#..." part) off the URL properly when trying to load the file into the viewer. If I go to the Contents tab, navigation works completely correctly. I can select a page in the tree pane, it displays in the viewer pane, and links in the viewer jump correctly, even the exact ones that failed in the Search mode.
Traced to dh-window window_search_link_selected_cb(), which includes the anchor-name in the uri passed to webkit_web_view_open(). I'm using gtkwebkit-1.1.10. Sounds like maybe a bug in webkit (should know to parse off the anchor before opening the uri filename), but I can't find information about anchors in the docs for that webkit function.
Yup... https://bugs.webkit.org/show_bug.cgi?id=17176
Actually, it's new webkit breakage. See: https://bugs.webkit.org/show_bug.cgi?id=26588 Given that webkit keeps breaking this function (which is likely to bit-rot further since it's deprecated), would be a good idea for devhelp to protect itself. If the uri is a local filename, should convert it to a uri (prepend file://) before handing off to webkit.
Just to CC myself and confirm the bug.
Seems like dh_link_get_uri is similarly unpredictable in what kind of string it returns (local filename vs method://path). Or at least it's called a ..._uri and sometimes it's passed directly to webkit but dh-assistant-view.c uses the returned string as if it's a file pathname. Maybe need a new dh_link_get_uri_no_really_a _uri that prepends file:// if it's a local filename and use that in all cases where an actual URI is desired. Or else have existing dh_link_get_uri always return an actual uri and add a new dh_link_get_uri_or_pathname that acts as current function does (or a dh_link_get_pathname that returns pathname if local or NULL if not).
Created attachment 138458 [details] [review] Prepend file:// Here's the patch we're using in fink. Not "complete" (only minimal change to work, not *every* use of webkit_web_view_open()) and doesn't resolve the inconsistent meaning of "uri", but also doesn't change anything in webkit lib API or behavior so no interface chaos (unlike webkit:)
This is already fixed in git: http://git.gnome.org/cgit/devhelp/patch/?id=af67fbedccab5044808a489a9f3a5540d42adcf2