1231157 - http auth dialog for each single media request on ios 9

Status: RESOLVED INVALID

(Firefox for iOS :: Browser, defect)

Description

[persona]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151029151421
Firefox for Android

Steps to reproduce:

We have a web app that is accessed with Basic Auth and loads all necessary html, javascript and images. It relies heavily on speech audio via mp3 files. The mp3 files are loaded only on request (click on it) by way of XHR (using jquery framework). The mp3 files reside in a subdirectory of the same site.


Actual results:

Note, the following happens only with the new Firefox on iOS, not on Windows and not on Mac (I think, I'll recheck).
Each *single* click/request for an mp3 file results in the http auth dialog been shown again (prefilled, as I told Firefox to remember the login data). However, the sound file isn't fetched and played even after submitting the auth dialog again.


Expected results:

There should be only one http auth request when entering the site and never ever after as Firefox should be sending authentication headers with each request to all ressources in that path. This is how it works with Firefox on Windows and Mac.

There is a similar bug open for Firefox on Mac: https://bugzilla.mozilla.org/show_bug.cgi?id=734436
However, I think this has been resolved as I don't remember seeing this happen with OS X.
Further information: Safari on iOS shows a somewhat similar buggy behavior. It just "ignores" the auth request and doesn't show nor honor it after login. So, the result is: no speech and no auth dialogs. So, this problem may be related to some iOS/Apple API?

Comment 1

[persona]

I just notice the "Firefox for Android" on top of my comment. This is wrong, of course. I didn't have any chance to select any other than "Firefox" when I submitted the bug. I edited it afterwards to be for "Firefox for iOS". I think the "Android" is from checking "happens on my phone or tablet".

Comment 2

[Brian Nicholson (:bnicholson)]

I can't reproduce. Can you link to a simple test case?

Here's what I'm trying:
1) Go to http://people.mozilla.org/~bnicholson/test/auth/
2) Enter test:test as username:password.
3) Click the button.
4) See the alert dialog.

The button in step 3 does an XHR for http://people.mozilla.org/~bnicholson/test/auth/text.txt, which is also an authenticated resource in this directory. The text contents are shown in the alert dialog with no additional authentication prompt.

Comment 3

[persona]

Thanks for your attention. I have a repro case for you. But first let me apologize. It's not an XHR, it's HTML5 audio. I wasn't that familiar with the code at that time, it's a huge WebApp that uses XHR for other ressources. I've built a simple example, just using the HTML5AudioElement. You can test here with the same user you used above:
http://mlpro0moz.medilang.info/mlproweb/audio-test2.html

The problem might be specific to HTML5 audio (or media) functionality.
And I think I may have found a second bug (more below).

Login and hit Snap. It launches the Login dialog again and once you submit it it downloads the sound and plays it. You can repeat this and it will ask for the password again, each time you hit the button.
I wrote in my initial bug report that the file is not played either. That's still true, but apparentally only in our WebApp. The audio player function in it is a bit more complex and I don't know where that might be failing. In my example it plays the sound, but launches the login each time. I think once this is fixed our WebApp should be playing the file as well.

Now, for the second bug. Note, that I didn't tell you to hit Click. Do it now. Notice that nothing happens. It doesn't work in Firefox on Windows either. Now fetch the mp3 file and play it in any player on Windows (I tried several). Or other browsers (I tried only IE11). Works fine. 
Firefox on Windows sends this error to the console: "Media resource http://mlpro0moz.medilang.info/mlproweb/audio/effects/click.mp3 could not be decoded." I recoded the file twice with Foobar. Firefox still doesn't like it.
The format of the file may still be incorrect, but if all other programs I tried can play it and recoding doesn't help, I rather guess there's something in the embedded player in Firefox that trips over the file and not a corrupted format.

Comment 4

[persona]

Additional about the click.mp3 bug: Accessing the click.mp3 directly in Firefox on Windows gives a "Video can't be played because the file is corrupt." So, it can't determine the file format or determines a wrong one, it seems.

Comment 5

[Richard Newman [:rnewman]]

I can play click.mp3 in Firefox 46 for Mac. It correctly prompts on the 401, then test:test gives me a 200 and it plays.

Comment 6

[persona]

Funny, yes, I can confirm that it works on Firefox (just downloaded and installed) on OS X. Windows is only on Firefox 44 (why?), I tested on Windows 10 and on XP. It doesn't work there. And it doesn't work on iOS 9. As this is a different bug, should I file it as a new one or can you split this thread to a new bug?