You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Braden Shepherdson <br...@chromium.org> on 2013/06/19 22:04:11 UTC
Fwd: Media API, DataResource, and empty URLs
The automated tests for Media frequently call new Media() with no URL,
which sends a null to the "create" action. In the past, this got turned
into the string "null" in Java, which was handled as a file named "null"
that didn't exist, and nothing crashed.
DataResource is fine with the files not existing, but it's not fine with
"null" as a filename since it neither has a URL scheme nor is it an
absolute path.
Is there a reason why new Media() should work rather than throwing
IllegalArgumentExceptions for trying to read files with relative paths?
Should I detect and gracefully handle null being given as the media URL in
Javascript? In Java? Should I instead change the mobile-spec tests to use
"file:///dummy" or similar?
Braden
Re: Media API, DataResource, and empty URLs
Posted by Ian Clelland <ic...@google.com>.
On Thu, Jun 20, 2013 at 11:45 AM, Andrew Grieve <ag...@chromium.org>wrote:
> WebView.getUrl() ?
>
>
Or that, modulo any base tags that we detect?
>
> On Thu, Jun 20, 2013 at 9:49 AM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > So the current state of handling URLs in DataResource is: if it has a
> > scheme, all good; if it doesn't and is absolute, also good; if it is
> > relative and has no scheme, throw new IllegalArgumentException.
> >
> > I agree that this behavior is dumb and there should be a sane default for
> > relative URLs, and DataResource should rewrite them. The tricky bit is
> what
> > they should be relative to. file:///android_asset/www? The currently
> loaded
> > page in the WebView? Can we reliably check that in the presence of
> > CordovaView and InAppBrowser?
> >
> > Braden
> >
> >
> > On Thu, Jun 20, 2013 at 12:34 AM, Andrew Grieve <agrieve@chromium.org
> > >wrote:
> >
> > > Agree that we should make Media() an error, but we don't want to change
> > the
> > > semantics of relative URLs for APIs without proper deprecation.
> > >
> > >
> > > On Thu, Jun 20, 2013 at 12:00 AM, Ian Clelland <ic...@google.com>
> > > wrote:
> > >
> > > > On Wed, Jun 19, 2013 at 7:41 PM, Andrew Grieve <agrieve@chromium.org
> >
> > > > wrote:
> > > >
> > > > > "null" could be interpreted as a relative URL I think. The current
> > > > handling
> > > > > of relative URLs by plugins is sadly plugin-specific.
> > > > >
> > > >
> > > > Isn't that one of the things that DataResource is supposed to
> > > standardize?
> > > >
> > > >
> > > > The string "null" is certainly a relative URL, and all plugins should
> > > > interpret that as one. The empty string is a relative url as well.
> (See
> > > the
> > > > 'image src=""' problem). DataResource should probably handle relative
> > > URLs;
> > > > that seems like a deficiency if it can't.
> > > >
> > > > We shouldn't be representing the JavaScript null value as "null", or
> as
> > > "",
> > > > though. I don't think there's any rational reason to support new
> > Media()
> > > as
> > > > a construct. Media is fairly clearly documented as taking two
> required
> > > > parameters, and two optional ones. I don't think Media() makes sense
> --
> > > it
> > > > doesn't give you a useful object. The calls to Media() are likely
> just
> > in
> > > > mobile-spec, and we should clean those up.
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > On Wed, Jun 19, 2013 at 4:04 PM, Braden Shepherdson <
> > > braden@chromium.org
> > > > > >wrote:
> > > > >
> > > > > > The automated tests for Media frequently call new Media() with no
> > > URL,
> > > > > > which sends a null to the "create" action. In the past, this got
> > > turned
> > > > > > into the string "null" in Java, which was handled as a file named
> > > > "null"
> > > > > > that didn't exist, and nothing crashed.
> > > > > >
> > > > > > DataResource is fine with the files not existing, but it's not
> fine
> > > > with
> > > > > > "null" as a filename since it neither has a URL scheme nor is it
> an
> > > > > > absolute path.
> > > > > >
> > > > > > Is there a reason why new Media() should work rather than
> throwing
> > > > > > IllegalArgumentExceptions for trying to read files with relative
> > > paths?
> > > > > > Should I detect and gracefully handle null being given as the
> media
> > > URL
> > > > > in
> > > > > > Javascript? In Java? Should I instead change the mobile-spec
> tests
> > to
> > > > use
> > > > > > "file:///dummy" or similar?
> > > > > >
> > > > > > Braden
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Media API, DataResource, and empty URLs
Posted by Andrew Grieve <ag...@chromium.org>.
WebView.getUrl() ?
On Thu, Jun 20, 2013 at 9:49 AM, Braden Shepherdson <br...@chromium.org>wrote:
> So the current state of handling URLs in DataResource is: if it has a
> scheme, all good; if it doesn't and is absolute, also good; if it is
> relative and has no scheme, throw new IllegalArgumentException.
>
> I agree that this behavior is dumb and there should be a sane default for
> relative URLs, and DataResource should rewrite them. The tricky bit is what
> they should be relative to. file:///android_asset/www? The currently loaded
> page in the WebView? Can we reliably check that in the presence of
> CordovaView and InAppBrowser?
>
> Braden
>
>
> On Thu, Jun 20, 2013 at 12:34 AM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > Agree that we should make Media() an error, but we don't want to change
> the
> > semantics of relative URLs for APIs without proper deprecation.
> >
> >
> > On Thu, Jun 20, 2013 at 12:00 AM, Ian Clelland <ic...@google.com>
> > wrote:
> >
> > > On Wed, Jun 19, 2013 at 7:41 PM, Andrew Grieve <ag...@chromium.org>
> > > wrote:
> > >
> > > > "null" could be interpreted as a relative URL I think. The current
> > > handling
> > > > of relative URLs by plugins is sadly plugin-specific.
> > > >
> > >
> > > Isn't that one of the things that DataResource is supposed to
> > standardize?
> > >
> > >
> > > The string "null" is certainly a relative URL, and all plugins should
> > > interpret that as one. The empty string is a relative url as well. (See
> > the
> > > 'image src=""' problem). DataResource should probably handle relative
> > URLs;
> > > that seems like a deficiency if it can't.
> > >
> > > We shouldn't be representing the JavaScript null value as "null", or as
> > "",
> > > though. I don't think there's any rational reason to support new
> Media()
> > as
> > > a construct. Media is fairly clearly documented as taking two required
> > > parameters, and two optional ones. I don't think Media() makes sense --
> > it
> > > doesn't give you a useful object. The calls to Media() are likely just
> in
> > > mobile-spec, and we should clean those up.
> > >
> > >
> > >
> > >
> > > >
> > > > On Wed, Jun 19, 2013 at 4:04 PM, Braden Shepherdson <
> > braden@chromium.org
> > > > >wrote:
> > > >
> > > > > The automated tests for Media frequently call new Media() with no
> > URL,
> > > > > which sends a null to the "create" action. In the past, this got
> > turned
> > > > > into the string "null" in Java, which was handled as a file named
> > > "null"
> > > > > that didn't exist, and nothing crashed.
> > > > >
> > > > > DataResource is fine with the files not existing, but it's not fine
> > > with
> > > > > "null" as a filename since it neither has a URL scheme nor is it an
> > > > > absolute path.
> > > > >
> > > > > Is there a reason why new Media() should work rather than throwing
> > > > > IllegalArgumentExceptions for trying to read files with relative
> > paths?
> > > > > Should I detect and gracefully handle null being given as the media
> > URL
> > > > in
> > > > > Javascript? In Java? Should I instead change the mobile-spec tests
> to
> > > use
> > > > > "file:///dummy" or similar?
> > > > >
> > > > > Braden
> > > > >
> > > >
> > >
> >
>
Re: Media API, DataResource, and empty URLs
Posted by Braden Shepherdson <br...@chromium.org>.
So the current state of handling URLs in DataResource is: if it has a
scheme, all good; if it doesn't and is absolute, also good; if it is
relative and has no scheme, throw new IllegalArgumentException.
I agree that this behavior is dumb and there should be a sane default for
relative URLs, and DataResource should rewrite them. The tricky bit is what
they should be relative to. file:///android_asset/www? The currently loaded
page in the WebView? Can we reliably check that in the presence of
CordovaView and InAppBrowser?
Braden
On Thu, Jun 20, 2013 at 12:34 AM, Andrew Grieve <ag...@chromium.org>wrote:
> Agree that we should make Media() an error, but we don't want to change the
> semantics of relative URLs for APIs without proper deprecation.
>
>
> On Thu, Jun 20, 2013 at 12:00 AM, Ian Clelland <ic...@google.com>
> wrote:
>
> > On Wed, Jun 19, 2013 at 7:41 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> > > "null" could be interpreted as a relative URL I think. The current
> > handling
> > > of relative URLs by plugins is sadly plugin-specific.
> > >
> >
> > Isn't that one of the things that DataResource is supposed to
> standardize?
> >
> >
> > The string "null" is certainly a relative URL, and all plugins should
> > interpret that as one. The empty string is a relative url as well. (See
> the
> > 'image src=""' problem). DataResource should probably handle relative
> URLs;
> > that seems like a deficiency if it can't.
> >
> > We shouldn't be representing the JavaScript null value as "null", or as
> "",
> > though. I don't think there's any rational reason to support new Media()
> as
> > a construct. Media is fairly clearly documented as taking two required
> > parameters, and two optional ones. I don't think Media() makes sense --
> it
> > doesn't give you a useful object. The calls to Media() are likely just in
> > mobile-spec, and we should clean those up.
> >
> >
> >
> >
> > >
> > > On Wed, Jun 19, 2013 at 4:04 PM, Braden Shepherdson <
> braden@chromium.org
> > > >wrote:
> > >
> > > > The automated tests for Media frequently call new Media() with no
> URL,
> > > > which sends a null to the "create" action. In the past, this got
> turned
> > > > into the string "null" in Java, which was handled as a file named
> > "null"
> > > > that didn't exist, and nothing crashed.
> > > >
> > > > DataResource is fine with the files not existing, but it's not fine
> > with
> > > > "null" as a filename since it neither has a URL scheme nor is it an
> > > > absolute path.
> > > >
> > > > Is there a reason why new Media() should work rather than throwing
> > > > IllegalArgumentExceptions for trying to read files with relative
> paths?
> > > > Should I detect and gracefully handle null being given as the media
> URL
> > > in
> > > > Javascript? In Java? Should I instead change the mobile-spec tests to
> > use
> > > > "file:///dummy" or similar?
> > > >
> > > > Braden
> > > >
> > >
> >
>
Re: Media API, DataResource, and empty URLs
Posted by Andrew Grieve <ag...@chromium.org>.
Agree that we should make Media() an error, but we don't want to change the
semantics of relative URLs for APIs without proper deprecation.
On Thu, Jun 20, 2013 at 12:00 AM, Ian Clelland <ic...@google.com> wrote:
> On Wed, Jun 19, 2013 at 7:41 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > "null" could be interpreted as a relative URL I think. The current
> handling
> > of relative URLs by plugins is sadly plugin-specific.
> >
>
> Isn't that one of the things that DataResource is supposed to standardize?
>
>
> The string "null" is certainly a relative URL, and all plugins should
> interpret that as one. The empty string is a relative url as well. (See the
> 'image src=""' problem). DataResource should probably handle relative URLs;
> that seems like a deficiency if it can't.
>
> We shouldn't be representing the JavaScript null value as "null", or as "",
> though. I don't think there's any rational reason to support new Media() as
> a construct. Media is fairly clearly documented as taking two required
> parameters, and two optional ones. I don't think Media() makes sense -- it
> doesn't give you a useful object. The calls to Media() are likely just in
> mobile-spec, and we should clean those up.
>
>
>
>
> >
> > On Wed, Jun 19, 2013 at 4:04 PM, Braden Shepherdson <braden@chromium.org
> > >wrote:
> >
> > > The automated tests for Media frequently call new Media() with no URL,
> > > which sends a null to the "create" action. In the past, this got turned
> > > into the string "null" in Java, which was handled as a file named
> "null"
> > > that didn't exist, and nothing crashed.
> > >
> > > DataResource is fine with the files not existing, but it's not fine
> with
> > > "null" as a filename since it neither has a URL scheme nor is it an
> > > absolute path.
> > >
> > > Is there a reason why new Media() should work rather than throwing
> > > IllegalArgumentExceptions for trying to read files with relative paths?
> > > Should I detect and gracefully handle null being given as the media URL
> > in
> > > Javascript? In Java? Should I instead change the mobile-spec tests to
> use
> > > "file:///dummy" or similar?
> > >
> > > Braden
> > >
> >
>
Re: Media API, DataResource, and empty URLs
Posted by Ian Clelland <ic...@google.com>.
On Wed, Jun 19, 2013 at 7:41 PM, Andrew Grieve <ag...@chromium.org> wrote:
> "null" could be interpreted as a relative URL I think. The current handling
> of relative URLs by plugins is sadly plugin-specific.
>
Isn't that one of the things that DataResource is supposed to standardize?
The string "null" is certainly a relative URL, and all plugins should
interpret that as one. The empty string is a relative url as well. (See the
'image src=""' problem). DataResource should probably handle relative URLs;
that seems like a deficiency if it can't.
We shouldn't be representing the JavaScript null value as "null", or as "",
though. I don't think there's any rational reason to support new Media() as
a construct. Media is fairly clearly documented as taking two required
parameters, and two optional ones. I don't think Media() makes sense -- it
doesn't give you a useful object. The calls to Media() are likely just in
mobile-spec, and we should clean those up.
>
> On Wed, Jun 19, 2013 at 4:04 PM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > The automated tests for Media frequently call new Media() with no URL,
> > which sends a null to the "create" action. In the past, this got turned
> > into the string "null" in Java, which was handled as a file named "null"
> > that didn't exist, and nothing crashed.
> >
> > DataResource is fine with the files not existing, but it's not fine with
> > "null" as a filename since it neither has a URL scheme nor is it an
> > absolute path.
> >
> > Is there a reason why new Media() should work rather than throwing
> > IllegalArgumentExceptions for trying to read files with relative paths?
> > Should I detect and gracefully handle null being given as the media URL
> in
> > Javascript? In Java? Should I instead change the mobile-spec tests to use
> > "file:///dummy" or similar?
> >
> > Braden
> >
>
Re: Media API, DataResource, and empty URLs
Posted by Andrew Grieve <ag...@chromium.org>.
"null" could be interpreted as a relative URL I think. The current handling
of relative URLs by plugins is sadly plugin-specific.
On Wed, Jun 19, 2013 at 4:04 PM, Braden Shepherdson <br...@chromium.org>wrote:
> The automated tests for Media frequently call new Media() with no URL,
> which sends a null to the "create" action. In the past, this got turned
> into the string "null" in Java, which was handled as a file named "null"
> that didn't exist, and nothing crashed.
>
> DataResource is fine with the files not existing, but it's not fine with
> "null" as a filename since it neither has a URL scheme nor is it an
> absolute path.
>
> Is there a reason why new Media() should work rather than throwing
> IllegalArgumentExceptions for trying to read files with relative paths?
> Should I detect and gracefully handle null being given as the media URL in
> Javascript? In Java? Should I instead change the mobile-spec tests to use
> "file:///dummy" or similar?
>
> Braden
>