Severity: normal → major
Component: Untriaged → Browser
OS: Unspecified → iOS 9
Product: Firefox → Firefox for iOS
Hardware: Unspecified → ARM
Version: Trunk → unspecified
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".
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.
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.
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.
Assignee: nobody → bnicholson
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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.
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?
Assignee: bnicholson → nobody
Status: ASSIGNED → NEW
tracking-fxios: 2.0+ → +
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.