[Webkit-unassigned] [Bug 109422] [Qt] Add Page Visibility API support

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Mar 11 08:45:19 PDT 2013


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





--- Comment #37 from Benjamin Dupont <bdupont at nds.com>  2013-03-11 08:47:45 PST ---
(In reply to comment #36)
> After seeing the surrounding code I personally like setVisibilityState(bool visible) as _name_.
Ok. :) 


> No, that would just continue to skip the test. Instead the necessary hooks need to be implemented in the Qt build of DumpRenderTree and then those lines need to be removed, so that they are not skipped anymore. Tests referred to in this file are skipped from the test runs or are marked here as known to fail - in this case we want them to pass when this patch lands.
Ok, thank you for these explanations. I'll try to implement the necessary hooks.


> That's the link to the spec, yes. But I don't see how the spec requires us to act on Qt's event specifically.

> With what tabbed browser? We don't want to mandate how exactly to design the tabs, i.e. require the use of say QTabWidget.
> 
> Think of custom UIs in QGraphicsView for example.
> 
> > If they reimplement "virtual bool event(QEvent*)" they can make this kind of stuff?
> 
> Yes, they can. And I want to make it even easier, because ::event() is a catch-all that is tricky to get rid (call the base implementation first? only for some events?).
> 
> I think it is a better practice to use specific virtual event functions where we can, and in this case they would combine nicely with our initial page visibility implementation based on Qt's show and hide events. They are basic and well defined.
> 
> If we can't figure out a sensible basic implementation then perhaps we should just leave it at a public function in QWebPage and document how application developers can support web applications that use this web-facing visibility API.
Now I better understand what you mean. 

My first implementation contained this kind of public API:
https://bugs.webkit.org/attachment.cgi?id=189060&action=prettypatch
In this case we just provided a way to implement visibility functionalities as described in W3C, but we don't implement it for "basic" use cases. I don't know what is the best... In our side we implemented it directly in QWebView (as proposed in my last patch) because we have different projects and this way it seemed to be more relevant.

-- 
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