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.
>>
