You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Andrew Grieve <ag...@chromium.org> on 2013/04/17 04:22:54 UTC
Making WebView's WebSQL work on Android 3.0+
Found a juicy hack that works around the webview disabling WebSQL for file:
URLs.
For our Chrome Apps plugins, we serve apps from chrome-extension:// URLs
instead of file:// URLs. This is possible via shouldInterceptRequest(),
where we just map the requests to the files.
So... I had the idea to test the WebSQL mobile-spec tests under this scheme
(while disabling Android's custom WebSQL work-around), and it seemed to
work fine.
I think that this means that we could change Cordova app urls to be
cordova:// (for ICS+), and could then delete the storage plugin.
What do you think?
Re: Making WebView's WebSQL work on Android 3.0+
Posted by Ian Clelland <ic...@google.com>.
On Wed, Apr 17, 2013 at 2:50 PM, Joe Bowser <bo...@gmail.com> wrote:
> So, there isn't a CORS issue with Android?
>
>
I can neither confirm nor deny the existence of the alleged CORS issue on
Android :)
I'll probably know more about that tomorrow; I'll let you know what I find.
If we're using OkHttp, though, we should be able to work around any Android
issues pretty easily.
Ian
Re: Making WebView's WebSQL work on Android 3.0+
Posted by Michael Brooks <mi...@michaelbrooks.ca>.
Thanks for the details Ian.
In our experience, by-passing CORS policies is a HUGE bonus for most
developers. It would be rad if you can find a nice hackity-hack to get
around this so that we can also take advantage of WebSQL :)
Michael
On Wed, Apr 17, 2013 at 12:50 PM, Joe Bowser <bo...@gmail.com> wrote:
> So, there isn't a CORS issue with Android?
>
> On Wed, Apr 17, 2013 at 11:41 AM, Ian Clelland <ic...@google.com>
> wrote:
> > Specifically with iOS, setting the start page to a chrome-extension://
> url
> > causes the underlying UIWebView to apply CORS policies to all XHR
> requests.
> >
> > UIWebView seems to use the same restrictions as desktop Safari:
> > - Requests coming from file:/// urls do not use the Origin header
> > - Requests coming from other schemes (such as chrome-extension://)
> have
> > an Origin header applied, and the UIWebView validates the
> Access-Control-*
> > headers in the response.
> >
> > In practice, this means that when we make an XHR to an origin server
> which
> > doesn't support CORS, the response is rejected by the UIWebView, and the
> > XHR completes with an error.
> >
> > (I'm looking at a couple of ways to work around this; hopefully we don't
> > have to go as far as replacing the HTTP stack on iOS now, too)
> >
> > Ian
> >
> >
> > On Wed, Apr 17, 2013 at 1:34 PM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> >> Ian has been running into some issues with CORS while working on
> porting an
> >> app, I'll let him comment on specifics.
> >>
> >>
> >> On Wed, Apr 17, 2013 at 12:27 PM, Michael Brooks
> >> <mi...@michaelbrooks.ca>wrote:
> >>
> >> > Very cool Andrew. Does this affect the cross-origin policy? Many users
> >> > exploit the ability to make requests across multiple domains.
> >> >
> >> > Michael
> >> >
> >> >
> >> > On Wed, Apr 17, 2013 at 8:35 AM, Andrew Grieve <ag...@chromium.org>
> >> > wrote:
> >> >
> >> > > Just tried it with:
> >> > >
> >> > > chrome-extension://asdf/chromeapp.html?foo:1?#asdf?ds#af:s
> >> > >
> >> > > Had to make a slight tweak to IceCreamCordovaWebViewClient, but it
> >> worked
> >> > > fine.
> >> > >
> >> > >
> >> > > On Wed, Apr 17, 2013 at 12:39 AM, Joe Bowser <bo...@gmail.com>
> >> wrote:
> >> > >
> >> > > > How does this affect URI handling? We've had far bigger issues
> with
> >> > > > file:///android-asset failing on ICS+. Did you test with URIs
> that
> >> > > contain
> >> > > > a question mark, pound or a colon?
> >> > > >
> >> > > > On Apr 16, 2013 7:23 PM, "Andrew Grieve" <ag...@chromium.org>
> >> wrote:
> >> > > >
> >> > > >> Found a juicy hack that works around the webview disabling WebSQL
> >> for
> >> > > >> file: URLs.
> >> > > >>
> >> > > >> For our Chrome Apps plugins, we serve apps from
> chrome-extension://
> >> > URLs
> >> > > >> instead of file:// URLs. This is possible via
> >> > shouldInterceptRequest(),
> >> > > >> where we just map the requests to the files.
> >> > > >>
> >> > > >> So... I had the idea to test the WebSQL mobile-spec tests under
> this
> >> > > >> scheme (while disabling Android's custom WebSQL work-around),
> and it
> >> > > seemed
> >> > > >> to work fine.
> >> > > >>
> >> > > >> I think that this means that we could change Cordova app urls to
> be
> >> > > >> cordova:// (for ICS+), and could then delete the storage plugin.
> >> > > >>
> >> > > >> What do you think?
> >> > > >>
> >> > > >
> >> > >
> >> >
> >>
>
Re: Making WebView's WebSQL work on Android 3.0+
Posted by Joe Bowser <bo...@gmail.com>.
So, there isn't a CORS issue with Android?
On Wed, Apr 17, 2013 at 11:41 AM, Ian Clelland <ic...@google.com> wrote:
> Specifically with iOS, setting the start page to a chrome-extension:// url
> causes the underlying UIWebView to apply CORS policies to all XHR requests.
>
> UIWebView seems to use the same restrictions as desktop Safari:
> - Requests coming from file:/// urls do not use the Origin header
> - Requests coming from other schemes (such as chrome-extension://) have
> an Origin header applied, and the UIWebView validates the Access-Control-*
> headers in the response.
>
> In practice, this means that when we make an XHR to an origin server which
> doesn't support CORS, the response is rejected by the UIWebView, and the
> XHR completes with an error.
>
> (I'm looking at a couple of ways to work around this; hopefully we don't
> have to go as far as replacing the HTTP stack on iOS now, too)
>
> Ian
>
>
> On Wed, Apr 17, 2013 at 1:34 PM, Michal Mocny <mm...@chromium.org> wrote:
>
>> Ian has been running into some issues with CORS while working on porting an
>> app, I'll let him comment on specifics.
>>
>>
>> On Wed, Apr 17, 2013 at 12:27 PM, Michael Brooks
>> <mi...@michaelbrooks.ca>wrote:
>>
>> > Very cool Andrew. Does this affect the cross-origin policy? Many users
>> > exploit the ability to make requests across multiple domains.
>> >
>> > Michael
>> >
>> >
>> > On Wed, Apr 17, 2013 at 8:35 AM, Andrew Grieve <ag...@chromium.org>
>> > wrote:
>> >
>> > > Just tried it with:
>> > >
>> > > chrome-extension://asdf/chromeapp.html?foo:1?#asdf?ds#af:s
>> > >
>> > > Had to make a slight tweak to IceCreamCordovaWebViewClient, but it
>> worked
>> > > fine.
>> > >
>> > >
>> > > On Wed, Apr 17, 2013 at 12:39 AM, Joe Bowser <bo...@gmail.com>
>> wrote:
>> > >
>> > > > How does this affect URI handling? We've had far bigger issues with
>> > > > file:///android-asset failing on ICS+. Did you test with URIs that
>> > > contain
>> > > > a question mark, pound or a colon?
>> > > >
>> > > > On Apr 16, 2013 7:23 PM, "Andrew Grieve" <ag...@chromium.org>
>> wrote:
>> > > >
>> > > >> Found a juicy hack that works around the webview disabling WebSQL
>> for
>> > > >> file: URLs.
>> > > >>
>> > > >> For our Chrome Apps plugins, we serve apps from chrome-extension://
>> > URLs
>> > > >> instead of file:// URLs. This is possible via
>> > shouldInterceptRequest(),
>> > > >> where we just map the requests to the files.
>> > > >>
>> > > >> So... I had the idea to test the WebSQL mobile-spec tests under this
>> > > >> scheme (while disabling Android's custom WebSQL work-around), and it
>> > > seemed
>> > > >> to work fine.
>> > > >>
>> > > >> I think that this means that we could change Cordova app urls to be
>> > > >> cordova:// (for ICS+), and could then delete the storage plugin.
>> > > >>
>> > > >> What do you think?
>> > > >>
>> > > >
>> > >
>> >
>>
Re: Making WebView's WebSQL work on Android 3.0+
Posted by Ian Clelland <ic...@google.com>.
Specifically with iOS, setting the start page to a chrome-extension:// url
causes the underlying UIWebView to apply CORS policies to all XHR requests.
UIWebView seems to use the same restrictions as desktop Safari:
- Requests coming from file:/// urls do not use the Origin header
- Requests coming from other schemes (such as chrome-extension://) have
an Origin header applied, and the UIWebView validates the Access-Control-*
headers in the response.
In practice, this means that when we make an XHR to an origin server which
doesn't support CORS, the response is rejected by the UIWebView, and the
XHR completes with an error.
(I'm looking at a couple of ways to work around this; hopefully we don't
have to go as far as replacing the HTTP stack on iOS now, too)
Ian
On Wed, Apr 17, 2013 at 1:34 PM, Michal Mocny <mm...@chromium.org> wrote:
> Ian has been running into some issues with CORS while working on porting an
> app, I'll let him comment on specifics.
>
>
> On Wed, Apr 17, 2013 at 12:27 PM, Michael Brooks
> <mi...@michaelbrooks.ca>wrote:
>
> > Very cool Andrew. Does this affect the cross-origin policy? Many users
> > exploit the ability to make requests across multiple domains.
> >
> > Michael
> >
> >
> > On Wed, Apr 17, 2013 at 8:35 AM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> > > Just tried it with:
> > >
> > > chrome-extension://asdf/chromeapp.html?foo:1?#asdf?ds#af:s
> > >
> > > Had to make a slight tweak to IceCreamCordovaWebViewClient, but it
> worked
> > > fine.
> > >
> > >
> > > On Wed, Apr 17, 2013 at 12:39 AM, Joe Bowser <bo...@gmail.com>
> wrote:
> > >
> > > > How does this affect URI handling? We've had far bigger issues with
> > > > file:///android-asset failing on ICS+. Did you test with URIs that
> > > contain
> > > > a question mark, pound or a colon?
> > > >
> > > > On Apr 16, 2013 7:23 PM, "Andrew Grieve" <ag...@chromium.org>
> wrote:
> > > >
> > > >> Found a juicy hack that works around the webview disabling WebSQL
> for
> > > >> file: URLs.
> > > >>
> > > >> For our Chrome Apps plugins, we serve apps from chrome-extension://
> > URLs
> > > >> instead of file:// URLs. This is possible via
> > shouldInterceptRequest(),
> > > >> where we just map the requests to the files.
> > > >>
> > > >> So... I had the idea to test the WebSQL mobile-spec tests under this
> > > >> scheme (while disabling Android's custom WebSQL work-around), and it
> > > seemed
> > > >> to work fine.
> > > >>
> > > >> I think that this means that we could change Cordova app urls to be
> > > >> cordova:// (for ICS+), and could then delete the storage plugin.
> > > >>
> > > >> What do you think?
> > > >>
> > > >
> > >
> >
>
Re: Making WebView's WebSQL work on Android 3.0+
Posted by Michal Mocny <mm...@chromium.org>.
Ian has been running into some issues with CORS while working on porting an
app, I'll let him comment on specifics.
On Wed, Apr 17, 2013 at 12:27 PM, Michael Brooks
<mi...@michaelbrooks.ca>wrote:
> Very cool Andrew. Does this affect the cross-origin policy? Many users
> exploit the ability to make requests across multiple domains.
>
> Michael
>
>
> On Wed, Apr 17, 2013 at 8:35 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > Just tried it with:
> >
> > chrome-extension://asdf/chromeapp.html?foo:1?#asdf?ds#af:s
> >
> > Had to make a slight tweak to IceCreamCordovaWebViewClient, but it worked
> > fine.
> >
> >
> > On Wed, Apr 17, 2013 at 12:39 AM, Joe Bowser <bo...@gmail.com> wrote:
> >
> > > How does this affect URI handling? We've had far bigger issues with
> > > file:///android-asset failing on ICS+. Did you test with URIs that
> > contain
> > > a question mark, pound or a colon?
> > >
> > > On Apr 16, 2013 7:23 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> > >
> > >> Found a juicy hack that works around the webview disabling WebSQL for
> > >> file: URLs.
> > >>
> > >> For our Chrome Apps plugins, we serve apps from chrome-extension://
> URLs
> > >> instead of file:// URLs. This is possible via
> shouldInterceptRequest(),
> > >> where we just map the requests to the files.
> > >>
> > >> So... I had the idea to test the WebSQL mobile-spec tests under this
> > >> scheme (while disabling Android's custom WebSQL work-around), and it
> > seemed
> > >> to work fine.
> > >>
> > >> I think that this means that we could change Cordova app urls to be
> > >> cordova:// (for ICS+), and could then delete the storage plugin.
> > >>
> > >> What do you think?
> > >>
> > >
> >
>
Re: Making WebView's WebSQL work on Android 3.0+
Posted by Michael Brooks <mi...@michaelbrooks.ca>.
Very cool Andrew. Does this affect the cross-origin policy? Many users
exploit the ability to make requests across multiple domains.
Michael
On Wed, Apr 17, 2013 at 8:35 AM, Andrew Grieve <ag...@chromium.org> wrote:
> Just tried it with:
>
> chrome-extension://asdf/chromeapp.html?foo:1?#asdf?ds#af:s
>
> Had to make a slight tweak to IceCreamCordovaWebViewClient, but it worked
> fine.
>
>
> On Wed, Apr 17, 2013 at 12:39 AM, Joe Bowser <bo...@gmail.com> wrote:
>
> > How does this affect URI handling? We've had far bigger issues with
> > file:///android-asset failing on ICS+. Did you test with URIs that
> contain
> > a question mark, pound or a colon?
> >
> > On Apr 16, 2013 7:23 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >
> >> Found a juicy hack that works around the webview disabling WebSQL for
> >> file: URLs.
> >>
> >> For our Chrome Apps plugins, we serve apps from chrome-extension:// URLs
> >> instead of file:// URLs. This is possible via shouldInterceptRequest(),
> >> where we just map the requests to the files.
> >>
> >> So... I had the idea to test the WebSQL mobile-spec tests under this
> >> scheme (while disabling Android's custom WebSQL work-around), and it
> seemed
> >> to work fine.
> >>
> >> I think that this means that we could change Cordova app urls to be
> >> cordova:// (for ICS+), and could then delete the storage plugin.
> >>
> >> What do you think?
> >>
> >
>
Re: Making WebView's WebSQL work on Android 3.0+
Posted by Andrew Grieve <ag...@chromium.org>.
Just tried it with:
chrome-extension://asdf/chromeapp.html?foo:1?#asdf?ds#af:s
Had to make a slight tweak to IceCreamCordovaWebViewClient, but it worked
fine.
On Wed, Apr 17, 2013 at 12:39 AM, Joe Bowser <bo...@gmail.com> wrote:
> How does this affect URI handling? We've had far bigger issues with
> file:///android-asset failing on ICS+. Did you test with URIs that contain
> a question mark, pound or a colon?
>
> On Apr 16, 2013 7:23 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>
>> Found a juicy hack that works around the webview disabling WebSQL for
>> file: URLs.
>>
>> For our Chrome Apps plugins, we serve apps from chrome-extension:// URLs
>> instead of file:// URLs. This is possible via shouldInterceptRequest(),
>> where we just map the requests to the files.
>>
>> So... I had the idea to test the WebSQL mobile-spec tests under this
>> scheme (while disabling Android's custom WebSQL work-around), and it seemed
>> to work fine.
>>
>> I think that this means that we could change Cordova app urls to be
>> cordova:// (for ICS+), and could then delete the storage plugin.
>>
>> What do you think?
>>
>
Re: Making WebView's WebSQL work on Android 3.0+
Posted by Joe Bowser <bo...@gmail.com>.
How does this affect URI handling? We've had far bigger issues with
file:///android-asset failing on ICS+. Did you test with URIs that contain
a question mark, pound or a colon?
On Apr 16, 2013 7:23 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> Found a juicy hack that works around the webview disabling WebSQL for
> file: URLs.
>
> For our Chrome Apps plugins, we serve apps from chrome-extension:// URLs
> instead of file:// URLs. This is possible via shouldInterceptRequest(),
> where we just map the requests to the files.
>
> So... I had the idea to test the WebSQL mobile-spec tests under this
> scheme (while disabling Android's custom WebSQL work-around), and it seemed
> to work fine.
>
> I think that this means that we could change Cordova app urls to be
> cordova:// (for ICS+), and could then delete the storage plugin.
>
> What do you think?
>