[Qt] QML WebView has no way of jumping to an anchor

[Henrik Hartz]

I have a WebView embedded inside a Flickable, and I'm trying to move the 
page appropriately when a user clicks on a link that's an anchor to the 
same page, such as:

<pre>
<a href="#references">Jump to References</a>
</pre>

I looked at the source code in demos/declarative/webbrowser, but I fear 
that they may have forgotten about the use of links for that purpose, 
since the code in FlickableWebView looks like:

<pre>
(...)
       onUrlChanged: {
             // got to topleft
             flickable.contentX = 0
             flickable.contentY = 0
             if (url != null) { header.editUrl = url.toString(); }
         }
(...)
</pre>

contentY shouldn't typically be set to 0 if the url changes just by the 
anchor part (i.e. from http://www.example.com#section1 to 
http://www.example.com#section2). My question is: Does the QML WebView 
element exposes enough of its state in its API so that we can actually 
scroll to the right place on the page ? If not, shouldn't we submit a 
bug report or feature request ?

Example:
Use the demos/declarative/webbrowser QML example and visit
http://en.wikipedia.org/wiki/Uniform_Resource_Locator
... and try any of the "Contents" link: Instead of scrolling to the 
right place on the page, it will go back to the top of the document.

[Benjamin Poulain]

Please follow http://trac.webkit.org/wiki/QtWebKitBugs when reporing bugs here (missing Qt keyword).

We need a bunch of new APIs in QGraphicsWebView to properly support mobile content:
-expose the real viewport/screen size the WebCore
-scroll to position
-touch support
-viewport metatag

I think the current element exposed to QML will not do the job for general web content. It should probably be limited to controlled content/hybrid. An element with its own viewport and the complete support of mobile model would be better IMHO.

Can you think of use cases for using the flickable with WebKit for rendering general web content?

[Kenneth Rohde Christiansen]

(In reply to comment #1)
> Please follow http://trac.webkit.org/wiki/QtWebKitBugs when reporing bugs here (missing Qt keyword).
> 
> We need a bunch of new APIs in QGraphicsWebView to properly support mobile content:
> -expose the real viewport/screen size the WebCore
> -scroll to position
> -touch support
> -viewport metatag
> 
> I think the current element exposed to QML will not do the job for general web content. It should probably be limited to controlled content/hybrid. An element with its own viewport and the complete support of mobile model would be better IMHO.
> 
> Can you think of use cases for using the flickable with WebKit for rendering general web content?

I guess it would be ok to support the programmatic scrolling/anchors. All that is needed is to call setActualVisibleContentsRect and then listen to the scrollRequested signal.

[Akos Polster]

I've run into this problem while porting an e-book reader to QML/WebView. The EPUB books consist of a bunch of HTML files + a chapter list. The chapter items are URLs with optional fragment part, so they can point to any location in the HTML files.

That would be my use case for rendering general web content with WebView.

[Kenneth Rohde Christiansen]

This is supported by our N9 browser and should be easy to move to trunk.

[Jocelyn Turcotte]

=== Bulk closing of Qt bugs ===

If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary.

If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.