-
Notifications
You must be signed in to change notification settings - Fork 146
Please create an example of how to attach event handlers on to inputs #366
Comments
Hey @sketchbuch! Meant to respond to this earlier week, but got pulled into some other pressing work the last few days. I'm happy you were able to find a solution, however, it's not recommended that you target elements inside the shadow DOM to do event listening. I'm assuming you were trying to listen to events on I was able to do a quick test with both components and confirm that everything seems to be working as expected. Here's a relevant snippet of the code I used to test things: <vscode-text-field id="text-field" placeholder="Type something"></vscode-text-field>
<vscode-text-area id="text-area" placeholder="Type something"></vscode-text-area> window.addEventListener("load", main);
function main() {
const textField = document.getElementById("text-field");
textField.addEventListener("keyup", (event) => {
console.log(event.target.value);
});
textField.addEventListener("change", (event) => {
console.log(event.target.value);
});
textField.addEventListener("input", (event) => {
console.log(event.target.value);
});
const textArea = document.getElementById("text-area");
textArea.addEventListener("keyup", (event) => {
console.log(event.target.value);
});
textArea.addEventListener("change", (event) => {
console.log(event.target.value);
});
textArea.addEventListener("input", (event) => {
console.log(event.target.value);
});
} Regardless, I'd love to hear more about what you were trying to achieve and see if we can find a way to do that without needing to dive into shadow DOM internals. |
Hello @hawkticehurst, Yes, it does work. My problem was caused by having the input surrounded by a form. It wasn't triggering the submit and I thought none of the events were working. Apparently inputs in shadow dom can't trigger a wrapping form's submission by implicit submisssion (pressing enter) This seems to have been what caused my issue. I previously had issues due to the form as web views do not allow navigation: microsoft/vscode#125485 which I did not know was unsupported in webviews. I managed to find a fix to keep the form (which I thought was better for accessibility reasons) but as it is not possible to do the submission via enter with the ui toolkit which was what I was doing, I removed the form completely now. I also noticed that the search field on the extensions panel has no form so maybe it isn't as necessary as I thought for accessibility. I recently saw Microsoft's Head of Accessibility talk about accessibility at MS (axe-con-2022), and know that it is important for you as a company, but I guess if you don't put a form around the search field it is ok for extension devs to also not add one! I'm using the toolkit here. https://github.com/sketchbuch/vsc-workspace-sidebar (currently I just use the buttons and the text field). Thanks for you help. Maybe you can mention in the docs for the ui toolkit not to use forms (or anything else that naviagtes the webview), and that implicit form submission will not be possible due to the inputs being in shadow dom. |
I will re-open this as I'm not sure you will get my reply if it is closed. Feel free to re-close as my issue is solved. Thanks, for the examples! PS I had to build a tree view for my extension (similar to file explorer). Is there any chance you will add a tree view to the toolkit? There is already an issue about it: |
@sketchbuch thank you for the detailed summary! That's actually super helpful/enlighting for me (I hadn't realized there are potential issues with form usage in both webview and shadow dom contexts). I'll go ahead and close this issue now, but think I'll add a new one that ensures I'll do a deeper exploration of forms/inputs/accessibility in the toolkit/webviews. And yes, at the very minimum I'll make sure to update the docs as part of that work. |
Also, we're still thinking about and collecting data/stories on tree view usage within webviews. We're still hesitant to duplicate this effort since the TreeView API already exists and we've demonstrated how the TreeView API and webviews can be used together in an extension. With that said, if this demonstration doesn't fit the needs of your extension for whatever reason I would love to know why! If you could add a comment to the above issue thread that you linked to, that details what you need a tree view for, how you would use it, and how the current TreeView API doesn't meet your needs that would be greatly appreciated! Now that toolkit 1.0 has been released, we'll be taking a closer look at the component requests we've received to determine what we should tackle next. So any more developer anecdotes we can get will help in that process :) |
I tried using the text input in my webview but need to listen to events like keyup, change, etc. but could not find out how to do this as the actual input is in the shadow dom.
The text was updated successfully, but these errors were encountered: