Bug 68466
| Summary: | Accessibility: Children changed notification fired on wrong node for visibility change | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Dominic Mazzoni <dmazzoni> |
| Component: | Accessibility | Assignee: | Nobody <webkit-unassigned> |
| Status: | UNCONFIRMED | ||
| Severity: | Normal | CC: | aboxhall, cfleizach, davidbarr, ericliang, jcraig, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Dominic Mazzoni
If I have a parent node P and I insert a child C, I get the children changed notification on the parent P, as I'd expect.
However, if I then make C invisible, or subsequently make it visible again, I get a children changed notification on C, which seems like a bug. On Windows we really need to have the notification on P, and it seems like that'd be the more logical thing to do in WebCore. I haven't yet tested to see if on the Mac VoiceOver is actually expecting the notification on C, or if it would work equally well on P, or if this is actually a bug under some circumstances.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
chris fleizach
yes that does seem like a bug. it seems strange that it would happen since i believe all of these node destroyed methods operate on renderer()->parent()
Dominic Mazzoni
(In reply to comment #1)
> yes that does seem like a bug. it seems strange that it would happen since i believe all of these node destroyed methods operate on renderer()->parent()
To clarify, this was setting visibility:hidden, not display:none. I think that objects with visibility:hidden still have render objects associated with them because they take up space on the page, so that may be the difference. I think you're right, when you actually delete a node, or set a node to display:none which deletes the render object, the notification is correct.
chris fleizach
(In reply to comment #2)
> (In reply to comment #1)
> > yes that does seem like a bug. it seems strange that it would happen since i believe all of these node destroyed methods operate on renderer()->parent()
>
> To clarify, this was setting visibility:hidden, not display:none. I think that objects with visibility:hidden still have render objects associated with them because they take up space on the page, so that may be the difference. I think you're right, when you actually delete a node, or set a node to display:none which deletes the render object, the notification is correct.
With that in mind, I can see how this is probably doing the wrong thing
Radar WebKit Bug Importer
<rdar://problem/15709910>