[Webkit-unassigned] [Bug 109422] [Qt] Add Page Visibility API support
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Mar 4 04:56:57 PST 2013
https://bugs.webkit.org/show_bug.cgi?id=109422
--- Comment #29 from Benjamin Dupont <bdupont at nds.com> 2013-03-04 04:59:22 PST ---
(In reply to comment #28)
> (From update of attachment 189331 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=189331&action=review
>
> > Source/WebKit/qt/WebCoreSupport/QWebPageAdapter.cpp:164
> > +void QWebPageAdapter::setVisibilityState(QWebPageAdapter::PageVisibilityState visibilityState, bool isInitialState)
>
> I suggest to get rid of the bool isInitialState parameter. It looks very confusing on the caller side, it is always false except for _one_ case inside initialWebCorePage. In there I think we should simply call
> page->setVisibilityState(WebCore::PageVisibilityStateHidden, true);
Ok.
>
> > Source/WebKit/qt/WebCoreSupport/QWebPageAdapter.h:136
> > + enum PageVisibilityState {
> > + PageVisibilityStateVisible,
> > + PageVisibilityStateHidden
> > + };
>
> Given that this is a binary state, why not simply use a boolean instead? It makes the translation to/from WebCore types easier I think. Just call it say setPageVisible(bool visible) or so - I think then you can get rid of some glue code.
Ok.
>
> > Source/WebKit/qt/WidgetApi/qwebview.cpp:736
> > +#if ENABLE(PAGE_VISIBILITY_API)
> > + else if ((e->type() == QEvent::Show) || (e->type() == QEvent::WindowActivate))
> > + d->page->d->setVisibilityState(QWebPagePrivate::PageVisibilityStateVisible, false);
> > + else if ((e->type() == QEvent::Hide) || (e->type() == QEvent::WindowDeactivate))
> > + d->page->d->setVisibilityState(QWebPagePrivate::PageVisibilityStateHidden, false);
> > +#endif
>
> Imagine a tabbed browser. Would this still be accurate, i.e. if the QWebView is in a tab that is _not_ visible (because it's not current/active) but the window gets activated. Should the page visibility state change to visible?
No, it shouldn't... We should also manage:
a) if the QWebView is in active tab and the window gets deactivated -> change state from visible to hidden
b) if the QWebView is in active tab and the window gets activated -> change state from hidden to visible
When the window is activated/deactivated a showEvent/hideEvent is fired to the current QWebView? If yes, I'll remove WindowDeactivate and WindowActivate case.
>
> I suggest to re-implement showEvent() and hideEvent(), pass on the event to d->page->event and call the base implementation. That gives advanced users the power to control the state if they need to (re-implement and call QWebView::showEvent or not if they like), and it still allows us to centralize the implementation inside QWebPageAdapter.
>
It's an HTML5 requirement, why should we want to give to advanced users the power to control the state and thus change the expected behaviour defined by W3C?
> The same applies to QGraphicsWebView.
>
I'm not sure, as I mentioned previously:
"After adding QGraphicsWebView on a scene, QGraphicsWebView receives a show event even if the bound QGraphicsView isn’t visible.
After a show on QGraphicsView, QGraphicsWebView receive only a WindowActivate event.
Furthermore when a QGraphicsWebView was created, it’s visible by default even if it isn't rendered."
If I only re-implement showEvent() and hideEvent(), when you hide the scene the visibility state won't be changed (because hideEvent isn't called)...
> > Source/WebKit/qt/tests/qgraphicswebview/tst_qgraphicswebview.cpp:140
> > + int waitForEvent = 5;
>
> I can almost guarantee you that this is going to fail on the bots. Randomly failing tests on the bot are a PITA.
>
> I suggest to replace this unit test with implementing page visibility support in the Qt DRT. Then we can enable the layout tests for it as well.
Yes I agree with you but I don't know how to do it differently...
What is the Qt DRT? Where can I find an example?
Thank you for your feedback.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list