[Webkit-unassigned] [Bug 40278] [EFL] EFLWebKit doesn't support viewport meta tag

Thu Jun 10 06:43:07 PDT 2010

https://bugs.webkit.org/show_bug.cgi?id=40278

Jesus Sanchez-Palencia <jesus at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jesus at webkit.org

--- Comment #11 from Jesus Sanchez-Palencia <jesus at webkit.org>  2010-06-10 06:43:04 PST ---
(In reply to comment #10)
I've been working on this recently for the Qt WebKit port. This is the bug which has a patch pending review: https://bugs.webkit.org/show_bug.cgi?id=39902

>   1. Should the meta tag ALWAYS be enforced in the user? Should it always prohibit users from changing zoom level or limiting the available zoom range? I don't think so. It should be only enforced by Browsers and thus ewk_view users.   If this is the case, then you must have a different structure to hold WebCore/dom reported values, and another one that is user-settable with the values to enforce with ewk_view_zoom_range_set() and ewk_view_user_scalable_set(). With this approach you will also need ewk_view_zoom_range_get() and ewk_view_user_scalable_get() as ewk_view_viewport_get() will always report the original WebCore/dom values.   In any case, you must document this behavior and side-effects in the public API in ewk_view.cpp

IMHO the values shouldn't be enforced always. This meta tag was created for the iPhone, so targeting mobile browsers is the best idea. So we have two code paths here: one when the webpage does have the viewport meta tag and one when it does not.
In order to cover these two cases I added the signal QWebPage::viewportChangeRequested(ViewportHints). For the first case, when we have the meta tag, I implemented the ChromeClient::didReceiveViewportArguments  in our ChromeClientQt, which creates our ViewportHints and emits the signal. For the second case we now emits the signal with an empty ViewportHints on FrameLoaderClientQt::dispatchDidCommitLoad. 
In both cases this signal will be emitted before any visual layout of the page so you can adapt your viewport if needed and avoid extra re-layouts after. By doing this we also ignore any viewport meta tag that is not on the <head>, which is correctly by the meta tag specification.
It's expected that the browser developer will handle this signal properly by following its documentation and nothing changes for your application if you don't use this signal at all.

>   2. How to reset these values on new page load? Are you sure WebCore/dom will always report new value for each visited page, even if the page does not contain the mentioned meta tag? If does and allows you to reset the values, good, otherwise you'd have to reset these values yourself. Failing to do so will result in bugs when user visits one page that applies the tag and then goes to another that does not and is not prepared to handle those constraints.
> 

IIRC, yes, WebCore/dom is our friend! :)
I think that the explanation above covers the rest of this question, right? Having those two code paths cover this quite well.

I'll have a quick look at the patch now and see if I can help. I'll try but since I'm not an EFL-deep-underground-hacker I'm not sure I can go any further.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.