HTML <select> and <datalist> in browser source (not docks)
techiServices opened this issue · 22 comments
The HTML elements <select> and <datalist> do not work as expected in the Interaction Mode.
The <select> dropdown was fixed previously but now appears to briefly show in the top left corner before disappearing as can be seen here https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select.
The <datalist> dropdown does not appear at all as can be seen here https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist.
In the title you wrote <source> but I guess you meant <select>?
I reported the dropdown menu bug here:
https://obsproject.com/mantis/view.php?id=1271
Was it really fixed? I can't test it at the moment (on my laptop with Intel iGPU), but there also seem to be issues with dropdowns with shared texture support disabled.
It was fixed quite some time before the refactor, but it wasn't put back in after the refactor and the CEF performance improvements. So currently it just doesn't work.
Yes <select> sorry. Would <datalist> as part of an <input> be a similar issue?
If I understand correctly, OBS is currently using CEF 3.3440.1805.gbe070f9 plus a patch for CEF PR 158. There was an issue during the development of that PR where select elements and other dropdowns failed to render, though that was fixed before the PR was merged into CEF. I don't recall if the CEF build used by OBS has that fix or not.
This sounds like it could otherwise be CEF Issue 1468, which is fixed in CEF 3538 and later.
For now, if you click on the select element, and then mouseover the area it would normally be displayed, you might be able to interact with it. It will look a bit bizarre, but at least it might work if you need it.
The problem is not any kind of bug in CEF, dropdowns are rendered as a seperate texture and needs to be copied over the browser texture, refactored versions of OnPaint and OnAcceleratedPaint do not account for that.
For reference, as this particular issue was brought up again on Discord, the original commit that added support for this can be found here: 3b30ecc
Unfortunately it can't just be copy-pasted as is, but should serve as a useful reference to whoever has the time and the skill to re implement it.
Is there any sort of progress being made on this issue? I'm trying to create some simple stream overlay interfaces for myself and friends, and this bug is making it quite difficult to progress. It seems odd to me that a bug like this would just go totally silent for over a year and a half.
Nobody has publicly said they're looking into it, no. The Interact capability in OBS is supposed to be a "it's there in the rare off-chance you need it, but there are better ways to do overlays and it shouldn't be a core part of your usage" sort of feature, so it's not high on the internal priority list.
The only workaround I could suggest for now (if you're making your own interface to be used with Interact) is using a javascript library like bootstrap-select which generates the dropdown in HTML.
Generally, if you want users to be able to control their overlays, the more "recommended" method is a second page that can be inserted as a dock or loaded in a standard web browser which then communicates with the source in OBS.
The Interact capability in OBS is supposed to be a "it's there in the rare off-chance you need it, but there are better ways to do overlays and it shouldn't be a core part of your usage" sort of feature, so it's not high on the internal priority list.
While that's understandable, when the "better way" is...
a second page that can be inserted as a dock or loaded in a standard web browser which then communicates with the source in OBS
... I think you can probably understand my frustration when trying to develop what should be a simple, no-nonsense, barebones local tool for my own personal usage, and I'm suddenly forced to either 1) pull in jQuery and several plugins just to work around what should be basic browser functionality, or 2) try to break this down into a server/client connection, which would be both out of my technical wheelhouse and massive overkill for this project.
I'll try to find a more elegant way to work around this, but I think you can probably understand why I'm a little annoyed at this of all bugs.
I completely understand wanting to keep a site simple and not wanting to implement either of the suggestions I mentioned.
To be honest: if I had the skill, this is something I would have already fixed. I did try a year ago, and got stuck pretty early in. As a full time web developer myself, I completely get why this bug is incredibly problematic and why it's worth fixing.
I managed to work out a solution using window.onstorage, since luckily browser docks don't have the same bug as browser sources in this case, but I would still very much like to see this fixed moving forward =)
is a browser dock a fully functional browser? i just tried my js and window.localstorage doesnt appear to work. do they work with window.obsstudio?
Is there an update to resolve these issues?
Thanks...
See obsproject/obs-studio#3853 for progress on upgrading CEF.
The CEF update landed and I just tried OBS Studio 27.2 Beta 3. Unfortunately, dropdown menus are still broken but differently than before. The part that should drop down is not rendered at all. It is possible to focus the widget and select a different entry via arrow keys but any interaction seems to freeze up OBS shortly after.
FWIW, dropdown menus in docks work fine as before.
To be clear, this issue won't be fixed with a CEF update - it requires implementing proper handling of layered textures on the OBS side, as Chromium basically creates a second texture for the menu itself.
Any update on this? Really need dropdown menu's.
Hello. Any update on this? I Really need too dropdown menu's.
I don't understand the last answer of WizardCM ?
Thanks
As @WizardCM mentioned earlier in the comments, the Interact feature of browser sources is not a 'fully supported feature'. If there are problems related specifically to interact, they're not a top priority for us to fix due to the complexity. In cases where it is an issue for your workflow, we suggest using an actual browser and doing a window capture of it instead. This is the same approach you would have to take if the Interact feature didn't exist after all.
While I know that may be frustrating for some things with Interact to not work quite right, we ultimately think it's better to include it for the cases where it does work over not having it at all.
I'm also not saying we outright won't fix this. Someone is still welcome to work on it. It is simply not at the top of anyone's list currently.
Thank you very much @Warchamp7 for your detailed response. I understand ...