Bug 24695 – URI passed in to acceptNavigationRequest is modified compared to the one in the source

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Page Loading

[Callum Prentice]

A C++ application that embeds WebKit using Qt utilizes HTML content with a bespoke URI scheme that is intercepted and processed separately.

The URI in the content is of the form myscheme:///blah.blah.blah but when the user clicks on an anchor tag with this HREF value, the url passed in via the QNetworkRequest parameter in the overridden acceptNavigationRequest function appears as myscheme:/blah.blah.blah (i.e. 2 of the 3 slashes are removed).

To test, create a page with the following fragment of HTML:

<a href="myscheme:///blah.blah.blah">External link</a>

and in your application:

bool MyWebPage::acceptNavigationRequest(QWebFrame* frame, const QNetworkRequest& request, NavigationType type)

note that the request.url() is "myscheme:/blah.blah.blah" and not "myscheme:///blah.blah.blah" as expected.

Only able to try this on Windows XP with an open source build of WebKit 4.5.0.

[Alexey Proskuryakov]

I see how this can be unexpected, but does anything in RFC 3986 (or some other standard) say that this is wrong?

[Callum Prentice]

I haven't read the RFC so the behavior may well match what's defined in that document. If that's the case, would it be overkill to provide a url() and rawUrl() accessors?

[Alexey Proskuryakov]

Perhaps, but my question wasn't rhetoric - it may well be that our behavior is incorrect.

[Kent Hansen]

Please provide a testcase (a small Qt app) that does what the description says, to help us verify this issue. Thanks.

[Callum Prentice]

Will do - might take me a little while as I'm not very familiar with Qt but I should be able to rip out the bits that illustrate what I'm talking about.

[Jocelyn Turcotte]

This is a known issue in Qt's QUrl

See http://bugreports.qt.nokia.com/browse/QTBUG-8701

Resolving as won't fix to mean it is tracked with Qt.