WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
199568
Radio button groups are not scoped by shadow boundaries
https://bugs.webkit.org/show_bug.cgi?id=199568
Summary
Radio button groups are not scoped by shadow boundaries
Jonathan Lin
Reported
2019-07-08 01:00:33 PDT
I have a web component, <kr-radios></kr-radios> that encapsulates a <fieldset></fieldset> with multiple <input type="radio">. In this bug <fieldset> can be replaced with pretty much anything, e.g. <div> and bug will still hold true. Say I have a form like the following: <kr-radios></kr-radios> #1 <kr-radios></kr-radios> #2 Click a radio in #1 and subsequently in #2 will clear the selection in #1. It appears that Webkit only uses <form></form> to scope the radio input, and it does not respect Shadow DOM boundaries. Clicking a radio in another Shadow DOM should not affect the Shadow DOM somewhere else. The workaround is to replace <fieldset> with <form> in the Shadow DOM of my component.
Attachments
Fixes the bug
(8.31 KB, patch)
2019-10-03 19:22 PDT
,
Ryosuke Niwa
no flags
Details
Formatted Diff
Diff
Fix GTK+/WPT builds
(8.36 KB, patch)
2019-10-03 20:56 PDT
,
Ryosuke Niwa
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2019-07-08 18:28:19 PDT
<
rdar://problem/52808785
>
Hubert SABLONNIÈRE
Comment 2
2019-07-10 11:38:09 PDT
Hi Webkit team, I may have the same bug. I created a reduced test case here:
https://jsbin.com/wequqojaca/1/edit?html,css,js,output
The thing is, if I have a custom element with shadow DOM and if this component contains input[type=radio], all the inputs (cross shadow DOM) are in the same group. It is not the case in Chrome and Firefox. Anyone knows what the spec says and if it's a bug?
Ryosuke Niwa
Comment 3
2019-10-03 19:22:44 PDT
Created
attachment 380182
[details]
Fixes the bug
Daniel Bates
Comment 4
2019-10-03 20:33:31 PDT
Comment on
attachment 380182
[details]
Fixes the bug View in context:
https://bugs.webkit.org/attachment.cgi?id=380182&action=review
This patch looks good.
> Source/WebCore/dom/RadioButtonGroups.h:34 > + WTF_MAKE_FAST_ALLOCATED;
Ok as-is, Because of comment below there is no need make this change. No harm in doing so though the optimal Solution would be to defer making this change until a fix needs it.
> Source/WebCore/dom/TreeScope.h:142 > + std::unique_ptr<RadioButtonGroups> m_radioButtonGroups;
The optimal solution is to not use a std::unique_ptr and just use the type because: 1. Sizeof(RadioButtonGroups) == sizeof(void*) == "small data type". 2. Avoids cost of dereference. 3. m_radioButoonGroup is never re-assigned. 4. Makes the code easier to understand since no need to reason about nullptr or lazy alloc strategy.
Ryosuke Niwa
Comment 5
2019-10-03 20:54:59 PDT
Comment on
attachment 380182
[details]
Fixes the bug View in context:
https://bugs.webkit.org/attachment.cgi?id=380182&action=review
>> Source/WebCore/dom/TreeScope.h:142 >> + std::unique_ptr<RadioButtonGroups> m_radioButtonGroups; > > The optimal solution is to not use a std::unique_ptr and just use the type because: > > 1. Sizeof(RadioButtonGroups) == sizeof(void*) == "small data type". > 2. Avoids cost of dereference. > 3. m_radioButoonGroup is never re-assigned. > 4. Makes the code easier to understand since no need to reason about nullptr or lazy alloc strategy.
Oh, that's a good point for this patch. My plan is to get rid of unique_ptr in RadioButtonGroups, and I really don't want to include RadioButtonGroups.h here.
Ryosuke Niwa
Comment 6
2019-10-03 20:56:02 PDT
Created
attachment 380183
[details]
Fix GTK+/WPT builds
Ryosuke Niwa
Comment 7
2019-10-04 00:34:34 PDT
Comment on
attachment 380183
[details]
Fix GTK+/WPT builds Clearing flags on attachment: 380183 Committed
r250708
: <
https://trac.webkit.org/changeset/250708
>
Ryosuke Niwa
Comment 8
2019-10-04 00:34:36 PDT
All reviewed patches have been landed. Closing bug.
Hubert SABLONNIÈRE
Comment 9
2019-10-11 07:46:39 PDT
Great news, thanks team!! I hope my jsbin helped :p
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug