WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
196457
Slot click events not fired after visibility change
https://bugs.webkit.org/show_bug.cgi?id=196457
Summary
Slot click events not fired after visibility change
David
Reported
2019-04-01 12:35:34 PDT
I've got a shadowed Web Components which exposes a slot. The visibility of the components' elements change from 'hidden' per default to 'visible' when I call a method. After the visitility (css `visibility: hidden/visible`) as changed, the click event on the button which exposes a slot isn't triggered anymore. ``` <button onClick={() => {this.toggleLink()}}> <span>H</span> </button> ``` => click event ok even after visibility change ``` <button onClick={() => {this.toggleLink()}}> <slot name="hello"></slot> </button> <span slot="hello">H</span> ``` => no click event after the visibility change Double checked, same code work in both Firefox and Chrome.
Attachments
Example (works)
(412 bytes, text/html)
2019-04-01 19:15 PDT
,
Ryosuke Niwa
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1
2019-04-01 19:15:03 PDT
Created
attachment 366452
[details]
Example (works) Could you describe which element's visibility is getting changed? For example, click event works fine in the attached example.
David
Comment 2
2019-04-01 22:57:11 PDT
Hi, thx for the feedback. Your example could work has it is not a shadowed (shadow DOM) components. The problem occurs in a Web Component respectively in a shadowed DOM components. If you modify the :host visibility or the first container visibility, in both case then the click event isn't triggered anymore if you click on the SLOTTED elements <my-components> <!-- If you change visibility on the host --> #shadow:root <div> <!-- Or if you change visibility on the first container --> <button> <slot name="test"/> </button> </div> <my-components> <span slot="test">In both case no click events</span>
Ryosuke Niwa
Comment 3
2019-04-01 23:19:21 PDT
(In reply to David from
comment #2
)
> Hi, thx for the feedback. Your example could work has it is not a shadowed > (shadow DOM) components.
?? The attached example totally uses shadow tree.
> The problem occurs in a Web Component respectively in a shadowed DOM > components. > > If you modify the :host visibility or the first container visibility, in > both case then the click event isn't triggered anymore if you click on the > SLOTTED elements > > <my-components> <!-- If you change visibility on the host --> > #shadow:root > <div> <!-- Or if you change visibility on the first container --> > <button> > <slot name="test"/> > </button> > </div> > <my-components> > > > <span slot="test">In both case no click events</span>
Okay, the following example seems to work just fine: <!DOCTYPE html> <html> <body> <div id="host" style="visibility: hidden"><span slot="hello">H</span></div> <button onclick="s = container.style; s.visibility = s.visibility == 'hidden' ? 'visible' : 'hidden'">Toggle</button> <script> const shadowRoot = host.attachShadow({mode: 'closed'}); shadowRoot.innerHTML = ` <div id="container"> <button onclick="alert('clicked!')"> <slot name="hello"></slot> </button> </div>`; window.container = shadowRoot.getElementById('container'); </script> </body> </html> Could you just give us a complete HTML file which reproduces this issue?
David
Comment 4
2019-04-01 23:52:02 PDT
I'll try later today to reproduce the issue in a dummy project and will provide it
David
Comment 5
2019-04-02 03:50:45 PDT
Yes you are right this issue could be closed, it isn't a valid issue Actually the problem of my component is probably another webkit related issue with the selection Therefore this one could be close
Ryosuke Niwa
Comment 6
2019-04-02 14:31:25 PDT
(In reply to David from
comment #5
)
> Yes you are right this issue could be closed, it isn't a valid issue > > Actually the problem of my component is probably another webkit related > issue with the selection > > Therefore this one could be close
Great. Thanks for checking!
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