Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of agrieve@google.com designates
 209.85.160.45 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: <523aacc7.6cf5420a.4bd5.0ba4@mx.google.com>
References: 
 <CAOBL_k7e5aN50A_+Tjj1xRYSx9XT6N6WYCKDRCAFUSh03fcqFA@mail.gmail.com>
 <CABiQX1Uh7RzOBFUZPvXx7Jhogegk_iCP_ixTCFYxef=-3aUSow@mail.gmail.com>
 <523aacc7.6cf5420a.4bd5.0ba4@mx.google.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Thu, 19 Sep 2013 10:35:30 -0400
Message-ID: 
 <CABiQX1V_Jn1Log6i+mRN49GpwEv-kaDLP4GaMLafmLo4BW2gog@mail.gmail.com>
Subject: Re: [Android] WebView, InAppBrowser and UI Threads
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b5da81f70809a04e6bd786e

--047d7b5da81f70809a04e6bd786e
Content-Type: text/plain; charset=ISO-8859-1

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 <agrieve@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 <bowserj@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.
> >>
>

--047d7b5da81f70809a04e6bd786e--