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 <purplecabb...@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 <agri...@chromium.org> wrote:
> >
> > On Thu, Sep 19, 2013 at 3:50 AM, purplecabbage <purplecabb...@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 <agri...@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 <bows...@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.
> >>
>

Reply via email to