On Thu, Sep 19, 2013 at 3:06 PM, Jesse <purplecabb...@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 <agri...@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 <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.
> >>
>
