Bug 199568 - Radio button groups are not scoped by shadow boundaries
Summary: Radio button groups are not scoped by shadow boundaries
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: Safari 12
Hardware: Mac macOS 10.14
: P2 Normal
Assignee: Ryosuke Niwa
URL:
Keywords: InRadar
Depends on:
Blocks: 148695
  Show dependency treegraph
 
Reported: 2019-07-08 01:00 PDT by Jonathan Lin
Modified: 2019-10-14 13:49 PDT (History)
15 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Lin 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.
Comment 1 Radar WebKit Bug Importer 2019-07-08 18:28:19 PDT
<rdar://problem/52808785>
Comment 2 Hubert SABLONNIÈRE 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?
Comment 3 Ryosuke Niwa 2019-10-03 19:22:44 PDT
Created attachment 380182 [details]
Fixes the bug
Comment 4 Daniel Bates 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.
Comment 5 Ryosuke Niwa 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.
Comment 6 Ryosuke Niwa 2019-10-03 20:56:02 PDT
Created attachment 380183 [details]
Fix GTK+/WPT builds
Comment 7 Ryosuke Niwa 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>
Comment 8 Ryosuke Niwa 2019-10-04 00:34:36 PDT
All reviewed patches have been landed.  Closing bug.
Comment 9 Hubert SABLONNIÈRE 2019-10-11 07:46:39 PDT
Great news, thanks team!!
I hope my jsbin helped :p