[BUG] Scripts with type="module" are ignored #226
Labels
No labels
area/accessibility
area/dependency
Confirmed
Crash Report
Delayed
Design Issue
Duplicate
Feedback required
Good first issue
kind/bug
kind/cleanup
kind/enhancement
platform/linux
platform/macos
platform/windows
priority/high
Question
Request for Comments
Seeking Other Contributors
Seeking Testers
Won't Fix / By Design
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-obsproject/obs-browser#226
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Platform
Operating system and version:
OBS Studio version: 25.0.2+ (built from git) on Debian Linux
Expected Behavior
JavaScript in
<script type=module>blocks should be executed.Current Behavior
JavaScript in such blocks is ignored.
Steps to Reproduce
Additional information
This script file is not using any module-specific features (eg imports), and should be executed just the same as if the type were omitted.
The issue does not seem to occur on Windows, but I have not confirmed this.
Can confirm it works fine on Windows 10.
Not sure if it helps anything, but on windows the event is triggered twice when showing/hiding the source for some reason:
That's very curious. I've seen some other situations where the event double-fires, though (even in browsers), so I've no idea what the cause is. (If you want more info about the events themselves, try https://rosuav.github.io/Ratigan/comfy which establishes a socket connection to Twitch as well, allowing a bit of external interaction; it also gives more detailed info about the event timings and such.) That's tangential to this issue, which is that the script isn't even being run at all, if the type is module.
The double-fire definitely isn't expected behaviour, but it's largely because we have to fake the event due to our current CEF build (and a few around it) having a broken visibility API. As long as it's reporting accurately, that should be fine.
If you're not seeing it fire, it's likely because you have Projector, Properties, Interact or Filters opened for the source. Due to the way OBS treats visibility, they are technically "always visible". Ideally you instead want to hook into the
obsSourceActiveChangedevent on the window/document instead. This will always give you a real status on whether the browser is visible in the stream/recording, regardless of previews visible. More info on the available JS bindings here.Curious. Why is it different on Linux and Windows?
In a local build on Ubuntu with CEF 3809, the visibility API behaves identical to Windows, with the side effects mentioned in my earlier post. Which version of CEF are you building with?
Ah! Even more interesting. And I'm not sure, how would I check?
Navigate to
chrome://versionand it'll be listed along the top.Gotcha. It's CEF 3.3029.1613.g22354a9 but I've no idea where I got that from. I think it was brought in automatically as part of the OBS build.
Then that's likely why. We only support 3770 and 3809 officially, 3029 is way too old. Please verify with a 3809 build from Spotify.
Hmm. I don't know what's going on, but everything I try to do to update CEF results in the browser being badly broken - either not rendering at all, or rendering in some way that is completely unreadable. But I'm going to close this issue, because the actual reported bug appears to simply be "CEF is too old". And quite frankly, the issues with updating it are not worth my effort at the moment. I'm reverting to the working one.