Open pallaswept opened 1 year ago
IceDBorn
commented
1 year ago I'm pretty sure that this is caused by the workaround we include for Discord on Wayland. If you're familiar with JavaScript, you can alter these lines and see if there's a fix for this. I would love to test this, but I don't have much free time at the moment, I'm not a user of Discord and I can't trigger the bug. @alansartorio is the one who implemented the workaround, maybe he can be of more help than I will.
pallaswept
commented
12 months ago I do know a little js (I'm rusty as heck and don't know squat about ff addons, but hey it's all js, right.....right? :rofl: NO. No, it wasn't.... ) so I took at look at this tonight.
Sure enough, it worked fine without that workaround in place, and even better without that timer (the one on line 12.... what's that for anyway?)
It still required two clicks to make it work though - one to allow permission for the "microphone" (the virtmic device), but then after that, minus those two pieces of code, a single click any time afterwards, would start the screen share. If I had saved the permission to use the mic, it worked on the first click of the button.
I do now know exactly why it's requiring two clicks, or in the case of the release version, spam-clicking - it's because it calls navigator.mediaDevices.getUserMedia() twice, from the single interaction (click of the button). The first click is allowed, but the second one is blocked, because there's no user interaction triggering it because that call to getUserMedia() is made from outside of the addon's getDisplayMedia() function.
The addon was pretty touchy about the few attempts I made, to get it to do its work with only one call to getUserMedia(), or to get it to call it twice but at least do so from within the function triggered by the button press. That might take someone with a bit better knowledge of how it works.... Or maybe I should stop being lazy and RTFM the specs of the API :laughing: But if you can think of a quick and easy way to get it to do one or preferably both of those things (as in, make it only call navigator.mediaDevices.getUserMedia() one time, not two, and get it to do so from within the addon's getDisplayMedia() function, not outside of.before it) , that would be great.
It's working when I spamclick it because I'm essentially exploiting a security flaw in the browser (I probably should report this when we're done) where if the first call is still in the process of failing, then it sees the still-active allowance to use the device, and allows us to pass.
I did have some trouble making sure it was working properly, because I was getting the same issue as #79, but I ALWAYS got it, even with the release version of the addon which I have no problems with in FF 120 and I'm certain it's a bug in nightly, it doesn't happen in 120 release.... but it made it impossible to confirm that what I was doing was really working properly.
If I'm not mistaken, there's an 'unbranded' release version that will allow me to run the unsigned addon, but is the same code as the 120 release I'm typing on right now, but I could only find nightly artefacts. Can you school me on where to get that 'unbranded' release version so I can finish testing it out properly and give you a straight answer or maybe even a PR with a fix?
Edit: just typos, I'm kinda sick, having trouble using my hands and seeing, hence the half-assed effort at fixing this. Sorry about that but I'm giving it a shot and I'll be better soon and more useful
IceDBorn
commented
3 months ago @pallaswept Is this resolved?
pallaswept
commented
3 months ago I still get this. I notice it won't do it now in an empty room, but it definitely did it a few days ago, so I guess it's one of those things that only happens when you connect to another user.
Looking back at this, I have a feeling that, by removing that workaround for Wayland video and timer to delay the audio grab, it just made everything fast enough that it's still considered part of the same user interaction, so the browser lets it all by.
When I try to start a screen share on discord, I am immediately prompted for permission to use to virtmic source (as a 'microphone') but I am not prompted for permission to allow screen sharing and then select a screen to share, as normal. If I then click the screen share button quickly four times (a 'double-double-click') it will prompt me for permission and to select a screen as normal. If I saved the permission to use my voice microphone, I will not be prompted for permission to use the virtmic input, but I still need to do the rapid clicking to trigger the screen share, so I do not believe that the first permission prompt is blocking the second. This does not occur without the addon enabled. When I use the multiprocess console, I catch this error, which does suggest that something about the addon is preventing the user interaction from being 'seen' by the browser. (Edit: since it's in a relevant section of the code, yes this is a wayland session, although the same happens in an xwayland browser session (disabling wayland at the environment variables))
I hope this helps!
I also just noticed, that when I click the screen share button, my microphone icon changes to red briefly (for about 2 seconds) before turning white again. It starts like so:
and changes to this for ~2 seconds:
