After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 753443 - Does not show documentation when given as a path
Does not show documentation when given as a path
Status: RESOLVED OBSOLETE
Product: yelp
Classification: Applications
Component: General
3.17.x
Other Linux
: Normal major
: ---
Assigned To: Yelp maintainers
Yelp maintainers
Depends on:
Blocks:
 
 
Reported: 2015-08-10 10:38 UTC by David King
Modified: 2018-05-22 13:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Backtrace (13.14 KB, text/plain)
2015-09-22 16:18 UTC, Michael Catanzaro
  Details
Restore ability to load local files (2.24 KB, patch)
2015-09-22 21:53 UTC, Michael Catanzaro
none Details | Review
libyelp: fix handling of documents using local paths (21.26 KB, patch)
2015-12-23 13:59 UTC, Carlos Garcia Campos
committed Details | Review

Description David King 2015-08-10 10:38:37 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".
Comment 1 Carlos Garcia Campos 2015-09-21 16:12:19 UTC
We are not correctly handled documents with file:// uris. I'll try to fix this for .1
Comment 2 Michael Catanzaro 2015-09-22 16:18:08 UTC
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.
Comment 3 Michael Catanzaro 2015-09-22 21:53:24 UTC
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.
Comment 4 Michael Catanzaro 2015-09-22 21:56:49 UTC
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()
Comment 5 Carlos Garcia Campos 2015-10-16 10:40:14 UTC
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.
Comment 6 Matthias Clasen 2015-10-29 17:49:03 UTC
fyi, this has broken the anaconda help in Fedora
Comment 7 Michael Catanzaro 2015-10-30 17:29:42 UTC
(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.
Comment 8 Carlos Garcia Campos 2015-12-23 13:59:49 UTC
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).
Comment 9 Michael Catanzaro 2016-01-16 05:51:06 UTC
David or Shaun, will you be able to review this soon? Anaconda user help is a Fedora release blocker.
Comment 10 Shaun McCance 2016-01-24 17:30:51 UTC
HTML files still show "URL cannot be shown". DocBook files just show an empty page.
Comment 11 Carlos Garcia Campos 2016-01-25 17:07:21 UTC
(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?
Comment 12 Shaun McCance 2016-01-29 17:13:26 UTC
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 13 Shaun McCance 2016-02-03 10:59:14 UTC
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.
Comment 14 Shaun McCance 2016-02-03 11:03:07 UTC
The issue with .docbook files is https://bugzilla.gnome.org/show_bug.cgi?id=699995
Comment 15 Shaun McCance 2016-02-03 17:41:52 UTC
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.
Comment 16 Carlos Garcia Campos 2016-02-03 18:23:44 UTC
(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?
Comment 17 Michael Catanzaro 2016-02-16 17:45:33 UTC
If you could get a backtrace from ABRT or coredumpctl...?
Comment 18 Michael Catanzaro 2016-02-16 17:47:02 UTC
Anyway, this is fixed, let's open new bugs for crashes.
Comment 19 Shaun McCance 2016-02-16 18:47:08 UTC
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.
Comment 20 Michael Catanzaro 2016-02-16 23:43:55 UTC
(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.
Comment 21 André Klapper 2016-09-15 08:30:12 UTC
[Removing outdated "GNOME target" value.]
Comment 22 GNOME Infrastructure Team 2018-05-22 13:09:02 UTC
-- 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.