[WIP] Fix select change handler#521
Conversation
|
This looks like a good fix to me — fairly sure it's just the same JSDOM quirks as before causing the test to fail, so we can probably just skip it. Maybe we should use a proper headless browser instead. Would probably make the tests run a lot slower though, especially in a CI context where you have to install a lot more. I know @PaulBGD has been getting his hands dirty with this stuff recently for svelte-bench. |
|
@Rich-Harris I've recently taken an interest in jsdom and have submitted a few PRs. Since you've extracted several neat testcases in this repo and specifically marked them as failing in jsdom, I'd like to see if I can resolve some of these issues when I have time over the coming weeks. |
|
@Zirro that'd be awesome, thanks — have been meaning to get round to it myself but there aren't enough hours in the day! |
I'm marking this [WIP] because I'm a little unsure of my change here still, but also because the unit test is still failing for some reason. I see some other unit tests involving
<select>have been disabled, apparently because of limitations or bugs in jsdom.The specific test cases (REPL, REPL) seem to work with this change when they're compiled and manipulated manually - and no other unit tests break.
The idea in the PR is to move all of the attribute handling of
<select>elements (attaching event handlers, etc) after the code for handling its children - but within that code generated by visiting the attributes to keep everything in the same relative order as it is for other types of elements. I can't see what any unpleasant side-effects of this might be, but there could still be some. As a bonus, the generation code inElement.jsis slightly tidier.cc @saibotsivad @TehShrike