DOMException: "The fetching process for the media resource was aborted by the user agent at the user's request."
Categories
(Firefox for Android Graveyard :: Audio/Video, defect)
Tracking
(Not tracked)
People
(Reporter: nealbharucha, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
Wrote a program that streams video via WebRTC.
Works completely fine on one Tablet Android version 8.1.0, Samsung Experience version 9.5. Another tablet has the same exact specs, but the video will not load on that.
Installed Firefox 62.0.3 on both. Really didn't mess with anything in about:config in relation to this.
https://stackoverflow.com/questions/57062577/video-tag-wont-autoplay-in-firefox-domexception
Please use this link for more info if needed.
Actual results:
Tablet A: works
Tablet B: Video will not load.
Receives this error, DOMException: "The fetching process for the media resource was aborted by the user agent at the user's request."
Expected results:
Both Tablets should have video working, streams connected and active via WebRTC.
|
||
Comment 1•5 years ago
|
||
Have you tried Firefox 68 on Android?
I'm wondering why you are using / reporting this on 62.0.3?
Version 62 will not receive any further fixes. Version 68 will need some user gesture to allow autoplay.
|
Reporter | |
Comment 2•5 years ago
|
||
(In reply to Karl Tomlinson (:karlt) from comment #1)
Have you tried Firefox 68 on Android?
I'm wondering why you are using / reporting this on 62.0.3?Version 62 will not receive any further fixes. Version 68 will need some user gesture to allow autoplay.
I tried on Firefox Version 68, the latest version, and it still did not work. I had it play onClick (user interaction) and yet the video still would not load.
I tried that same code on Tablet A, which has Version 62.0.3, and it worked perfectly.
Maybe there's a setting or something I need to change within Firefox, in the about:config, that I'm just missing? I pretty much compared the two tablets and everything seems the same except Tablet B has a slightly higher security version (by like 3-4 months).
Any advise or approach to handling this?
|
||
Comment 3•5 years ago
|
||
Jan-Ivar, any thoughts on what might be going on here?
|
||
Comment 4•5 years ago
|
||
FYI the error message in question is from AbortError.
|
|
||
Comment 5•5 years ago
•
|
||
I'm not able to reproduce this (though I don't have a tablet, just an android phone). Does the problem happen for you if you run this fiddle?
Receives this error, DOMException: "The fetching process for the media resource was aborted by the user agent at the user's request."
I'm also wondering where exactly this error is being emitted. Is it preceded by playPromise error:?
The DOMException: part is curious, and I'm wondering if it's emitted even if you remove your console.error statement...
I've experienced some phantom AbortErrors in the past, but never been able to nail it down.
|
|
||
Updated•5 years ago
|
|
|
||
Comment 6•5 years ago
•
|
||
If that works, then it's possible it could have something to do with codecs selected during WebRTC negotiation vs. the hardware. Are able to complete calls successfully using other WebRTC apps like e.g. https://appear.in on this tablet?
|
|
||
Comment 7•5 years ago
|
||
Also, what about something simple like https://jsfiddle.net/yxbLvjm6/show/ —does that work on the problem tablet?
|
|
Reporter | |
Comment 8•5 years ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #7)
Also, what about something simple like https://jsfiddle.net/yxbLvjm6/show/ —does that work on the problem tablet?
I'll give that a shot today, sorry I didn't have access to the tablet till today.
As far as the other comments go, the error does popup in the console without my console.error statement. I just had that console.error statement to make filtering a little easier for me, sorry I should have mentioned that.
Also, i can't really test on Fiddle. The way this project works is I connect to a specific WiFi connection, projected from a Raspberry Pi, using a tablet (A or B). Then I pretty much have it running a program from the Raspberry Pi. The Pi connects to Motors, a camera, and more.
|
|
Reporter | |
Comment 9•5 years ago
|
||
(In reply to thatDevOpGuy from comment #8)
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #7)
Also, what about something simple like https://jsfiddle.net/yxbLvjm6/show/ —does that work on the problem tablet?
I'll give that a shot today, sorry I didn't have access to the tablet till today.
As far as the other comments go, the error does popup in the console without myconsole.errorstatement. I just had thatconsole.errorstatement to make filtering a little easier for me, sorry I should have mentioned that.Also, i can't really test on Fiddle. The way this project works is I connect to a specific WiFi connection, projected from a Raspberry Pi, using a tablet (A or B). Then I pretty much have it running a program from the Raspberry Pi. The Pi connects to Motors, a camera, and more.
- This connects through UV4L
|
|
Reporter | |
Comment 10•5 years ago
|
||
I ran one of the fiddles just to see if WebRtc is working fine on firefox, which it worked just fine. I don't have internet access with the tablets, so I just copied the fiddle code over as an HTML file and ran it. Worked just fine. So there's something with UV4L on tablet B
Any further thoughts given the above, :jib?
|
|
||
Comment 12•5 years ago
|
||
I don't know that there's much we can glean without being able to reproduce. We don't have access to a tablet running in this configuration with UV4L. Maybe we could get logs, but I dunno how to get MOZ_LOGs out of android.
Interestingly, these errors aren't being reported by content JS, making this distinct from e.g. bug 1568363.
Sounds instead like an "Unhandled rejection" escaping from our platform code somehow, like bug 1565795 or bug 1507193 (As I recall, we have some funky promise handling in our Seek code). There may be different causes for these errors, but the platform should not be leaking them into the web console like this.
Furthermore, the error message (see comment 4) points to NS_ERROR_DOM_MEDIA_ABORT_ERR which narrows things down a bit. There are only so many place we use that particular error. Bryce, do any of these stick out as probable fail sites?
|
|
Reporter | |
Comment 13•5 years ago
|
||
I checked the UV4L logs and there was nothing useful there.
I can show you both of the tablet's prefs.js file, but that being said i modified tablet B to look very similar to tablet A by using the prefs.js file.
If this is an error that you guys haven't seen before, did you want me to run my program on tablet B and screenshot the error? Not sure if you need that at all.
I may order a new tablet, not connect it to internet at all and give this a go again and see what i can do.
Any other advise?
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #12)
...
Furthermore, the error message (see comment 4) points to
NS_ERROR_DOM_MEDIA_ABORT_ERRwhich narrows things down a bit. There are only so many place we use that particular error. Bryce, do any of these stick out as probable fail sites?
None of those leap out at me. Based on the code in question, if I had to guess, I would guess it's coming from the HTMLMediaElement (many of the other paths I wouldn't expect to hit in this case such as media source or the Apple encoder).
thatDevOpGuy, would you be able to navigate to about:support on the tablets can copy that information (via the button to do so) onto this bug? Provided the error is just manifested as that text in the console, a screenshot isn't needed.
Aside from that, are the other programs involved at the same versions and configurations? Is UV4L the same on both tablets?
|
|
Reporter | |
Comment 15•5 years ago
|
||
(In reply to Bryce Seager van Dyk (:bryce) from comment #14)
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #12)
...
Furthermore, the error message (see comment 4) points to
NS_ERROR_DOM_MEDIA_ABORT_ERRwhich narrows things down a bit. There are only so many place we use that particular error. Bryce, do any of these stick out as probable fail sites?None of those leap out at me. Based on the code in question, if I had to guess, I would guess it's coming from the HTMLMediaElement (many of the other paths I wouldn't expect to hit in this case such as media source or the Apple encoder).
thatDevOpGuy, would you be able to navigate to
about:supporton the tablets can copy that information (via the button to do so) onto this bug? Provided the error is just manifested as that text in the console, a screenshot isn't needed.Aside from that, are the other programs involved at the same versions and configurations? Is UV4L the same on both tablets?
I believe it is from the HTMLMediaElement, but why it's showing up on one tablet on Firefox and not the other is where the confusion is occurring.
To the best of my knowledge, yes the tablets have the same versions (Firefox as well) and configurations (compared the prefs.js). I can take a look and send what I see in the about:support, though i don't think i can just copy everything over. I can try.
UV4L is running on the Raspberry Pi (only one raspberry pi we are using to test) and we're using Webrtc to get the live stream to our Android Tablet.
If you're able to get the about:support info from the tablets, that would be useful to help determine if there's any differences there on the Firefox side that could be impacting this.
|
|
Reporter | |
Comment 17•5 years ago
|
||
(In reply to Bryce Seager van Dyk (:bryce) from comment #16)
If you're able to get the
about:supportinfo from the tablets, that would be useful to help determine if there's any differences there on the Firefox side that could be impacting this.
I have both of the files but I'm not so sure how you would like to me to attach them ( i don't see the attachment button anywhere). They are both JSON files.
There should be an Attach File button at the bottom of the bug details on the top of this page. Failing that you can just dump them into a comment on the bug and surround them with ```s, this will make them look like this:
Code
Block
|
||
Comment 19•5 years ago
|
||
The priority flag is not set for this bug.
:jya, could you have a look please?
For more information, please visit auto_nag documentation.
|
|
Reporter | |
Comment 20•5 years ago
|
||
This is for Tablet A, the working tablet. about:support
|
|
Reporter | |
Comment 21•5 years ago
|
||
This is for Tablet B, the non-working tablet. about:support
|
|
Reporter | |
Comment 22•5 years ago
|
||
(In reply to Bryce Seager van Dyk (:bryce) from comment #18)
There should be an
Attach Filebutton at the bottom of the bug details on the top of this page. Failing that you can just dump them into a comment on the bug and surround them with ```s, this will make them look like this:Code Block
Thank you, I have just attached the JSON files for both tablets!
|
|
Reporter | |
Comment 23•5 years ago
|
||
(In reply to Bryce Seager van Dyk (:bryce) from comment #16)
If you're able to get the
about:supportinfo from the tablets, that would be useful to help determine if there's any differences there on the Firefox side that could be impacting this.
were you able to take a look at the attached files?
It looks like one of the tablets doesn't have the openh264 plugin available. In newer versions of Firefox no longer download the openh264 plugin due to bug 1548679. In older versions I'd still expect it to be downloaded, but if the tablets aren't connected to the internet then this will prevent Firefox downloading the plugin.
You could try mitigate this by streaming VP8 or VP9 instead of h264. You could also connect the tablet to the internet if possible to allow it to download the plugin, then disconnect it.
Let me know if the above works, and I'll resolve this accordingly.
(As a heads up, it's okay to upload attachments without the review flag, as it's use is for code review.)
Edit: see bug 1571126 for the work we have going to resolve this in new Android builds.
|
|
Reporter | |
Comment 25•5 years ago
|
||
(In reply to Bryce Seager van Dyk (:bryce) from comment #24)
It looks like one of the tablets doesn't have the openh264 plugin available. In newer versions of Firefox no longer download the openh264 plugin due to bug 1548679. In older versions I'd still expect it to be downloaded, but if the tablets aren't connected to the internet then this will prevent Firefox downloading the plugin.
You could try mitigate this by streaming VP8 or VP9 instead of h264. You could also connect the tablet to the internet if possible to allow it to download the plugin, then disconnect it.
Let me know if the above works, and I'll resolve this accordingly.
(As a heads up, it's okay to upload attachments without the review flag, as it's use is for code review.)
Edit: see bug 1571126 for the work we have going to resolve this in new Android builds.
Hey Bryce,
that was it! the second i connected it to internet and let the plugin install, then the video stream began to work.
It works consistently, just like Tablet A.
I really appreciate the help!
Thank you,
Neal
Glad to hear it's working now. I'll mark this as resolved.
|
||
Updated•3 years ago
|
Description
•