You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Joe Bowser <bo...@gmail.com> on 2013/05/24 19:36:10 UTC
Android Audio isn't broken, the URIs being fed into the audio are
Hey
After looking into the bug further, for some reason URIs such as
http://cordova.apache.org/downloads/BlueZedEx.mp3 are losing slashes
after the protocol. (i.e.
http:/cordova.apache.org/downloads/BlueZedEx.mp3). This is causing
Android to epic fail the media tests and I suspect that it would cause
the same problem in other platforms. Did anything change that would
cause the URIs to be malformed? This is a pretty important thing to
get fixed for 2.8.0rc1, and I don't want to tag until this is
resolved.
Joe
Re: Android Audio isn't broken, the URIs being fed into the audio are
Posted by Max Woghiren <ma...@chromium.org>.
Okay, thanks for checking. I just wanted to make sure it wasn't just my
setup.
I can look into this some more. Have fun at JSConf!
On Mon, May 27, 2013 at 3:59 PM, Joe Bowser <bo...@gmail.com> wrote:
> I saw it fixed on the manual audio tests only. Since it's still
> broken on the Mobile spec on my end, I'm thinking there's more broken
> than I initially thought. Unfortunately, I'm debugging this in
> airports on the way to JSConf today, and MSP doesn't seem to have
> awesome desks like SFO and YVR. I'm squatting a food table with
> outlets at the moment.
>
> I suspect that a change in cordova-js or in the config broke the media
> API. The weird thing is that I still see the calls going through.
>
> On Mon, May 27, 2013 at 2:07 PM, Max Woghiren <ma...@chromium.org> wrote:
> > I'm seeing it in the automatic tests. If you saw it fixed in the
> automatic
> > tests then I probably just need to figure out what's wrong on my end.
> >
> >
> > On Mon, May 27, 2013 at 2:58 PM, Joe Bowser <bo...@gmail.com> wrote:
> >
> >> I meant to test the manual tests. If you're still seeing NPObject,
> >> something is still broken.
> >> On May 27, 2013 1:47 PM, "Max Woghiren" <ma...@chromium.org> wrote:
> >>
> >> > Joe, was your four-line commit intended to fix the "Error calling
> method
> >> on
> >> > NPObject" errors in the automatic Media tests? I'm still getting
> them on
> >> > twelve of those tests. Just want to make sure it's something on my
> end.
> >> >
> >> > On Fri, May 24, 2013 at 2:44 PM, Joe Bowser <bo...@gmail.com>
> wrote:
> >> >
> >> > > I've already fixed this bug! We should be all good now!
> >> > >
> >> > > On Fri, May 24, 2013 at 11:40 AM, Ian Clelland <
> iclelland@chromium.org
> >> >
> >> > > wrote:
> >> > > > Definitely, Joe --
> >> > > >
> >> > > > It looks like Shravan was a little over-eager to apply the
> >> DataResource
> >> > > API
> >> > > > to replace FileHelper, and this is definitely a bug.
> >> > > >
> >> > > > I'm going to revert the changes that he made to AudioHandler.java,
> >> and
> >> > we
> >> > > > can try the media tests again.
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Fri, May 24, 2013 at 1:59 PM, Joe Bowser <bo...@gmail.com>
> >> wrote:
> >> > > >
> >> > > >> OK, I was wrong. It turns out the DataResource code that was
> added
> >> in
> >> > > >> doesn't have support for streaming audio. We need to get this
> fixed
> >> > > >> ASAP. Seriously, we have these tests for a reason. Every time we
> >> > > >> start changing how an API works, we should run the Mobile-Spec
> tests
> >> > > >> to make sure that it's covered. If it's not covered by
> mobile-spec,
> >> > > >> we should create a ticket to write a test for the Android Test
> >> Suite.
> >> > > >>
> >> > > >> The culprit appears to be on line 60 of AudioHandler.java:
> >> > > >>
> >> > > >> public String getFilePath(String url, String source){
> >> > > >> DataResource dataResource =
> >> > > >> DataResource.initiateNewDataRequestForUri(url,
> >> > > >> this.webView.pluginManager, cordova, source);
> >> > > >> return dataResource.getRealFile().getPath();
> >> > > >> }
> >> > > >>
> >> > > >> If it's an web URI, we shouldn't screw with it. Seriously!
> >> > > >>
> >> > > >> Joe
> >> > > >>
> >> > > >> On Fri, May 24, 2013 at 10:36 AM, Joe Bowser <bo...@gmail.com>
> >> > wrote:
> >> > > >> > Hey
> >> > > >> >
> >> > > >> > After looking into the bug further, for some reason URIs such
> as
> >> > > >> > http://cordova.apache.org/downloads/BlueZedEx.mp3 are losing
> >> > slashes
> >> > > >> > after the protocol. (i.e.
> >> > > >> > http:/cordova.apache.org/downloads/BlueZedEx.mp3). This is
> >> causing
> >> > > >> > Android to epic fail the media tests and I suspect that it
> would
> >> > cause
> >> > > >> > the same problem in other platforms. Did anything change that
> >> would
> >> > > >> > cause the URIs to be malformed? This is a pretty important
> thing
> >> to
> >> > > >> > get fixed for 2.8.0rc1, and I don't want to tag until this is
> >> > > >> > resolved.
> >> > > >> >
> >> > > >> > Joe
> >> > > >>
> >> > >
> >> >
> >>
>
Re: Android Audio isn't broken, the URIs being fed into the audio are
Posted by Joe Bowser <bo...@gmail.com>.
I saw it fixed on the manual audio tests only. Since it's still
broken on the Mobile spec on my end, I'm thinking there's more broken
than I initially thought. Unfortunately, I'm debugging this in
airports on the way to JSConf today, and MSP doesn't seem to have
awesome desks like SFO and YVR. I'm squatting a food table with
outlets at the moment.
I suspect that a change in cordova-js or in the config broke the media
API. The weird thing is that I still see the calls going through.
On Mon, May 27, 2013 at 2:07 PM, Max Woghiren <ma...@chromium.org> wrote:
> I'm seeing it in the automatic tests. If you saw it fixed in the automatic
> tests then I probably just need to figure out what's wrong on my end.
>
>
> On Mon, May 27, 2013 at 2:58 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>> I meant to test the manual tests. If you're still seeing NPObject,
>> something is still broken.
>> On May 27, 2013 1:47 PM, "Max Woghiren" <ma...@chromium.org> wrote:
>>
>> > Joe, was your four-line commit intended to fix the "Error calling method
>> on
>> > NPObject" errors in the automatic Media tests? I'm still getting them on
>> > twelve of those tests. Just want to make sure it's something on my end.
>> >
>> > On Fri, May 24, 2013 at 2:44 PM, Joe Bowser <bo...@gmail.com> wrote:
>> >
>> > > I've already fixed this bug! We should be all good now!
>> > >
>> > > On Fri, May 24, 2013 at 11:40 AM, Ian Clelland <iclelland@chromium.org
>> >
>> > > wrote:
>> > > > Definitely, Joe --
>> > > >
>> > > > It looks like Shravan was a little over-eager to apply the
>> DataResource
>> > > API
>> > > > to replace FileHelper, and this is definitely a bug.
>> > > >
>> > > > I'm going to revert the changes that he made to AudioHandler.java,
>> and
>> > we
>> > > > can try the media tests again.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Fri, May 24, 2013 at 1:59 PM, Joe Bowser <bo...@gmail.com>
>> wrote:
>> > > >
>> > > >> OK, I was wrong. It turns out the DataResource code that was added
>> in
>> > > >> doesn't have support for streaming audio. We need to get this fixed
>> > > >> ASAP. Seriously, we have these tests for a reason. Every time we
>> > > >> start changing how an API works, we should run the Mobile-Spec tests
>> > > >> to make sure that it's covered. If it's not covered by mobile-spec,
>> > > >> we should create a ticket to write a test for the Android Test
>> Suite.
>> > > >>
>> > > >> The culprit appears to be on line 60 of AudioHandler.java:
>> > > >>
>> > > >> public String getFilePath(String url, String source){
>> > > >> DataResource dataResource =
>> > > >> DataResource.initiateNewDataRequestForUri(url,
>> > > >> this.webView.pluginManager, cordova, source);
>> > > >> return dataResource.getRealFile().getPath();
>> > > >> }
>> > > >>
>> > > >> If it's an web URI, we shouldn't screw with it. Seriously!
>> > > >>
>> > > >> Joe
>> > > >>
>> > > >> On Fri, May 24, 2013 at 10:36 AM, Joe Bowser <bo...@gmail.com>
>> > wrote:
>> > > >> > Hey
>> > > >> >
>> > > >> > After looking into the bug further, for some reason URIs such as
>> > > >> > http://cordova.apache.org/downloads/BlueZedEx.mp3 are losing
>> > slashes
>> > > >> > after the protocol. (i.e.
>> > > >> > http:/cordova.apache.org/downloads/BlueZedEx.mp3). This is
>> causing
>> > > >> > Android to epic fail the media tests and I suspect that it would
>> > cause
>> > > >> > the same problem in other platforms. Did anything change that
>> would
>> > > >> > cause the URIs to be malformed? This is a pretty important thing
>> to
>> > > >> > get fixed for 2.8.0rc1, and I don't want to tag until this is
>> > > >> > resolved.
>> > > >> >
>> > > >> > Joe
>> > > >>
>> > >
>> >
>>
Re: Android Audio isn't broken, the URIs being fed into the audio are
Posted by Max Woghiren <ma...@chromium.org>.
I'm seeing it in the automatic tests. If you saw it fixed in the automatic
tests then I probably just need to figure out what's wrong on my end.
On Mon, May 27, 2013 at 2:58 PM, Joe Bowser <bo...@gmail.com> wrote:
> I meant to test the manual tests. If you're still seeing NPObject,
> something is still broken.
> On May 27, 2013 1:47 PM, "Max Woghiren" <ma...@chromium.org> wrote:
>
> > Joe, was your four-line commit intended to fix the "Error calling method
> on
> > NPObject" errors in the automatic Media tests? I'm still getting them on
> > twelve of those tests. Just want to make sure it's something on my end.
> >
> > On Fri, May 24, 2013 at 2:44 PM, Joe Bowser <bo...@gmail.com> wrote:
> >
> > > I've already fixed this bug! We should be all good now!
> > >
> > > On Fri, May 24, 2013 at 11:40 AM, Ian Clelland <iclelland@chromium.org
> >
> > > wrote:
> > > > Definitely, Joe --
> > > >
> > > > It looks like Shravan was a little over-eager to apply the
> DataResource
> > > API
> > > > to replace FileHelper, and this is definitely a bug.
> > > >
> > > > I'm going to revert the changes that he made to AudioHandler.java,
> and
> > we
> > > > can try the media tests again.
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, May 24, 2013 at 1:59 PM, Joe Bowser <bo...@gmail.com>
> wrote:
> > > >
> > > >> OK, I was wrong. It turns out the DataResource code that was added
> in
> > > >> doesn't have support for streaming audio. We need to get this fixed
> > > >> ASAP. Seriously, we have these tests for a reason. Every time we
> > > >> start changing how an API works, we should run the Mobile-Spec tests
> > > >> to make sure that it's covered. If it's not covered by mobile-spec,
> > > >> we should create a ticket to write a test for the Android Test
> Suite.
> > > >>
> > > >> The culprit appears to be on line 60 of AudioHandler.java:
> > > >>
> > > >> public String getFilePath(String url, String source){
> > > >> DataResource dataResource =
> > > >> DataResource.initiateNewDataRequestForUri(url,
> > > >> this.webView.pluginManager, cordova, source);
> > > >> return dataResource.getRealFile().getPath();
> > > >> }
> > > >>
> > > >> If it's an web URI, we shouldn't screw with it. Seriously!
> > > >>
> > > >> Joe
> > > >>
> > > >> On Fri, May 24, 2013 at 10:36 AM, Joe Bowser <bo...@gmail.com>
> > wrote:
> > > >> > Hey
> > > >> >
> > > >> > After looking into the bug further, for some reason URIs such as
> > > >> > http://cordova.apache.org/downloads/BlueZedEx.mp3 are losing
> > slashes
> > > >> > after the protocol. (i.e.
> > > >> > http:/cordova.apache.org/downloads/BlueZedEx.mp3). This is
> causing
> > > >> > Android to epic fail the media tests and I suspect that it would
> > cause
> > > >> > the same problem in other platforms. Did anything change that
> would
> > > >> > cause the URIs to be malformed? This is a pretty important thing
> to
> > > >> > get fixed for 2.8.0rc1, and I don't want to tag until this is
> > > >> > resolved.
> > > >> >
> > > >> > Joe
> > > >>
> > >
> >
>
Re: Android Audio isn't broken, the URIs being fed into the audio are
Posted by Joe Bowser <bo...@gmail.com>.
I meant to test the manual tests. If you're still seeing NPObject,
something is still broken.
On May 27, 2013 1:47 PM, "Max Woghiren" <ma...@chromium.org> wrote:
> Joe, was your four-line commit intended to fix the "Error calling method on
> NPObject" errors in the automatic Media tests? I'm still getting them on
> twelve of those tests. Just want to make sure it's something on my end.
>
> On Fri, May 24, 2013 at 2:44 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > I've already fixed this bug! We should be all good now!
> >
> > On Fri, May 24, 2013 at 11:40 AM, Ian Clelland <ic...@chromium.org>
> > wrote:
> > > Definitely, Joe --
> > >
> > > It looks like Shravan was a little over-eager to apply the DataResource
> > API
> > > to replace FileHelper, and this is definitely a bug.
> > >
> > > I'm going to revert the changes that he made to AudioHandler.java, and
> we
> > > can try the media tests again.
> > >
> > >
> > >
> > >
> > > On Fri, May 24, 2013 at 1:59 PM, Joe Bowser <bo...@gmail.com> wrote:
> > >
> > >> OK, I was wrong. It turns out the DataResource code that was added in
> > >> doesn't have support for streaming audio. We need to get this fixed
> > >> ASAP. Seriously, we have these tests for a reason. Every time we
> > >> start changing how an API works, we should run the Mobile-Spec tests
> > >> to make sure that it's covered. If it's not covered by mobile-spec,
> > >> we should create a ticket to write a test for the Android Test Suite.
> > >>
> > >> The culprit appears to be on line 60 of AudioHandler.java:
> > >>
> > >> public String getFilePath(String url, String source){
> > >> DataResource dataResource =
> > >> DataResource.initiateNewDataRequestForUri(url,
> > >> this.webView.pluginManager, cordova, source);
> > >> return dataResource.getRealFile().getPath();
> > >> }
> > >>
> > >> If it's an web URI, we shouldn't screw with it. Seriously!
> > >>
> > >> Joe
> > >>
> > >> On Fri, May 24, 2013 at 10:36 AM, Joe Bowser <bo...@gmail.com>
> wrote:
> > >> > Hey
> > >> >
> > >> > After looking into the bug further, for some reason URIs such as
> > >> > http://cordova.apache.org/downloads/BlueZedEx.mp3 are losing
> slashes
> > >> > after the protocol. (i.e.
> > >> > http:/cordova.apache.org/downloads/BlueZedEx.mp3). This is causing
> > >> > Android to epic fail the media tests and I suspect that it would
> cause
> > >> > the same problem in other platforms. Did anything change that would
> > >> > cause the URIs to be malformed? This is a pretty important thing to
> > >> > get fixed for 2.8.0rc1, and I don't want to tag until this is
> > >> > resolved.
> > >> >
> > >> > Joe
> > >>
> >
>
Re: Android Audio isn't broken, the URIs being fed into the audio are
Posted by Max Woghiren <ma...@chromium.org>.
Joe, was your four-line commit intended to fix the "Error calling method on
NPObject" errors in the automatic Media tests? I'm still getting them on
twelve of those tests. Just want to make sure it's something on my end.
On Fri, May 24, 2013 at 2:44 PM, Joe Bowser <bo...@gmail.com> wrote:
> I've already fixed this bug! We should be all good now!
>
> On Fri, May 24, 2013 at 11:40 AM, Ian Clelland <ic...@chromium.org>
> wrote:
> > Definitely, Joe --
> >
> > It looks like Shravan was a little over-eager to apply the DataResource
> API
> > to replace FileHelper, and this is definitely a bug.
> >
> > I'm going to revert the changes that he made to AudioHandler.java, and we
> > can try the media tests again.
> >
> >
> >
> >
> > On Fri, May 24, 2013 at 1:59 PM, Joe Bowser <bo...@gmail.com> wrote:
> >
> >> OK, I was wrong. It turns out the DataResource code that was added in
> >> doesn't have support for streaming audio. We need to get this fixed
> >> ASAP. Seriously, we have these tests for a reason. Every time we
> >> start changing how an API works, we should run the Mobile-Spec tests
> >> to make sure that it's covered. If it's not covered by mobile-spec,
> >> we should create a ticket to write a test for the Android Test Suite.
> >>
> >> The culprit appears to be on line 60 of AudioHandler.java:
> >>
> >> public String getFilePath(String url, String source){
> >> DataResource dataResource =
> >> DataResource.initiateNewDataRequestForUri(url,
> >> this.webView.pluginManager, cordova, source);
> >> return dataResource.getRealFile().getPath();
> >> }
> >>
> >> If it's an web URI, we shouldn't screw with it. Seriously!
> >>
> >> Joe
> >>
> >> On Fri, May 24, 2013 at 10:36 AM, Joe Bowser <bo...@gmail.com> wrote:
> >> > Hey
> >> >
> >> > After looking into the bug further, for some reason URIs such as
> >> > http://cordova.apache.org/downloads/BlueZedEx.mp3 are losing slashes
> >> > after the protocol. (i.e.
> >> > http:/cordova.apache.org/downloads/BlueZedEx.mp3). This is causing
> >> > Android to epic fail the media tests and I suspect that it would cause
> >> > the same problem in other platforms. Did anything change that would
> >> > cause the URIs to be malformed? This is a pretty important thing to
> >> > get fixed for 2.8.0rc1, and I don't want to tag until this is
> >> > resolved.
> >> >
> >> > Joe
> >>
>
Re: Android Audio isn't broken, the URIs being fed into the audio are
Posted by Joe Bowser <bo...@gmail.com>.
I've already fixed this bug! We should be all good now!
On Fri, May 24, 2013 at 11:40 AM, Ian Clelland <ic...@chromium.org> wrote:
> Definitely, Joe --
>
> It looks like Shravan was a little over-eager to apply the DataResource API
> to replace FileHelper, and this is definitely a bug.
>
> I'm going to revert the changes that he made to AudioHandler.java, and we
> can try the media tests again.
>
>
>
>
> On Fri, May 24, 2013 at 1:59 PM, Joe Bowser <bo...@gmail.com> wrote:
>
>> OK, I was wrong. It turns out the DataResource code that was added in
>> doesn't have support for streaming audio. We need to get this fixed
>> ASAP. Seriously, we have these tests for a reason. Every time we
>> start changing how an API works, we should run the Mobile-Spec tests
>> to make sure that it's covered. If it's not covered by mobile-spec,
>> we should create a ticket to write a test for the Android Test Suite.
>>
>> The culprit appears to be on line 60 of AudioHandler.java:
>>
>> public String getFilePath(String url, String source){
>> DataResource dataResource =
>> DataResource.initiateNewDataRequestForUri(url,
>> this.webView.pluginManager, cordova, source);
>> return dataResource.getRealFile().getPath();
>> }
>>
>> If it's an web URI, we shouldn't screw with it. Seriously!
>>
>> Joe
>>
>> On Fri, May 24, 2013 at 10:36 AM, Joe Bowser <bo...@gmail.com> wrote:
>> > Hey
>> >
>> > After looking into the bug further, for some reason URIs such as
>> > http://cordova.apache.org/downloads/BlueZedEx.mp3 are losing slashes
>> > after the protocol. (i.e.
>> > http:/cordova.apache.org/downloads/BlueZedEx.mp3). This is causing
>> > Android to epic fail the media tests and I suspect that it would cause
>> > the same problem in other platforms. Did anything change that would
>> > cause the URIs to be malformed? This is a pretty important thing to
>> > get fixed for 2.8.0rc1, and I don't want to tag until this is
>> > resolved.
>> >
>> > Joe
>>
Re: Android Audio isn't broken, the URIs being fed into the audio are
Posted by Ian Clelland <ic...@chromium.org>.
Definitely, Joe --
It looks like Shravan was a little over-eager to apply the DataResource API
to replace FileHelper, and this is definitely a bug.
I'm going to revert the changes that he made to AudioHandler.java, and we
can try the media tests again.
On Fri, May 24, 2013 at 1:59 PM, Joe Bowser <bo...@gmail.com> wrote:
> OK, I was wrong. It turns out the DataResource code that was added in
> doesn't have support for streaming audio. We need to get this fixed
> ASAP. Seriously, we have these tests for a reason. Every time we
> start changing how an API works, we should run the Mobile-Spec tests
> to make sure that it's covered. If it's not covered by mobile-spec,
> we should create a ticket to write a test for the Android Test Suite.
>
> The culprit appears to be on line 60 of AudioHandler.java:
>
> public String getFilePath(String url, String source){
> DataResource dataResource =
> DataResource.initiateNewDataRequestForUri(url,
> this.webView.pluginManager, cordova, source);
> return dataResource.getRealFile().getPath();
> }
>
> If it's an web URI, we shouldn't screw with it. Seriously!
>
> Joe
>
> On Fri, May 24, 2013 at 10:36 AM, Joe Bowser <bo...@gmail.com> wrote:
> > Hey
> >
> > After looking into the bug further, for some reason URIs such as
> > http://cordova.apache.org/downloads/BlueZedEx.mp3 are losing slashes
> > after the protocol. (i.e.
> > http:/cordova.apache.org/downloads/BlueZedEx.mp3). This is causing
> > Android to epic fail the media tests and I suspect that it would cause
> > the same problem in other platforms. Did anything change that would
> > cause the URIs to be malformed? This is a pretty important thing to
> > get fixed for 2.8.0rc1, and I don't want to tag until this is
> > resolved.
> >
> > Joe
>
Re: Android Audio isn't broken, the URIs being fed into the audio are
Posted by Ian Clelland <ic...@chromium.org>.
On Fri, May 24, 2013 at 2:38 PM, Joe Bowser <bo...@gmail.com> wrote:
> Hey
>
> I've thrown together a quick 4 line fix to fix it for now, but we need
> to make sure that we actually test things when we change them. This
> change totally broke the Media API on Android, and could have been
> easily avoided. We shouldn't have to wait for the RC1 to find these
> bugs, and people should run the tests now, since about half of the
> issues that come through JIRA could be tested with mobile-spec.
>
Looks like you beat me to it, then. That should be good for now, to get 2.8
out. If you're still planning on refactoring the whole module, then that's
a good chance to make better use of DataResource here. Just skimming
through the code, I can see lots of things I'd like to fix in it.
Ian
Re: Android Audio isn't broken, the URIs being fed into the audio are
Posted by Joe Bowser <bo...@gmail.com>.
Hey
I've thrown together a quick 4 line fix to fix it for now, but we need
to make sure that we actually test things when we change them. This
change totally broke the Media API on Android, and could have been
easily avoided. We shouldn't have to wait for the RC1 to find these
bugs, and people should run the tests now, since about half of the
issues that come through JIRA could be tested with mobile-spec.
On Fri, May 24, 2013 at 10:59 AM, Joe Bowser <bo...@gmail.com> wrote:
> OK, I was wrong. It turns out the DataResource code that was added in
> doesn't have support for streaming audio. We need to get this fixed
> ASAP. Seriously, we have these tests for a reason. Every time we
> start changing how an API works, we should run the Mobile-Spec tests
> to make sure that it's covered. If it's not covered by mobile-spec,
> we should create a ticket to write a test for the Android Test Suite.
>
> The culprit appears to be on line 60 of AudioHandler.java:
>
> public String getFilePath(String url, String source){
> DataResource dataResource =
> DataResource.initiateNewDataRequestForUri(url,
> this.webView.pluginManager, cordova, source);
> return dataResource.getRealFile().getPath();
> }
>
> If it's an web URI, we shouldn't screw with it. Seriously!
>
> Joe
>
> On Fri, May 24, 2013 at 10:36 AM, Joe Bowser <bo...@gmail.com> wrote:
>> Hey
>>
>> After looking into the bug further, for some reason URIs such as
>> http://cordova.apache.org/downloads/BlueZedEx.mp3 are losing slashes
>> after the protocol. (i.e.
>> http:/cordova.apache.org/downloads/BlueZedEx.mp3). This is causing
>> Android to epic fail the media tests and I suspect that it would cause
>> the same problem in other platforms. Did anything change that would
>> cause the URIs to be malformed? This is a pretty important thing to
>> get fixed for 2.8.0rc1, and I don't want to tag until this is
>> resolved.
>>
>> Joe
Re: Android Audio isn't broken, the URIs being fed into the audio are
Posted by Joe Bowser <bo...@gmail.com>.
OK, I was wrong. It turns out the DataResource code that was added in
doesn't have support for streaming audio. We need to get this fixed
ASAP. Seriously, we have these tests for a reason. Every time we
start changing how an API works, we should run the Mobile-Spec tests
to make sure that it's covered. If it's not covered by mobile-spec,
we should create a ticket to write a test for the Android Test Suite.
The culprit appears to be on line 60 of AudioHandler.java:
public String getFilePath(String url, String source){
DataResource dataResource =
DataResource.initiateNewDataRequestForUri(url,
this.webView.pluginManager, cordova, source);
return dataResource.getRealFile().getPath();
}
If it's an web URI, we shouldn't screw with it. Seriously!
Joe
On Fri, May 24, 2013 at 10:36 AM, Joe Bowser <bo...@gmail.com> wrote:
> Hey
>
> After looking into the bug further, for some reason URIs such as
> http://cordova.apache.org/downloads/BlueZedEx.mp3 are losing slashes
> after the protocol. (i.e.
> http:/cordova.apache.org/downloads/BlueZedEx.mp3). This is causing
> Android to epic fail the media tests and I suspect that it would cause
> the same problem in other platforms. Did anything change that would
> cause the URIs to be malformed? This is a pretty important thing to
> get fixed for 2.8.0rc1, and I don't want to tag until this is
> resolved.
>
> Joe