[Webkit-unassigned] [Bug 36882] [chromium] traverse from WebApplicationCacheHost to its associated WebDataSource and ultimately to its containing WebFrame

[bugzilla-daemon at webkit.org]

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





--- Comment #5 from Michael Nordman <michaeln at google.com>  2010-03-31 12:25:36 PST ---
As mentioned in an earlier email, here's an overview of what's going on...

I've been noodling with how to get the icon to show up when an appcache is
blocked by the policy. Respecting the policy and putting up prompts as needed
is already done (see AppCachePolicy stuff).

Please refer to this work in progress stuff...
http://codereview.chromium.org/1599002/show
http://codereview.chromium.org/1580004/show

There are two parts to this.

* Be able to identify the 'frame' associated with an appcache from the chrome
side of things.

* Notify the appcache frontend when something was blocked in the backend. When
the msg gets to the frontend, look up the render view and tell it about the
blockage.

-------------

> Why is it preferrable to pass WebDataSource instead of WebFrame to
> createApplicationCacheHost?

Frame->DocumentLoader->AppCacheHost is what happens in webcore.

WebFrame->WebDataSource->WebAppCacheHost is what i'm proposing we do in the
webkit API. (Actually we have API that lets you traverse in the direction that
the arrows show, this is adding stuff to allow traversal in the opposite
direction as well).

(note: DocumentLoader is represented in our WebKit API as WebDataSource)

I don't see any reason to deviate from what webcore is doing under the covers.
Also honestly, I'm not sure if we know which frame we're destined for at
AppCacheHost ctor time (an example of the type of trouble that deviating from
what happens under the covers can get you into).

> Also, can we instead introduce a method on
> WebFrameClient as we did for scripts, images, plugins and databases to check if
> appcaches are allowed?

You could but in Chrome it wouldn't be used. We test the policy in the backend
far removed from the renderer, only after we're discovered we either have
something to load (policy.CanLoadAppCache), or we're trying to create a new
appcache (policy.CanCreateAppCache). The callsites for those methods are in
place in the chrome code base for all to see. Imagine arranging to call back to
the renderer and have it call back out thru some WebFrameClient method which
calls back to the browser (i'm getting dizzy already).

It may make sense to have an API like that and hook webcore's impl up to it.

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