Closed chefexperte closed 1 year ago
Thank you for the report. Basically it should be a Firefox bug but first lets try to get more details why this is happening before filing one.
As you said the profile as created manually doesn't show the problem. Would you mind running a test with geckodriver by explicitly using this same profile? Does the crash happen as well? Do you have a more detailed stack trace that you could share with us? Thanks.
I have tried out some more things. One thing that I have gotten working is Firefox with Geckodriver without a profile. For some reason it finally decided to install Widevine and DRM content did work.
However when I use Firefox with a saved profile, Widevine crashes when trying to load DRM content. I have tried creating a profile and installing Widevine using Geckodriver, and creating a profile using "normal" Firefox and then loading it with Geckodriver. Both led to Widevine crashing when loading DRM content. I haven't debugged(?) a browser before, so I am not sure where I can get a more detailed stack-trace for the plugin crash, since it's not a full browser crash
Actually it should be easy to get the crash details when you use a custom profile. Please check if there is a minidump
sub-folder contained in the profile directory after it was in use by geckodriver and you passed it as --profile
within moz:firefoxOptions[args]
. If there are files contained please attach both the minidump and extra file to this issue. I can then have a look.
Otherwise please also check if setting the preference remote.prefs.recommended
to false
within the moz:firefoxOptions[prefs]
capability makes a difference or not.
Thanks.
Okay so here are the .dmp and the .extra files. This is without the remote.prefs.recommended
enabled.
566c8d52-1cb9-0cfc-60f8-e833be07824a.zip
And after enabling the option Widevine still crashed sadly, the dmp files varied in size so here are the minidump and extra file that were created with remote.prefs.recommended
set to false
5da4daf1-5f96-0b8c-3046-b727fb8c6a64.zip
I thought I'd also give you how I execute the code if that makes a difference: (it's a shortened version)
from selenium import webdriver
from selenium.webdriver.firefox.options import Options
if __name__ == "__main__":
options = Options()
options.set_preference("media.eme.enabled", True)
options.set_preference("media.gmp-manager.updateEnabled", True)
options.set_preference("remote.prefs.recommended", False)
options.add_argument('--profile')
options.add_argument(path + '/firefox-profile')
options.log.level = "trace"
driver = webdriver.Firefox(options=options)
driver.get("https://accounts.spotify.com/en/login/")
# login logic
if login_success:
driver.get("https://open.spotify.com")
Thanks! I've uploaded the crash report and it can be seen here: https://crash-stats.mozilla.org/report/index/0354140d-a22f-4ee1-93ad-7f8f10220419
As it looks like you are hitting https://bugzilla.mozilla.org/show_bug.cgi?id=1444334 which already open for quite some time. Some indication shows that this might be an issue with loading the plugin and that the module is blocked by the sandbox. Maybe you could check with different sandbox levels if there is a difference in behavior? The related preference is security.sandbox.content.level
. It starts with 0
which means off, while higher numbers activate more restrictions.
Your help would be appreciated given that we haven't found a case that is reproducible yet. Once it's clear what's causing it we should get a bug on Bugzilla filed.
@sstraightea have you had the time to check the suggestions from my last comment yet? I'm curious about the results. Thanks!
I sadly did not have time yet, but I will try it out, it's on my todo list. Sorry.
@sstraightea wanted to check back if you may have the time to check these mentioned steps. We would appreciate. Thanks!
Oh I thought I had responded, I am sorry.
I tried out security.sandbox.content.level
but it didn't make any difference, the exact same things happen just like without the setting enabled.
Hm ok so it doesn't seem to be sandbox related if even 0
as value doesn't prevent the crash from happening.
Would you mind giving more details about your system installation? Is there any kind of software running which might prevent loading of the Widevine module? Does the system log maybe show something which might indicate that? Maybe you could also list in detail the different scenarios when it works and when it fails? Maybe that gives some details around possible patterns.
Thanks.
In my system logs I did find this:
Process 28763 (MainThread) of user 1000 dumped core.
Module /home/[removed path]/firefox-profile/gmp-widevinecdm/4.10.2449.0/libwidevinecdm.so with build-id e8b384278b62d82722bb2599c02fca53af063083 Module linux-vdso.so.1 with build-id 1b29ff114d30e41b5ec9d9cdf4fd690d9ad61f7f Module librt.so.1 with build-id 55b6834a0f40c38da6ba638d9c5e6d6ff5fae1df Module libpthread.so.0 with build-id 06234572a6c94739e06bd8521d45ec00c45246df Module libdl.so.2 with build-id d3755f8aa82728259712ad67538901bc30552ca9 Module libgpg-error.so.0 with build-id a53c231739d55cc39b97e28c36cd8b3e58a8f8f8 Metadata for module libgpg-error.so.0 owned by FDO found: { "type" : "rpm", "name" : "libgpg-error", "version" : "1.45-1.fc36", "architecture" : "x86_64", "osCpe" : "cpe:/o:fedoraproject:fedora:36" }
Module libicudata.so.69 with build-id 4d19cd548e77f2f9778d81cf9c27831200804bc4 Stack trace of thread 28763:
0 0x00007f46e4230e4d _ZN7mozilla3gmp8GMPChild15ProcessingErrorENS_3ipc14HasResultCodes6ResultEPKc (libxul.so + 0x19a0e4d)
1 0x00007f46e35d6541 _ZN7mozilla3ipc9IPCResult4FailENS_7NotNullIPNS09IProtocolEEEPKcS7 (libxul.so + 0xd46541)
2 0x00007f46e423a0be _ZN7mozilla3gmp8GMPChild15RecvStartPluginERK9nsTStringIDsE (libxul.so + 0x19aa0be)
3 0x00007f46e425171a ZN7mozilla3gmp9PGMPChild17OnMessageReceivedERKN3IPC7MessageERPS3 (libxul.so + 0x19c171a)
4 0x00007f46e591fe6f _ZN7mozilla3ipc14MessageChannel19DispatchSyncMessageEPNS019ActorLifecycleProxyERKN3IPC7MessageERPS5 (libxul.so + 0x308fe6f)
5 0x00007f46e554ee63 _ZN7mozilla3ipc14MessageChannel15DispatchMessageEPNS0_19ActorLifecycleProxyEON3IPC7MessageE (libxul.so + 0x2cbee63)
6 0x00007f46e554ea84 _ZN7mozilla3ipc14MessageChannel11MessageTask3RunEv (libxul.so + 0x2cbea84)
7 0x00007f46e5544b58 _ZN11MessageLoop6DoWorkEv (libxul.so + 0x2cb4b58)
8 0x00007f46e58fc87f _ZN4base18MessagePumpDefault3RunEPNS_11MessagePump8DelegateE (libxul.so + 0x306c87f)
9 0x00007f46e58fa8ab _ZN11MessageLoop3RunEv (libxul.so + 0x306a8ab)
10 0x00007f46e6552343 _Z20XRE_InitChildProcessiPPcPK12XREChildData (libxul.so + 0x3cc2343)
11 0x0000561c9fa822fa _Z20content_process_mainPN7mozilla9BootstrapEiPPc (plugin-container + 0x532fa)
12 0x0000561c9fa75276 main (plugin-container + 0x46276)
13 0x00007f46e2318590 __libc_start_call_main (libc.so.6 + 0x29590)
14 0x00007f46e2318649 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x29649)
15 0x0000561c9fa821e5 _start (plugin-container + 0x531e5)
Stack trace of thread 28770:
0 0x00007f46e23fa63d syscall (libc.so.6 + 0x10b63d)
1 0x00007f46e554bafe epoll_wait (libxul.so + 0x2cbbafe)
2 0x00007f46e554b399 event_base_loop (libxul.so + 0x2cbb399)
3 0x00007f46e554480f _ZN4base19MessagePumpLibevent3RunEPNS_11MessagePump8DelegateE (libxul.so + 0x2cb480f)
4 0x00007f46e58fa8ab _ZN11MessageLoop3RunEv (libxul.so + 0x306a8ab)
5 0x00007f46e58ff4e5 _ZN4base6Thread10ThreadMainEv (libxul.so + 0x306f4e5)
6 0x00007f46e58fa0bb _ZL10ThreadFuncPv (libxul.so + 0x306a0bb)
7 0x0000561c9fa9fbf6 _Z30set_alt_signal_stack_and_startP19PthreadCreateParams (plugin-container + 0x70bf6)
8 0x00007f46e237be5d start_thread (libc.so.6 + 0x8ce5d)
9 0x00007f46e24018f0 __clone3 (libc.so.6 + 0x1128f0)
ELF object binary architecture: AMD x86-64
I can't tell if this log is useful though.
The cases where Widewine crashes are basically only when I start geckodriver using an existing firefox profile. I have tried creating a firefox profile in a geckodriver/marionette instance as well, leading to the same crash of widewine though.
When I do not use Geckodriver, and start Firefox normally, the crash does not happen. If I start geckodriver without a profile, widewine is installed and does not crash. However it has to install everytime when the browser starts (because nothing is saved)
I don't think I have any software that could cause Widewine to crash. I am running Fedora 36 (Fedora 35 before), and Firefox version 100.0 (older ones before that also had the same problem for me) The crash happens on my Desktop with an Intel CPU and NVidia GPU, and also on my Laptop with an AMD iGPU.
If you need any specific information on my system, I can provide that as well
Thanks for all the details. I had a look at the log output but not sure if these stack entries there are from a crash or not. If they are then its related to the plugin-container
as used by Firefox for content processes.
Could you check once more manually by starting Firefox with the --marionette
argument. Does that crash as well?
Okay I tried it, and I have made a discovery.
Currently Widevine only seems to be working with firefox profiles saved in the default profile location (~/.mozilla/firefox/profile-name
), and --marionette
does not change anything. So I might have been wrong and the problem I am facing is not a geckodriver one, but something about where the Firefox profile is saved at.
Not necessarily. geckodriver sets some other preferences that may not be set when just specifying --marionette
. As such it would be good to check again the following scenarios with a webdriver test by using geckodriver:
--profile
argument in moz:firefoxOptions[args]
.Note that for step 3 and 4 you should pre-create the profile and make a backup before using it the very first time with geckodriver.
I'm curious to hear which of these above scenarios work and which don't. Thanks in advance!
Okay so the results are:
When copying an existing profile to a place outside the default profile location and opening it with geckodriver, it also re-downloaded Widevine, even though it was already installed in the profile, so that is weird
Interesting. Does the re-download of Widevine also happen when you manually start Firefox after moving the profile out of the default location?
When I manually start Firefox with a profile moved to a different location the re-download does not happen.
@sstraightea I actually missed one case. Could you please also check what happens when you make use of the profile
capability?
@chefexperte is this actually still a problem?
Closing given that this crash is an issue with Firefox and as mentioned early should be tracked by https://bugzilla.mozilla.org/show_bug.cgi?id=1444334.
System
Testcase
Playing DRM protected content works fine when normally running Firefox, but every time Firefox is started using Geckodriver, the Widevine plugin crashes and I can't play the content. I have tried this without selecting a Firefox profile, but then Widevine just would not install. Using a profile that has Widevine installed, this is what happens. This happens for me on every website that uses Widevine. To test it out I recommend https://bitmovin.com/demos/drm
Stacktrace
Trace-level log
geckodriver-trace-log.txt