[Webkit-unassigned] [Bug 97324] [GTK] Add support for Page Visibility

[bugzilla-daemon at webkit.org]

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





--- Comment #7 from Martin Robinson <mrobinson at webkit.org>  2013-02-07 09:56:29 PST ---
(In reply to comment #6)
> (From update of attachment 186591 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=186591&action=review
> 
> >> Source/WebKit2/UIProcess/WebPageProxy.cpp:1645
> >> +}
> > 
> > Are we adding this WebCore API just for the sake of the unit tests? Why not simply ask JavaScript for the value of the page visibility state there?
> 
> I could do that. I thought if we add webkit_web_view_set_page_visibility to WebKit2 API, shouldn’t we add symmetrically webkit_web_view_get_page_visibility?

Ah, if WebCore doesn't support that kind of use, it might better to go with the flow and not use it that way in both WebKit1 and WebKit2.

> 
> >> Source/WebKit2/UIProcess/API/gtk/WebKitWebView.cpp:2955
> >> + * @initial_state: a flag to specify if the visibility state is initial
> > 
> > Hrm. I'm not sure if I totally understand the initial_state flag here. It could definitely use some more documentation.
> 
> Well, it basically means if the flag is set then override current visibility state with @visibility_state. Will update documentation here.

If you can only override the current state with a TRUE value here, what happens if you don't pass the flag? 

> > If only visible and hidden are implemented in WebCore, maybe it's better to only expose them? Do the layout tests depend on all states?
> 
> As far as I know no, they test only visible/hidden states. I was more thinking about future releases.

It's very easy to add new ENUM values to the API in a later release, but it's very difficult to remove them. :)

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