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 <[email protected]> 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
> <[email protected]>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 <[email protected]> wrote:
>>>
>>> On Thu, Sep 19, 2013 at 3:50 AM, purplecabbage <[email protected]
>>> 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 <[email protected]>
>> 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 <[email protected]>
>> 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.
>>
