"Waiting for selector 'video.vjs-tech' failed" error after successful login
muzso opened this issue · comments
Hi!
I've tried both the latest release (5.1.0, https://github.com/kylon/Sharedown/releases/download/5.1.0/sharedown-5.1.0.AppImage) and the latest commit on the main branch (7b9eaa4), but both result in the same error.
I'm trying to download a Teams meeting recording with an URL pattern like this:
https://examplecloud-my.sharepoint.com/:v:/r/personal/bob_test_example_com/Documents/Recordings/Some%20Meeting-20221104_125428-Meeting%20Recording.mp4?csf=1&web=1&e=aD21Ge
After a successful authentication (to AzureAD/O365) the Chromium window is closed and a popup is produced with the following error message:
Waiting for selector 'video.vjs-tech' failed: Protocol error
(Runtime.callFunctionOn): Argument should belong to the
same JavaScript world as target object
After I close this by clicking the OK button, a new popup comes up with this:
Cannot read properties of null (reading 'kill')
The latter happens only with v5.1.0, but not with the main branch.
Interestingly no sharedownLog.log is created in $HOME/.config/Sharedown/logs despite having enabled "Sharedown Logs" in Settings. :(
How can I drill down into the cause of this problem?
One more hint: regardless of how I start Sharedown, it prints the following line on the terminal:
[27704:1105/020303.664750:ERROR:nss_util.cc(349)] After loading Root Certs, loaded==false: NSS error code: -8018
My guess is that the latter has nothing to do with the symptoms.
known issue with puppeteer, i cannot reproduce so it is a bit hard to find a workaround, but you should be able to use a custom chrome executable in this case (see settings)
The same happened, when I tried it with the latest official Google Chrome (stable) release.
https://github.com/kylon/Sharedown/files/9954005/Sharedownt2.zip
can you try with this? use manual login
Thanks for your help in trying to debug the issue! :-)
Still the same error. But the refactored logging was worth it, because now I got a sharedownLog.log to share. :-)
Not too much additional info though.
startDownload: enter
start download: data true
runPuppeteer: goto https://examplecloud-my.sharepoint.com/:v:/r/personal/bob_test_example_com/Documents/Recordings/Some%20Meeting-20221104_125428-Meeting%20Recording.mp4?csf=1&web=1&e=aD21Ge
runPuppeteer ex: Waiting for selector `video.vjs-tech` failed: Protocol error (Runtime.callFunctionOn): Argument should belong to the same JavaScript world as target object
ProtocolError: Waiting for selector `video.vjs-tech` failed: Protocol error (Runtime.callFunctionOn): Argument should belong to the same JavaScript world as target object
at /home/myuser/temp/Sharedown_t2/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Connection.js:329:24
at new Promise (<anonymous>)
at CDPSessionImpl.send (/home/myuser/temp/Sharedown_t2/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Connection.js:325:16)
at ExecutionContext._ExecutionContext_evaluate (/home/myuser/temp/Sharedown_t2/node_modules/puppeteer-core/lib/cjs/puppeteer/common/ExecutionContext.js:211:46)
at process.processTicksAndRejections (node:internal/process/task_queues:96:5)
at async WaitTask.rerun (/home/myuser/temp/Sharedown_t2/node_modules/puppeteer-core/lib/cjs/puppeteer/common/WaitTask.js:95:68)
at async Promise.all (index 0)
at async TaskManager.rerunAll (/home/myuser/temp/Sharedown_t2/node_modules/puppeteer-core/lib/cjs/puppeteer/common/WaitTask.js:197:9)
I've replaced the actual URL and the path to the HOME directory (for privacy reasons).
P.S.: there's a typo in the preload.js (from your ZIP): in api.runPuppeteerGetVideoData the "keepBrowerOpen" should be "keepBrowserOpen"
I tried this new build with Google Chrome as well (just to make sure it's not the built-in Chromium) and the same result.
For full disclosure: the tenant I'm testing with has Microsoft Defender for Cloud Apps (see: https://www.microsoft.com/en-us/security/business/siem-and-xdr/microsoft-defender-cloud-apps) enabled.
This means that if I use the video URL (https://examplecloud-my.sharepoint.com/:v:/r/personal/bob_test_example_com/Documents/Recordings/Some%20Meeting-20221104_125428-Meeting%20Recording.mp4?csf=1&web=1&e=aD21Ge) in a regular browser, I'm redirected to the AzureAD login page, enter the credentials, confirm the 2FA prompt, and after the successful authentication is completed, the browser is redirected to the https://example-com.access.mcas.ms/aad_login URL where the following text is displayed:
Access to Microsoft OneDrive for Business is monitored
For improved security, your organization allows access to Microsoft OneDrive for Business in monitor mode.
Access is only available from a web browser.
[checkbox] Hide this notification for all apps for one week
And then I'm redirected to this URL:
https://examplecloud-my.sharepoint.com.mcas.ms/personal/bob_test_example_com/_layouts/15/stream.aspx?id=%2Fpersonal%2Fbob%5Ftest%5Fexample%5Fcom%2FDocuments%2FRecordings%2FSome%20Meeting%2D20221104%5F125428%2DMeeting%20Recording%2Emp4
Notice the .mcas.ms at the end of the hostname.
MCAS stands for Microsoft Cloud App Security.
So this is not a "standard" (aka. basic) O365 setup.
Previously (before enabling Microsoft Defender for Cloud Apps) I could download Teams recordings even with https://github.com/snobu/destreamer.git (using the sharepoint branch).
With Microsoft Defender for Cloud Apps enabled, both destreamer and Sharedown have problems.
However playback of the Teams recording is possible in all sorts of browsers (the choice of browsers is not limited).
Thus it should be possible to make this work with an Electron based app as well.
My guess is that both destreamer and Sharedown simply get the authentication tokens from the browser's cookie store and call the video downloader (yt-dlp or ffmpeg) with the original URL that was supplied initially. And this doesn't work, because of the .mcas.ms thing. I'll try to feed this modified URL to the app and see what's happening.
I've tried the following two URLs, but without any success:
https://examplecloud-my.sharepoint.com.mcas.ms/:v:/r/personal/bob_test_example_com/Documents/Recordings/Some%20Meeting-20221104_125428-Meeting%20Recording.mp4?csf=1&web=1&e=aD21Ge
https://examplecloud-my.sharepoint.com.mcas.ms/personal/bob_test_example_com/_layouts/15/stream.aspx?id=%2Fpersonal%2Fbob%5Ftest%5Fexample%5Fcom%2FDocuments%2FRecordings%2FSome%20Meeting%2D20221104%5F125428%2DMeeting%20Recording%2Emp4
P.S.: still ... for privacy reasons these are not the actual URLs I tested with, but they bear the same characteristics as the actual URLs I used.
ok, lot of things happening, puppeteer may have issues with this
this is waiting for ~4 minutes when login process starts before trying to catch video data, just testing if puppeteer function i'm calling is not working in this case
app.js is missing from Sharedownt3.zip.
This actually worked! :-)
It seems that (previously) the multiple HTTP redirects of this MCAS feature took longer than what Sharedown waited for.
good, i don't know who can replace that function rn :P
i ll came back to this in a few days
is this the final url? the video player page
https://examplecloud-my.sharepoint.com.mcas.ms/personal/bob_test_example_com/_layouts/15/stream.aspx?id=%2Fpersonal%2Fbob%5Ftest%5Fexample%5Fcom%2FDocuments%2FRecordings%2FSome%20Meeting%2D20221104%5F125428%2DMeeting%20Recording%2Emp4
Yes, it is.
However I don't find any trace of this URL in sharedownLog.log (of the successful download with Sharedownt3.zip).
@brianchen0 for you too
Sharedownt61.zip still works (video download is successful) and doesn't wait 230 seconds for the video page to load.
The new _waitForVideoPlayer() function seems to do the trick well.
Thanks @kylon for the quick responses and the fix!
@brianchen0 for you too
@kylon thanks for the quick response! May I know how to integrate the sharedown61.zip to the current program? Would you please share the instructions?
this is now fixed in main, i ll post a new release soon
Great! Thanks again for the quick update!!