You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Joe Bowser <bo...@gmail.com> on 2013/09/18 23:21:24 UTC
[Android] WebView, InAppBrowser and UI Threads
I'm currently trying to figure out CB-4858, which got assigned to
David, but I'm finding that I'm getting stuck at this part:
private String updateUrl(String url) {
Uri newUrl = Uri.parse(url);
if (newUrl.isRelative()) {
//url = this.webView.getUrl().substring(0,
this.webView.getUrl().lastIndexOf("/")+1) + url;
}
return url;
}
The problem with this code is that all methods on the WebView class
must run on the UI thread. Now, there's no easy way for us to pass
this data back because now we're doing asynchronous Java where we have
to wait for the UI thread to give us back the URL so we can find out
what our base path is.
We could override this in CordovaWebView, getting around the check,
but I think that this might not be the right thing to do.
Anyway, I'm content letting David chew on this, since I didn't know it
got assigned to him (JIRA didn't send me the e-mail), but I'd be
interested in seeing how this gets solved, because it's particularly
ugly.
Re: [Android] WebView, InAppBrowser and UI Threads
Posted by Andrew Grieve <ag...@chromium.org>.
On Thu, Sep 19, 2013 at 3:06 PM, Jesse <pu...@gmail.com> wrote:
> Is this the use case ?
>
> window.open('subFldr/page.html','_blank');
>
> or are you talking about the page inside the iab loading another page
> via relative url?
>
I think that's the use case.
>
>
>
> Sent from my iPhone
>
> > On Sep 19, 2013, at 9:31 AM, Andrew Grieve <ag...@chromium.org> wrote:
> >
> > You suggested making relative URLs a developer concern. I thought by this
> > you meant our plugins shouldn't support relative URLs. Not supporting
> > relative URLs would be broken IMO. Maybe you meant something different by
> > that?
> >
> >
> > On Thu, Sep 19, 2013 at 11:48 AM, purplecabbage <purplecabbage@gmail.com
> >wrote:
> >
> >> Andrew, can you post a detailed use case of what you think is broken
> with
> >> URL resolution? I think I am missing something.
> >>
> >> Sent from my iPhone
> >>
> >>> On Sep 19, 2013, at 7:35 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
> >>>
> >>> On Thu, Sep 19, 2013 at 3:50 AM, purplecabbage <
> purplecabbage@gmail.com
> >>> wrote:
> >>>
> >>>> Why don't we make relative urls a developer concern? The developer
> >> should
> >>>> know their own package, and it can be easily resolved using current
> >>>> window.location and expected location of the file.
> >>> URLs are such a core piece of web APIs, that I think it would be quite
> >> bad
> >>> if we didn't properly support them (plus it's quite easy to do).
> >>>
> >>>
> >>>
> >>>>
> >>>> A minor rant, while we are on the subject of iab:
> >>>>
> >>>> I don't understand why this executeScript madness was added. Why not
> >> just
> >>>> call for a new URL with a javascript:prefix ?
> >>>> If you want a full blown web-browser control then make a new plugin,
> iab
> >>>> (originally ChildBrowser) was intended to show potentially unsafe code
> >>>> inside your app without risk. The API is already non-standard, and
> worse
> >>>> still it mimics a standard api but mutated. There are probably
> security
> >>>> implications to all of these choices as well.
> >>> Native app WebView controls can inject JS, so why would we make ours
> less
> >>> powerful?
> >>>
> >>>
> >>>
> >>>>
> >>>> What is the use-case for insertCSS? Is it to load someone else's html
> >> with
> >>>> your style sheet?
> >>> That would be my guess.
> >>>
> >>>
> >>>>
> >>>> Sent from my iPhone
> >>>>
> >>>>> On Sep 18, 2013, at 7:31 PM, Andrew Grieve <ag...@chromium.org>
> >> wrote:
> >>>>>
> >>>>> I assigned it to David just because I thought it would be a good bug
> >> for
> >>>>> him and thought it sounded important to fix. I don't think he's in
> any
> >>>>> hurry to get to it, so feel free to assign it to yourself. I don't
> >> really
> >>>>> consider bugs to be actually assigned when they are assigned to the
> >>>> default
> >>>>> person since it's not clear that anyone's looked at it. Maybe it'd be
> >>>> worth
> >>>>> having new bugs come in as "unassigned", so that when someone assigns
> >> it,
> >>>>> it's more meaningful. I'll start another thread to discuss this idea.
> >>>>>
> >>>>> Anyways, I've thought a good amount about this problem previously
> (what
> >>>> to
> >>>>> do with relative URLs), and I think the best solution is to resolve
> >>>>> relative URLs in JS. iOS also has no good way of resolving relative
> >> URLs
> >>>>> from native. I added a function to do just that in this release -
> >>>>> require('cordova/urlutil').makeAbsolute(url)
> >>>>>
> >>>>> I'll make a note of this on the bug.
> >>>>>
> >>>>>
> >>>>>> On Wed, Sep 18, 2013 at 5:21 PM, Joe Bowser <bo...@gmail.com>
> >> wrote:
> >>>>>>
> >>>>>> I'm currently trying to figure out CB-4858, which got assigned to
> >>>>>> David, but I'm finding that I'm getting stuck at this part:
> >>>>>>
> >>>>>>
> >>>>>> private String updateUrl(String url) {
> >>>>>> Uri newUrl = Uri.parse(url);
> >>>>>> if (newUrl.isRelative()) {
> >>>>>> //url = this.webView.getUrl().substring(0,
> >>>>>> this.webView.getUrl().lastIndexOf("/")+1) + url;
> >>>>>> }
> >>>>>> return url;
> >>>>>> }
> >>>>>>
> >>>>>> The problem with this code is that all methods on the WebView class
> >>>>>> must run on the UI thread. Now, there's no easy way for us to pass
> >>>>>> this data back because now we're doing asynchronous Java where we
> have
> >>>>>> to wait for the UI thread to give us back the URL so we can find out
> >>>>>> what our base path is.
> >>>>>>
> >>>>>> We could override this in CordovaWebView, getting around the check,
> >>>>>> but I think that this might not be the right thing to do.
> >>>>>>
> >>>>>> Anyway, I'm content letting David chew on this, since I didn't know
> it
> >>>>>> got assigned to him (JIRA didn't send me the e-mail), but I'd be
> >>>>>> interested in seeing how this gets solved, because it's particularly
> >>>>>> ugly.
> >>
>
Re: [Android] WebView, InAppBrowser and UI Threads
Posted by Jesse <pu...@gmail.com>.
Is this the use case ?
window.open('subFldr/page.html','_blank');
or are you talking about the page inside the iab loading another page
via relative url?
Sent from my iPhone
> On Sep 19, 2013, at 9:31 AM, Andrew Grieve <ag...@chromium.org> wrote:
>
> You suggested making relative URLs a developer concern. I thought by this
> you meant our plugins shouldn't support relative URLs. Not supporting
> relative URLs would be broken IMO. Maybe you meant something different by
> that?
>
>
> On Thu, Sep 19, 2013 at 11:48 AM, purplecabbage <pu...@gmail.com>wrote:
>
>> Andrew, can you post a detailed use case of what you think is broken with
>> URL resolution? I think I am missing something.
>>
>> Sent from my iPhone
>>
>>> On Sep 19, 2013, at 7:35 AM, Andrew Grieve <ag...@chromium.org> wrote:
>>>
>>> On Thu, Sep 19, 2013 at 3:50 AM, purplecabbage <purplecabbage@gmail.com
>>> wrote:
>>>
>>>> Why don't we make relative urls a developer concern? The developer
>> should
>>>> know their own package, and it can be easily resolved using current
>>>> window.location and expected location of the file.
>>> URLs are such a core piece of web APIs, that I think it would be quite
>> bad
>>> if we didn't properly support them (plus it's quite easy to do).
>>>
>>>
>>>
>>>>
>>>> A minor rant, while we are on the subject of iab:
>>>>
>>>> I don't understand why this executeScript madness was added. Why not
>> just
>>>> call for a new URL with a javascript:prefix ?
>>>> If you want a full blown web-browser control then make a new plugin, iab
>>>> (originally ChildBrowser) was intended to show potentially unsafe code
>>>> inside your app without risk. The API is already non-standard, and worse
>>>> still it mimics a standard api but mutated. There are probably security
>>>> implications to all of these choices as well.
>>> Native app WebView controls can inject JS, so why would we make ours less
>>> powerful?
>>>
>>>
>>>
>>>>
>>>> What is the use-case for insertCSS? Is it to load someone else's html
>> with
>>>> your style sheet?
>>> That would be my guess.
>>>
>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Sep 18, 2013, at 7:31 PM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>>>>>
>>>>> I assigned it to David just because I thought it would be a good bug
>> for
>>>>> him and thought it sounded important to fix. I don't think he's in any
>>>>> hurry to get to it, so feel free to assign it to yourself. I don't
>> really
>>>>> consider bugs to be actually assigned when they are assigned to the
>>>> default
>>>>> person since it's not clear that anyone's looked at it. Maybe it'd be
>>>> worth
>>>>> having new bugs come in as "unassigned", so that when someone assigns
>> it,
>>>>> it's more meaningful. I'll start another thread to discuss this idea.
>>>>>
>>>>> Anyways, I've thought a good amount about this problem previously (what
>>>> to
>>>>> do with relative URLs), and I think the best solution is to resolve
>>>>> relative URLs in JS. iOS also has no good way of resolving relative
>> URLs
>>>>> from native. I added a function to do just that in this release -
>>>>> require('cordova/urlutil').makeAbsolute(url)
>>>>>
>>>>> I'll make a note of this on the bug.
>>>>>
>>>>>
>>>>>> On Wed, Sep 18, 2013 at 5:21 PM, Joe Bowser <bo...@gmail.com>
>> wrote:
>>>>>>
>>>>>> I'm currently trying to figure out CB-4858, which got assigned to
>>>>>> David, but I'm finding that I'm getting stuck at this part:
>>>>>>
>>>>>>
>>>>>> private String updateUrl(String url) {
>>>>>> Uri newUrl = Uri.parse(url);
>>>>>> if (newUrl.isRelative()) {
>>>>>> //url = this.webView.getUrl().substring(0,
>>>>>> this.webView.getUrl().lastIndexOf("/")+1) + url;
>>>>>> }
>>>>>> return url;
>>>>>> }
>>>>>>
>>>>>> The problem with this code is that all methods on the WebView class
>>>>>> must run on the UI thread. Now, there's no easy way for us to pass
>>>>>> this data back because now we're doing asynchronous Java where we have
>>>>>> to wait for the UI thread to give us back the URL so we can find out
>>>>>> what our base path is.
>>>>>>
>>>>>> We could override this in CordovaWebView, getting around the check,
>>>>>> but I think that this might not be the right thing to do.
>>>>>>
>>>>>> Anyway, I'm content letting David chew on this, since I didn't know it
>>>>>> got assigned to him (JIRA didn't send me the e-mail), but I'd be
>>>>>> interested in seeing how this gets solved, because it's particularly
>>>>>> ugly.
>>
Re: [Android] WebView, InAppBrowser and UI Threads
Posted by Andrew Grieve <ag...@chromium.org>.
You suggested making relative URLs a developer concern. I thought by this
you meant our plugins shouldn't support relative URLs. Not supporting
relative URLs would be broken IMO. Maybe you meant something different by
that?
On Thu, Sep 19, 2013 at 11:48 AM, purplecabbage <pu...@gmail.com>wrote:
> Andrew, can you post a detailed use case of what you think is broken with
> URL resolution? I think I am missing something.
>
> Sent from my iPhone
>
> > On Sep 19, 2013, at 7:35 AM, Andrew Grieve <ag...@chromium.org> wrote:
> >
> > On Thu, Sep 19, 2013 at 3:50 AM, purplecabbage <purplecabbage@gmail.com
> >wrote:
> >
> >> Why don't we make relative urls a developer concern? The developer
> should
> >> know their own package, and it can be easily resolved using current
> >> window.location and expected location of the file.
> > URLs are such a core piece of web APIs, that I think it would be quite
> bad
> > if we didn't properly support them (plus it's quite easy to do).
> >
> >
> >
> >>
> >> A minor rant, while we are on the subject of iab:
> >>
> >> I don't understand why this executeScript madness was added. Why not
> just
> >> call for a new URL with a javascript:prefix ?
> >> If you want a full blown web-browser control then make a new plugin, iab
> >> (originally ChildBrowser) was intended to show potentially unsafe code
> >> inside your app without risk. The API is already non-standard, and worse
> >> still it mimics a standard api but mutated. There are probably security
> >> implications to all of these choices as well.
> > Native app WebView controls can inject JS, so why would we make ours less
> > powerful?
> >
> >
> >
> >>
> >> What is the use-case for insertCSS? Is it to load someone else's html
> with
> >> your style sheet?
> > That would be my guess.
> >
> >
> >>
> >> Sent from my iPhone
> >>
> >>> On Sep 18, 2013, at 7:31 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> >>>
> >>> I assigned it to David just because I thought it would be a good bug
> for
> >>> him and thought it sounded important to fix. I don't think he's in any
> >>> hurry to get to it, so feel free to assign it to yourself. I don't
> really
> >>> consider bugs to be actually assigned when they are assigned to the
> >> default
> >>> person since it's not clear that anyone's looked at it. Maybe it'd be
> >> worth
> >>> having new bugs come in as "unassigned", so that when someone assigns
> it,
> >>> it's more meaningful. I'll start another thread to discuss this idea.
> >>>
> >>> Anyways, I've thought a good amount about this problem previously (what
> >> to
> >>> do with relative URLs), and I think the best solution is to resolve
> >>> relative URLs in JS. iOS also has no good way of resolving relative
> URLs
> >>> from native. I added a function to do just that in this release -
> >>> require('cordova/urlutil').makeAbsolute(url)
> >>>
> >>> I'll make a note of this on the bug.
> >>>
> >>>
> >>>> On Wed, Sep 18, 2013 at 5:21 PM, Joe Bowser <bo...@gmail.com>
> wrote:
> >>>>
> >>>> I'm currently trying to figure out CB-4858, which got assigned to
> >>>> David, but I'm finding that I'm getting stuck at this part:
> >>>>
> >>>>
> >>>> private String updateUrl(String url) {
> >>>> Uri newUrl = Uri.parse(url);
> >>>> if (newUrl.isRelative()) {
> >>>> //url = this.webView.getUrl().substring(0,
> >>>> this.webView.getUrl().lastIndexOf("/")+1) + url;
> >>>> }
> >>>> return url;
> >>>> }
> >>>>
> >>>> The problem with this code is that all methods on the WebView class
> >>>> must run on the UI thread. Now, there's no easy way for us to pass
> >>>> this data back because now we're doing asynchronous Java where we have
> >>>> to wait for the UI thread to give us back the URL so we can find out
> >>>> what our base path is.
> >>>>
> >>>> We could override this in CordovaWebView, getting around the check,
> >>>> but I think that this might not be the right thing to do.
> >>>>
> >>>> Anyway, I'm content letting David chew on this, since I didn't know it
> >>>> got assigned to him (JIRA didn't send me the e-mail), but I'd be
> >>>> interested in seeing how this gets solved, because it's particularly
> >>>> ugly.
> >>
>
Re: [Android] WebView, InAppBrowser and UI Threads
Posted by purplecabbage <pu...@gmail.com>.
Andrew, can you post a detailed use case of what you think is broken with URL resolution? I think I am missing something.
Sent from my iPhone
> On Sep 19, 2013, at 7:35 AM, Andrew Grieve <ag...@chromium.org> wrote:
>
> On Thu, Sep 19, 2013 at 3:50 AM, purplecabbage <pu...@gmail.com>wrote:
>
>> Why don't we make relative urls a developer concern? The developer should
>> know their own package, and it can be easily resolved using current
>> window.location and expected location of the file.
> URLs are such a core piece of web APIs, that I think it would be quite bad
> if we didn't properly support them (plus it's quite easy to do).
>
>
>
>>
>> A minor rant, while we are on the subject of iab:
>>
>> I don't understand why this executeScript madness was added. Why not just
>> call for a new URL with a javascript:prefix ?
>> If you want a full blown web-browser control then make a new plugin, iab
>> (originally ChildBrowser) was intended to show potentially unsafe code
>> inside your app without risk. The API is already non-standard, and worse
>> still it mimics a standard api but mutated. There are probably security
>> implications to all of these choices as well.
> Native app WebView controls can inject JS, so why would we make ours less
> powerful?
>
>
>
>>
>> What is the use-case for insertCSS? Is it to load someone else's html with
>> your style sheet?
> That would be my guess.
>
>
>>
>> Sent from my iPhone
>>
>>> On Sep 18, 2013, at 7:31 PM, Andrew Grieve <ag...@chromium.org> wrote:
>>>
>>> I assigned it to David just because I thought it would be a good bug for
>>> him and thought it sounded important to fix. I don't think he's in any
>>> hurry to get to it, so feel free to assign it to yourself. I don't really
>>> consider bugs to be actually assigned when they are assigned to the
>> default
>>> person since it's not clear that anyone's looked at it. Maybe it'd be
>> worth
>>> having new bugs come in as "unassigned", so that when someone assigns it,
>>> it's more meaningful. I'll start another thread to discuss this idea.
>>>
>>> Anyways, I've thought a good amount about this problem previously (what
>> to
>>> do with relative URLs), and I think the best solution is to resolve
>>> relative URLs in JS. iOS also has no good way of resolving relative URLs
>>> from native. I added a function to do just that in this release -
>>> require('cordova/urlutil').makeAbsolute(url)
>>>
>>> I'll make a note of this on the bug.
>>>
>>>
>>>> On Wed, Sep 18, 2013 at 5:21 PM, Joe Bowser <bo...@gmail.com> wrote:
>>>>
>>>> I'm currently trying to figure out CB-4858, which got assigned to
>>>> David, but I'm finding that I'm getting stuck at this part:
>>>>
>>>>
>>>> private String updateUrl(String url) {
>>>> Uri newUrl = Uri.parse(url);
>>>> if (newUrl.isRelative()) {
>>>> //url = this.webView.getUrl().substring(0,
>>>> this.webView.getUrl().lastIndexOf("/")+1) + url;
>>>> }
>>>> return url;
>>>> }
>>>>
>>>> The problem with this code is that all methods on the WebView class
>>>> must run on the UI thread. Now, there's no easy way for us to pass
>>>> this data back because now we're doing asynchronous Java where we have
>>>> to wait for the UI thread to give us back the URL so we can find out
>>>> what our base path is.
>>>>
>>>> We could override this in CordovaWebView, getting around the check,
>>>> but I think that this might not be the right thing to do.
>>>>
>>>> Anyway, I'm content letting David chew on this, since I didn't know it
>>>> got assigned to him (JIRA didn't send me the e-mail), but I'd be
>>>> interested in seeing how this gets solved, because it's particularly
>>>> ugly.
>>
Re: [Android] WebView, InAppBrowser and UI Threads
Posted by Andrew Grieve <ag...@chromium.org>.
On Thu, Sep 19, 2013 at 3:50 AM, purplecabbage <pu...@gmail.com>wrote:
> Why don't we make relative urls a developer concern? The developer should
> know their own package, and it can be easily resolved using current
> window.location and expected location of the file.
>
URLs are such a core piece of web APIs, that I think it would be quite bad
if we didn't properly support them (plus it's quite easy to do).
>
> A minor rant, while we are on the subject of iab:
>
> I don't understand why this executeScript madness was added. Why not just
> call for a new URL with a javascript:prefix ?
> If you want a full blown web-browser control then make a new plugin, iab
> (originally ChildBrowser) was intended to show potentially unsafe code
> inside your app without risk. The API is already non-standard, and worse
> still it mimics a standard api but mutated. There are probably security
> implications to all of these choices as well.
>
Native app WebView controls can inject JS, so why would we make ours less
powerful?
>
> What is the use-case for insertCSS? Is it to load someone else's html with
> your style sheet?
>
That would be my guess.
>
> Sent from my iPhone
>
> > On Sep 18, 2013, at 7:31 PM, Andrew Grieve <ag...@chromium.org> wrote:
> >
> > I assigned it to David just because I thought it would be a good bug for
> > him and thought it sounded important to fix. I don't think he's in any
> > hurry to get to it, so feel free to assign it to yourself. I don't really
> > consider bugs to be actually assigned when they are assigned to the
> default
> > person since it's not clear that anyone's looked at it. Maybe it'd be
> worth
> > having new bugs come in as "unassigned", so that when someone assigns it,
> > it's more meaningful. I'll start another thread to discuss this idea.
> >
> > Anyways, I've thought a good amount about this problem previously (what
> to
> > do with relative URLs), and I think the best solution is to resolve
> > relative URLs in JS. iOS also has no good way of resolving relative URLs
> > from native. I added a function to do just that in this release -
> > require('cordova/urlutil').makeAbsolute(url)
> >
> > I'll make a note of this on the bug.
> >
> >
> >> On Wed, Sep 18, 2013 at 5:21 PM, Joe Bowser <bo...@gmail.com> wrote:
> >>
> >> I'm currently trying to figure out CB-4858, which got assigned to
> >> David, but I'm finding that I'm getting stuck at this part:
> >>
> >>
> >> private String updateUrl(String url) {
> >> Uri newUrl = Uri.parse(url);
> >> if (newUrl.isRelative()) {
> >> //url = this.webView.getUrl().substring(0,
> >> this.webView.getUrl().lastIndexOf("/")+1) + url;
> >> }
> >> return url;
> >> }
> >>
> >> The problem with this code is that all methods on the WebView class
> >> must run on the UI thread. Now, there's no easy way for us to pass
> >> this data back because now we're doing asynchronous Java where we have
> >> to wait for the UI thread to give us back the URL so we can find out
> >> what our base path is.
> >>
> >> We could override this in CordovaWebView, getting around the check,
> >> but I think that this might not be the right thing to do.
> >>
> >> Anyway, I'm content letting David chew on this, since I didn't know it
> >> got assigned to him (JIRA didn't send me the e-mail), but I'd be
> >> interested in seeing how this gets solved, because it's particularly
> >> ugly.
> >>
>
Re: [Android] WebView, InAppBrowser and UI Threads
Posted by purplecabbage <pu...@gmail.com>.
Why don't we make relative urls a developer concern? The developer should know their own package, and it can be easily resolved using current window.location and expected location of the file.
A minor rant, while we are on the subject of iab:
I don't understand why this executeScript madness was added. Why not just call for a new URL with a javascript:prefix ?
If you want a full blown web-browser control then make a new plugin, iab (originally ChildBrowser) was intended to show potentially unsafe code inside your app without risk. The API is already non-standard, and worse still it mimics a standard api but mutated. There are probably security implications to all of these choices as well.
What is the use-case for insertCSS? Is it to load someone else's html with your style sheet?
Sent from my iPhone
> On Sep 18, 2013, at 7:31 PM, Andrew Grieve <ag...@chromium.org> wrote:
>
> I assigned it to David just because I thought it would be a good bug for
> him and thought it sounded important to fix. I don't think he's in any
> hurry to get to it, so feel free to assign it to yourself. I don't really
> consider bugs to be actually assigned when they are assigned to the default
> person since it's not clear that anyone's looked at it. Maybe it'd be worth
> having new bugs come in as "unassigned", so that when someone assigns it,
> it's more meaningful. I'll start another thread to discuss this idea.
>
> Anyways, I've thought a good amount about this problem previously (what to
> do with relative URLs), and I think the best solution is to resolve
> relative URLs in JS. iOS also has no good way of resolving relative URLs
> from native. I added a function to do just that in this release -
> require('cordova/urlutil').makeAbsolute(url)
>
> I'll make a note of this on the bug.
>
>
>> On Wed, Sep 18, 2013 at 5:21 PM, Joe Bowser <bo...@gmail.com> wrote:
>>
>> I'm currently trying to figure out CB-4858, which got assigned to
>> David, but I'm finding that I'm getting stuck at this part:
>>
>>
>> private String updateUrl(String url) {
>> Uri newUrl = Uri.parse(url);
>> if (newUrl.isRelative()) {
>> //url = this.webView.getUrl().substring(0,
>> this.webView.getUrl().lastIndexOf("/")+1) + url;
>> }
>> return url;
>> }
>>
>> The problem with this code is that all methods on the WebView class
>> must run on the UI thread. Now, there's no easy way for us to pass
>> this data back because now we're doing asynchronous Java where we have
>> to wait for the UI thread to give us back the URL so we can find out
>> what our base path is.
>>
>> We could override this in CordovaWebView, getting around the check,
>> but I think that this might not be the right thing to do.
>>
>> Anyway, I'm content letting David chew on this, since I didn't know it
>> got assigned to him (JIRA didn't send me the e-mail), but I'd be
>> interested in seeing how this gets solved, because it's particularly
>> ugly.
>>
Re: [Android] WebView, InAppBrowser and UI Threads
Posted by Michal Mocny <mm...@chromium.org>.
(FWIW, I've assumed any bug is up for grabs if it isn't marked "in
progress", regardless of who is assigned.)
On Wed, Sep 18, 2013 at 7:31 PM, Andrew Grieve <ag...@chromium.org> wrote:
> I assigned it to David just because I thought it would be a good bug for
> him and thought it sounded important to fix. I don't think he's in any
> hurry to get to it, so feel free to assign it to yourself. I don't really
> consider bugs to be actually assigned when they are assigned to the default
> person since it's not clear that anyone's looked at it. Maybe it'd be worth
> having new bugs come in as "unassigned", so that when someone assigns it,
> it's more meaningful. I'll start another thread to discuss this idea.
>
> Anyways, I've thought a good amount about this problem previously (what to
> do with relative URLs), and I think the best solution is to resolve
> relative URLs in JS. iOS also has no good way of resolving relative URLs
> from native. I added a function to do just that in this release -
> require('cordova/urlutil').makeAbsolute(url)
>
> I'll make a note of this on the bug.
>
>
> On Wed, Sep 18, 2013 at 5:21 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > I'm currently trying to figure out CB-4858, which got assigned to
> > David, but I'm finding that I'm getting stuck at this part:
> >
> >
> > private String updateUrl(String url) {
> > Uri newUrl = Uri.parse(url);
> > if (newUrl.isRelative()) {
> > //url = this.webView.getUrl().substring(0,
> > this.webView.getUrl().lastIndexOf("/")+1) + url;
> > }
> > return url;
> > }
> >
> > The problem with this code is that all methods on the WebView class
> > must run on the UI thread. Now, there's no easy way for us to pass
> > this data back because now we're doing asynchronous Java where we have
> > to wait for the UI thread to give us back the URL so we can find out
> > what our base path is.
> >
> > We could override this in CordovaWebView, getting around the check,
> > but I think that this might not be the right thing to do.
> >
> > Anyway, I'm content letting David chew on this, since I didn't know it
> > got assigned to him (JIRA didn't send me the e-mail), but I'd be
> > interested in seeing how this gets solved, because it's particularly
> > ugly.
> >
>
Re: [Android] WebView, InAppBrowser and UI Threads
Posted by Andrew Grieve <ag...@chromium.org>.
I assigned it to David just because I thought it would be a good bug for
him and thought it sounded important to fix. I don't think he's in any
hurry to get to it, so feel free to assign it to yourself. I don't really
consider bugs to be actually assigned when they are assigned to the default
person since it's not clear that anyone's looked at it. Maybe it'd be worth
having new bugs come in as "unassigned", so that when someone assigns it,
it's more meaningful. I'll start another thread to discuss this idea.
Anyways, I've thought a good amount about this problem previously (what to
do with relative URLs), and I think the best solution is to resolve
relative URLs in JS. iOS also has no good way of resolving relative URLs
from native. I added a function to do just that in this release -
require('cordova/urlutil').makeAbsolute(url)
I'll make a note of this on the bug.
On Wed, Sep 18, 2013 at 5:21 PM, Joe Bowser <bo...@gmail.com> wrote:
> I'm currently trying to figure out CB-4858, which got assigned to
> David, but I'm finding that I'm getting stuck at this part:
>
>
> private String updateUrl(String url) {
> Uri newUrl = Uri.parse(url);
> if (newUrl.isRelative()) {
> //url = this.webView.getUrl().substring(0,
> this.webView.getUrl().lastIndexOf("/")+1) + url;
> }
> return url;
> }
>
> The problem with this code is that all methods on the WebView class
> must run on the UI thread. Now, there's no easy way for us to pass
> this data back because now we're doing asynchronous Java where we have
> to wait for the UI thread to give us back the URL so we can find out
> what our base path is.
>
> We could override this in CordovaWebView, getting around the check,
> but I think that this might not be the right thing to do.
>
> Anyway, I'm content letting David chew on this, since I didn't know it
> got assigned to him (JIRA didn't send me the e-mail), but I'd be
> interested in seeing how this gets solved, because it's particularly
> ugly.
>