GNOME Bugzilla – Bug 753443
Does not show documentation when given as a path
Last modified: 2018-05-22 13:09:02 UTC
Since the WebKit2 port, if I try to view a local path (such as with "yelp help/C" when running inside a git repository with some help), I get a plain (unstyled) page which says "URL cannot be shown".
We are not correctly handled documents with file:// uris. I'll try to fix this for .1
Created attachment 311888 [details] Backtrace (In reply to David King from comment #0) > Since the WebKit2 port, if I try to view a local path (such as with "yelp > help/C" when running inside a git repository with some help), I get a plain > (unstyled) page which says "URL cannot be shown". I have a debug build, and I get an assertion failure.
Created attachment 311912 [details] [review] Restore ability to load local files It's still pretty buggy. Images are missing. You often have to click a link twice before it will work, and the back/forward list gets screwey when that happens.
Debugging notes: yelp-uri-builder changes the file URI to a bogus-file URI. Eventually that winds up being passed to WebKit unchanged, which isn't going to work. That's easy to fix by just returning early from build_network_uri(), or moving more code into the conditional there. Anyway, after that change, WebKit no longer crashes, and Yelp will load the directory the file is in, but not the file itself. Next, resolve_gfile() in yelp-uri.c inserts a rogue # character between the directory name and the basename of the file. That can be fixed in resolve_file_uri() by setting priv->fullurl right before the call to resolve_gfile(), which tells resolve_gfile() not to mangle the URI. (Don't do this though; see below for why.) Now Yelp will load the file properly, except it's loaded as plaintext. The remaining issue is that we don't have a custom URI scheme handler for file URIs as we do for the help URIs. The URI scheme handler in yelp-view.c is what's responsible for actually taking the URI and returning a data stream to WebKit, with an appropriate MIME type set, via webkit_uri_scheme_request_finish(). As far as I can tell, it's not possible to set a custom scheme handler for file URIs, since that's not really a custom protocol. So the thing to do is to send a bogus-file URI into WebKit after all, and handle it. The web extension takes care of converting it to a file URI. This means the only change needed in resolve_file_uri() is to add "file" to the list of special-cased URIs, otherwise the URI seen by the scheme request handler will have one slash too few, and somehow that causes the first component of the path to be stripped. Now, regarding original WebKit assertion: I haven't debugged why this is happening yet, but the problem is PageLoadState::didStartProvisionalLoad is called twice in a row (which is illegal), once with the URI file:///error/ and then again with the URI about:blank: didStartProvisionalLoad token=0x7fff0e6f6290 url=bogus-file:///home/mcatanzaro/jhbuild/checkout/gnome-nibbles/help/C/index.page unreachableURL= setUnreachableURL token=0x7fff0e6f6290 unreachableURL= didFailProvisionalLoad token=0x7fff0e6f6240 setUnreachableURL token=0x7fff0e6f58f0 unreachableURL=bogus-file:///home/mcatanzaro/jhbuild/checkout/gnome-nibbles/help/C/index.page didStartProvisionalLoad token=0x7fff0e6f6290 url=file:///error/ unreachableURL= setUnreachableURL token=0x7fff0e6f6290 unreachableURL= didStartProvisionalLoad token=0x7fff0e6f6290 url=about:blank unreachableURL=bogus-file:///home/mcatanzaro/jhbuild/checkout/gnome-nibbles/help/C/index.page ASSERTION FAILED: m_uncommittedState.provisionalURL.isEmpty()
I haven't forgotten this, but I haven't had enough time. I've started several times to work on this, but the yelp uri code is a bit messy. I'll try to find some more time soon.
fyi, this has broken the anaconda help in Fedora
(In reply to Matthias Clasen from comment #6) > fyi, this has broken the anaconda help in Fedora FYI: we noticed this very late because anaconda help is a new feature and there wasn't a test criterion for it until now. We've reverted to Yelp 3.17.2, since this is a tough bug and we needed a fix yesterday.
Created attachment 317814 [details] [review] libyelp: fix handling of documents using local paths Sorry again for the delay to fix this, it was indeed tricky. I think I'm handling all the cases supported before, but also man and info URIs should work now. So, you can use yelp /foo/bar for mallard (passing the directory or a page in the path), docbook (passing the xml file in the path), man and info. Passing the URIs with a full path is also supported, for example ghelp:/foo/bar, man:/foo/bar or info:/foo/bar. All other URI types don't support full paths (as before the wk2 port).
David or Shaun, will you be able to review this soon? Anaconda user help is a Fedora release blocker.
HTML files still show "URL cannot be shown". DocBook files just show an empty page.
(In reply to Shaun McCance from comment #10) > HTML files still show "URL cannot be shown". DocBook files just show an > empty page. I didn't know we also supported any HTML file, I guess epiphany is more appropriate for that, but I'll look at it anyway. Regarding docbook, what documentation are you trying? and how? yelp /usr/share/gnome/help/gstreamer-properties/C/gstreamer-properties.xml that works for me here. Could someone confirm if this patch fixes the anaconda use case at least?
Regarding DocBook, it actually does work with a local path to a .xml file, just not a local path to a .docbook file. And I think that might be an existing bug that predates the WK2 port.
Comment on attachment 317814 [details] [review] libyelp: fix handling of documents using local paths Pushing this patch. Keeping bug open until HTML paths are fixed.
The issue with .docbook files is https://bugzilla.gnome.org/show_bug.cgi?id=699995
Upon further testing, I seem to be getting a lot of crashes when clicking around. The first page always loads. The rest, not so much.
(In reply to Shaun McCance from comment #15) > Upon further testing, I seem to be getting a lot of crashes when clicking > around. The first page always loads. The rest, not so much. Could you provide more information? what document are you trying? does it happen with a particular document? do you have a bt?
If you could get a backtrace from ABRT or coredumpctl...?
Anyway, this is fixed, let's open new bugs for crashes.
HTML paths still don't work, so I don't consider this fixed. I could use some pointers on getting backtraces from out-of-process WebKit. All I get from gdb on the main process is that the main loop is spinning.
(In reply to Shaun McCance from comment #19) > HTML paths still don't work, so I don't consider this fixed. OK. > I could use some pointers on getting backtraces from out-of-process WebKit. > All I get from gdb on the main process is that the main loop is spinning. sudo gdb -p `pidof WebKitWebProcess` (if it's the only web process running) But really, it's much easier to just get it from coredumpctl: `sudo systemctl stop abrtd`, make it crash, then simply run `coredumpctl gdb`. FWIW, it works for me without crashing.
[Removing outdated "GNOME target" value.]
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/yelp/issues/108.