[webkit-qt] QML2 WebView and viewport meta tag (on Desktop)
Lars Knudsen
larsgk at gmail.com
Fri Feb 15 11:55:20 PST 2013
Thanks Andras and Jocelyn,
I will do some work on this in the weekend and get back to you with the
results.
- Lars
PS: The project I am working on:
http://opensourcedays.org/2013/content/education-kit-built-webapps-raspberry-pi-and-arduino
On Fri, Feb 15, 2013 at 6:33 PM, Andras Becsi <abecsi at webkit.org> wrote:
> Hi again,
>
> On 15 February 2013 16:41, Lars Knudsen <larsgk at gmail.com> wrote:
>
>> just to recap my troubles and findings for QML2/WebView:
>>
>> 1. if you want to have (somewhat) working viewport meta tag support, you
>> should use the WebView as it is - without fiddling with any experimental
>> features.
>> However:
>> a) Only very few mouse events will be sent to the page (e.g. try with
>> http://dunnbypaul.net/js_mouse/) - looks like mouse move and click (the
>> rest is caught by the flickable surface (zoom/pan) and are never sent to
>> the page
>> b) Somehow, zoom/pan is still possible when specifying the
>> maximum/initial/minimum scale = 1 and user-scalable=no .. even when
>> creating a surface that would steal all touch and mouse events (working on
>> iPad)
>>
>
> Zooming should not be possible if you set user-scalable=no, not event
> with double-tap (double-click). If it is possible, then it is a bug.
>
> 2. if you want to have the forced pan/zoom disabled and the mouse events
>> back, you need to specify
>> QQuickWebViewExperimental::setFlickableViewportEnabled(false); - BUT - an
>> unfortunate side effect of this is that the viewport meta tag seems to be
>> ignored. Leaving the WebView back to the same behavior as most desktop
>> browsers have.
>>
>
>> In my particular case, I need to have a WebView filling out the complete
>> window, where mouse (or touch) events are all sent to the page. I also
>> need the viewport meta tag to be respected as I am making a WebApps centric
>> 'browser' window to be used on RaspberryPi and PC's running full screen
>> (mostly) in developing regions (where you never know what resolution you
>> will be hooked up to). Additionally, It would be VERY helpful if the
>> parameters to the viewport metatag would make the browser window behave as
>> on the iDevices - simply locking the screen (well - the width at least) to
>> the size specified.. and then HANDS OFF ;)
>>
>
> As said in my previous e-mail, the current WebView is a subclass of
> Flickable.
> Thus you might want to consider setting boundsBehavior:
> Flickable.StopAtBounds for your web app, to disable the bounce back
> animation.
>
> And also, for a web app where you control the content, you could maybe
> make your "browser" application more specific and experiment with a WebView
> with experimental settings like (accordin to your example from before):
>
> experimental.useDefaultContentItemSize: false
> contentWidth: rootPanel.width
> contentHeight: rootPanel.height
>
> Note, that this is highly experimental, and the property might go away in
> future versions without notice, but for specialized use-cases like this it
> could help to adopt the WebView.
>
> Personally, I think that if a page has a viewport meta tag specified, it
>> does not make sense in ANY case I can think of NOT to respect it. I really
>> don't understand why only Internet Explorer (to my knowledge) behaves like
>> this (and no - I don't enjoy using windows ;)).
>>
>> I can make some test pages and file the bugs - but I think a BIG step
>> forward would be to start using the viewport meta tag in ANY context.
>>
>
> Opening bugs with test pages would be highly valuable, and very much
> appreciated :)
>
> /Andras
>
> br
>> Lars
>>
>>
>>
>> On Fri, Feb 15, 2013 at 3:00 PM, Lars Knudsen <larsgk at gmail.com> wrote:
>>
>>> Hi Jocelyn,
>>>
>>> Also, setting the following will make the WebView completely ignore any
>>> viewport settings:
>>>
>>> QQuickWebViewExperimental::setFlickableViewportEnabled(false);
>>>
>>>
>>> But if I don't disable the flickable viewport, then mouse and touch
>>> clicks (with the mouse) behave strangly - AND double-click will zoom.
>>>
>>> hmmm... I guess I am back to some hack needed by deriving from
>>> QQuickWebView and setting the zoom factor directly based on the
>>> relationship between the width in the meta tag and the window width.
>>>
>>> This seemed to work when using QWebView - but I still havent found the
>>> equivalent for QQuickWebView:
>>>
>>> void MainWebView::resizeEvent ( QResizeEvent * event )
>>>
>>> {
>>>
>>> QWebView::resizeEvent(event);
>>>
>>> QWebPage::ViewportAttributes va = page()->viewportAttributesForSize(page()->viewportSize());
>>>
>>> qreal zf = ((qreal)width())/va.size().width();
>>>
>>> setZoomFactor(zf);
>>>
>>> }
>>>
>>>
>>>
>>> br
>>>
>>>
>>> Lars
>>>
>>>
>>>
>>> On Fri, Feb 15, 2013 at 12:27 PM, Lars Knudsen <larsgk at gmail.com> wrote:
>>>
>>>> Hi Jocelyn,
>>>>
>>>> I am getting half way there by removing the max and initial scale - but
>>>> now window resizes don't have control over the zoom/scale when the content
>>>> grows outside the window or double-click to zoom happens . Previously, I
>>>> have combined the max/min/initial scale values on iPad to lock down all
>>>> kinds of accidental zooming/panning when making webapp demos/games. But
>>>> maybe that's abusing the system ;)
>>>>
>>>> - Lars
>>>>
>>>>
>>>> On Fri, Feb 15, 2013 at 12:18 PM, Jocelyn Turcotte <
>>>> jocelyn.turcotte at digia.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> humm I just realized that what you want is a zoom out, so
>>>>> maximum-scale shouldn't prevent that, minimum-scale would.
>>>>>
>>>>> The initial-scale=1 along with user-scalable=no on the other hand
>>>>> might be forcing it.
>>>>> So maybe you could play along those lines.
>>>>> It's also quite possible that you're hitting a bug in our code, I'd be
>>>>> interested to know if you find any bad behavior.
>>>>>
>>>>> The spec is there if you are able to read this kind of language:
>>>>> http://dev.w3.org/csswg/css-device-adapt/
>>>>> We should follow it as best as we can.
>>>>>
>>>>> br,
>>>>> Jocelyn
>>>>>
>>>>> On Fri, Feb 15, 2013 at 12:12:55PM +0100, Lars Knudsen wrote:
>>>>> > I just tried it on my android tablet, where it works. It could be
>>>>> that the
>>>>> > params are interpreted differently on chrome/mobile and qml2/webview.
>>>>> >
>>>>> > I'll try without min/max scale now.
>>>>> >
>>>>> > br
>>>>> > Lars
>>>>> >
>>>>> >
>>>>> > On Fri, Feb 15, 2013 at 12:10 PM, Jocelyn Turcotte <
>>>>> > jocelyn.turcotte at digia.com> wrote:
>>>>> >
>>>>> > > Hello Lars,
>>>>> > >
>>>>> > > This is pretty rusty stuff in my head, but doesn't maximum-scale=1
>>>>> mean
>>>>> > > that you force a 1:1 pixel ratio of the page pixels with screen
>>>>> pixels?
>>>>> > >
>>>>> > > To me it feels that using anything else than "width=device-width"
>>>>> with
>>>>> > > "maximum-scale=1" means that you do not want a view that fits the
>>>>> screen to
>>>>> > > width.
>>>>> > >
>>>>> > > br,
>>>>> > > Jocelyn
>>>>> > >
>>>>> > >
>>>>> > > On Fri, Feb 15, 2013 at 11:57:37AM +0100, Lars Knudsen wrote:
>>>>> > > > Hi,
>>>>> > > >
>>>>> > > > I am having some trouble getting WebView to respect the viewport
>>>>> meta
>>>>> > > tag.
>>>>> > > >
>>>>> > > > I am including a test project (qt5) that should show the problem.
>>>>> > > >
>>>>> > > > In the index.html file, I have:
>>>>> > > >
>>>>> > > > <!DOCTYPE html>
>>>>> > > >
>>>>> > > > <html>
>>>>> > > >
>>>>> > > > <head>
>>>>> > > >
>>>>> > > > <title>Demo App</title>
>>>>> > > >
>>>>> > > > <meta name="viewport" content="width=1024, initial-scale=1,
>>>>> > > > maximum-scale=1, user-scalable=no">
>>>>> > > >
>>>>> > > > <style type="text/css">
>>>>> > > >
>>>>> > > > #block {
>>>>> > > >
>>>>> > > > position: absolute;
>>>>> > > >
>>>>> > > > left: 256px;
>>>>> > > >
>>>>> > > > top: 256px;
>>>>> > > >
>>>>> > > > width: 512px;
>>>>> > > >
>>>>> > > > height: 512px;
>>>>> > > >
>>>>> > > > background-color: red;
>>>>> > > >
>>>>> > > > }
>>>>> > > >
>>>>> > > > </style>
>>>>> > > >
>>>>> > > > </head>
>>>>> > > >
>>>>> > > > <body>
>>>>> > > >
>>>>> > > > <h1>TEST</h1>
>>>>> > > >
>>>>> > > > <div id="block"></div>
>>>>> > > >
>>>>> > > > </body>
>>>>> > > >
>>>>> > > > </html>
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > In the main.cpp, I have:
>>>>> > > >
>>>>> > > > QtQuick2ApplicationViewer viewer;
>>>>> > > >
>>>>> > > >
>>>>> > > > viewer.setResizeMode(QQuickView::SizeRootObjectToView);
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > >
>>>>> viewer.setMainQmlFile(QStringLiteral("qml/SimpleWebAppRunner/main.qml"));
>>>>> > > >
>>>>> > > >
>>>>> > > > // Select the app to load
>>>>> > > >
>>>>> > > > QQmlProperty property((QObject*)(viewer.rootObject()),
>>>>> "appToLoad");
>>>>> > > >
>>>>> > > > property.write("SimpleWebApp");
>>>>> > > >
>>>>> > > >
>>>>> > > > viewer.showExpanded();
>>>>> > > >
>>>>> > > >
>>>>> > > > In the QML, I have:
>>>>> > > >
>>>>> > > > import QtQuick 2.0
>>>>> > > >
>>>>> > > > import QtWebKit 3.0
>>>>> > > >
>>>>> > > >
>>>>> > > > Rectangle {
>>>>> > > >
>>>>> > > > id: rootPanel
>>>>> > > >
>>>>> > > > width: 800
>>>>> > > >
>>>>> > > > height: 600
>>>>> > > >
>>>>> > > >
>>>>> > > > property string appBaseUrl: "../../apps/"
>>>>> > > >
>>>>> > > > property string appToLoad: ""
>>>>> > > >
>>>>> > > >
>>>>> > > > WebView {
>>>>> > > >
>>>>> > > > id: webView
>>>>> > > >
>>>>> > > > anchors.fill: parent
>>>>> > > >
>>>>> > > > url: ""
>>>>> > > >
>>>>> > > > onUrlChanged: console.log("Loading " + url)
>>>>> > > >
>>>>> > > > }
>>>>> > > >
>>>>> > > >
>>>>> > > > onAppToLoadChanged: {
>>>>> > > >
>>>>> > > > webView.url = appBaseUrl + appToLoad + "/index.html"
>>>>> > > >
>>>>> > > > }
>>>>> > > >
>>>>> > > > }
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > The whole web view seems to resize fine when resizing the QML
>>>>> window -
>>>>> > > but
>>>>> > > > content does not scale like it should (like on a mobile device) -
>>>>> > > > basically, scaling/zooming it <window width>/<viewport
>>>>> witdth=1024px>.
>>>>> > > >
>>>>> > > > Can anyone tell me what I am doing wrong? (maybe I am just blind
>>>>> from
>>>>> > > > looking at the code too long - and the answer is obvious..
>>>>> please tell
>>>>> > > :)).
>>>>> > > >
>>>>> > > > br
>>>>> > > > Lars
>>>>> > >
>>>>> > >
>>>>> > > > _______________________________________________
>>>>> > > > webkit-qt mailing list
>>>>> > > > webkit-qt at lists.webkit.org
>>>>> > > > https://lists.webkit.org/mailman/listinfo/webkit-qt
>>>>> > >
>>>>> > >
>>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> webkit-qt mailing list
>> webkit-qt at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-qt
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20130215/305fef3c/attachment-0001.html>
More information about the webkit-qt
mailing list