All page content is loaded with HTTP. Strangely, this static content does
load successfully if it is sourced in the iframe document, but not if it is
sourced in the literal HTML. Even if there was a protocol difference, I
can't understand why that would make a difference in the internal
Probably because they only examine the AppCache when going through HTTP.
On Thu, Jul 12, 2012 at 1:32 PM, Andy an...@google.com wrote:
All page content is loaded with HTTP. Strangely, this static content does
load successfully if it is sourced in the iframe document, but not if it is
sourced
Greetings! I've been stumped on a WebView AppCache problem for a while
now. I'm attempting to use loadDataWithBaseURL() to load literal HTML
sourcing JS, CSS, images, and iframes into a WebView. At the same time I
am using the HTML5 AppCache to store this content locally. My problem is
On Mon, Jul 9, 2012 at 2:12 PM, Andy Erickson an...@google.com wrote:
Greetings! I've been stumped on a WebView AppCache problem for a while now.
I'm attempting to use loadDataWithBaseURL() to load literal HTML sourcing
JS, CSS, images, and iframes into a WebView.
All the base URL is there
However, specifying this base URL allows the iframed HTML to load from the
AppCache, so it looks like some domain information is being extracted from
the URL. Is there any reason why the iframe element should load from the
AppCache while the other elements do not?
On Tuesday, July 10, 2012
On Tue, Jul 10, 2012 at 1:19 PM, Andy Erickson an...@google.com wrote:
However, specifying this base URL allows the iframed HTML to load from the
AppCache, so it looks like some domain information is being extracted from
the URL. Is there any reason why the iframe element should load from the
6 matches
Mail list logo