Bug 19360 – Frags on current page don't generate "navigation-requested" events

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Don Scorgie]

While trying to make yelp (the GNOME help browser) work with Webkit, I've hit the following issue (copy-paste of an email I originally sent to Alp directly):

I've uploaded an example program to:
http://www.gnome.org/~dscorgie/webkit_frags.c

The basic problem is that anchor points to current documents sometimes
doesn't emit a "navigation-request" signal.

The example program (compiled with:
gcc -o main webkit_frags.c `pkg-config --cflags --libs webkit-1.0`
) produces a page with 2 anchors and 2 links in it.  The first link
looks like:
<a href="#link1">
while the second looks like:
<a href="out.xhtml#link2">

When run without parameters, the example will set the base URI to:
"file://out.xhtml".  In this case, clicking the first link will move to
the corresponding anchor, but not generate the "navigation-requested"
event (as denoted by a message to stdout).

The program can take a second parameter, which specifies the base URI.
If this is set to:
"out.xhtml", the navigation-requested signal is generated, but the page
doesn't jump.
"/out.xhtml" the navigation-signal is NOT generated and the page jumps.
"file:out" &#65279;the navigation-signal is NOT generated and the page jumps.
"out" the navigation-signal is &#65279;generated, but the page doesn't jump.

Anyway, the basic pattern seems to be a signal is only generated when
the base URI doesn't contain a ":" or "/" character.

This is a bit of a problem for us as gnome-doc-utils (which generates
our xhtml) tends to create links using "#frag" for pages in the same
document, but not on the same page.  The way we get around this is to
intercept links clicked and handle them ourselves.

Long ramblings later, I'm done.  Any help with this would be
appreciated.

[Gustavo Noronha (kov)]

Hey. I'm looking at Yelp, and noticed this bug in a comment. I may have misunderstood something about the problem, but I think this problem is gone for a while now. The signal is emitted in both links of the example for me, without passing arguments for the program.

Can you confirm my investigation is correct?

[Frederic Peters]

I traced it back to FrameLoader::checkNavigationPolicy, which exits early at

    // We are always willing to show alternate content for unreachable URLs;
    // treat it like a reload so it maintains the right state for b/f list.
    if (loader->substituteData().isValid() && !loader->substituteData().failingURL().isEmpty()) {
        if (isBackForwardLoadType(m_policyLoadType))
            m_policyLoadType = FrameLoadTypeReload;
        function(argument, request, 0, true);
        return;
    }

and therefore skips the m_client->dispatchDecidePolicyForNavigationAction() which would emit the signal.

From there, however, I do not know where to go :/

[Gustavo Noronha (kov)]

Created attachment 35066 [details]
fix SubstituteData creation

 WebKit/gtk/ChangeLog                 |   13 +++++++++++++
 WebKit/gtk/webkit/webkitwebframe.cpp |    4 ++--
 2 files changed, 15 insertions(+), 2 deletions(-)

[Xan Lopez]

Comment on attachment 35066 [details]
fix SubstituteData creation

r=me

[Gustavo Noronha (kov)]

Created attachment 35071 [details]
 fix SubstituteData creation

 WebKit/gtk/ChangeLog                 |   14 ++++++++++++++
 WebKit/gtk/webkit/webkitwebframe.cpp |    2 +-
 2 files changed, 15 insertions(+), 1 deletions(-)

[Gustavo Noronha (kov)]

Created attachment 35072 [details]
 fix SubstituteData creation

 WebKit/gtk/ChangeLog                 |   14 ++++++++++++++
 WebKit/gtk/webkit/webkitwebframe.cpp |    2 +-
 2 files changed, 15 insertions(+), 1 deletions(-)

[Gustavo Noronha (kov)]

Comment on attachment 35072 [details]
 fix SubstituteData creation

Sorry for the spam. So, it looks like we are also using the baseKURL incorrectly. This patch makes both the normal reload, and the 'try again' work on error pages, in addition to fixing this bug.

[Jan Alonzo]

Comment on attachment 35072 [details]
 fix SubstituteData creation

r=me

[Gustavo Noronha (kov)]

Landed as r47457.