Bug 37694 – [Qt] Issue with using QWebPage::setLinkDelegationPolicy...

• Component: WebKit Qt
• Status: RESOLVED FIXED

[Dawit A.]

Clicking on the type of links shown below completely renders QWebPage::setLinkDelegationPolicy(QWebPage::DelegateAllLinks) calls useless:

<a href="javascript:window.location='http://qt.nokia.com'">Click me</a>

When you click on a link like the one above, you will never receive the linkClicked signal. Instead the click will be treated as a non-click event and handled internally as if the default QWebPage::DontDelegateLinks is set. I guess this happens because the click triggers the execution of a javascript code which might do things other than making navigation requests. Regardless, the setLinkDelegationPolicy should mention this issue or perhaps there should be another NavigationType, QWebPage::NavigationTypeJavascript ???

[Jocelyn Turcotte]

In this case it is hard to know if the navigation was trigger by a user action from other types of events, so linkClicked cannot fit reliably.

A NavigationTypeJavascript might make sense if you cannot rely on re-implementing acceptNavigationRequest listening for NavigationTypeOther requests.

[Dawit A.]

(In reply to comment #1)
> In this case it is hard to know if the navigation was trigger by a user action
> from other types of events, so linkClicked cannot fit reliably.
> 
> A NavigationTypeJavascript might make sense if you cannot rely on
> re-implementing acceptNavigationRequest listening for NavigationTypeOther
> requests.

Unfortunately that is the case. That is one cannot rely on the meaning of NavigationTypeOther since there is no way you can distinguish that from say a call that originated from QWebView::load(...). :( 

After opening this bug report I took a look at the Qtwebkit source code and realized that this issue is actually the result of QtWebKit directly relying on the navigation types present in WebKit. All the Navigation types in QtWebKit are an exact equivalent right down to the name of the ones that exist in WebKit ; so the problem I guess is beyond just QtWebKit. 

Anyhow, I guess I have to come up with yet another hack to distinguish between requests that originate from a user clicking on a javascript link and those that originated from other means. In the meantime could this perhaps be clearly documented in the API ?

[Jocelyn Turcotte]

Created attachment 55353 [details]
Document the limitation

How about that?

[Kenneth Rohde Christiansen]

Comment on attachment 55353 [details]
Document the limitation


> +    \note This signal possibly won't be emitted for clicked links which use
> +    JavaScript to trigger navigation.

I don't like the 'possibly'

\note The signal will not be emitted for navigation triggered by JavaScript, such as ...

[WebKit Commit Bot]

Comment on attachment 55353 [details]
Document the limitation

Clearing flags on attachment: 55353

Committed r59026: <http://trac.webkit.org/changeset/59026>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.