[Webkit-unassigned] [Bug 72811] [Gtk] No accessible caret-moved events found in certain content
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Aug 20 19:00:33 PDT 2012
https://bugs.webkit.org/show_bug.cgi?id=72811
--- Comment #14 from Joanmarie Diggs <jdiggs at igalia.com> 2012-08-20 19:01:09 PST ---
Chris, I think you may not be understanding me. Which is my fault for writing when tired. Lemme try again.
You said in comment #7:
> The logic change here appears to be to cause <spans> and anonymous render blocks to be ignored, but doesn't WebCore do that already?
The answer is no.
* Comment 10 shows what happens if I run the layout test from
the proposed patch WITHOUT the code changes from the proposed
patch. Without the code changes, I see spans and anonymous
render blocks. I do NOT want to see spans and anonymous render
blocks
(In reply to comment #13)
> It looks like the children count is different
>
> > +FAIL element.childrenCount should be 0. Was 3.
>
> It looks like this patch makes every <span> into an accessible element. that's sort of a big change. maybe it doesn't matter, but it will add a whole lot more elements to the tree
Nope. The patch with the code changes results in their being 0 children.
To get 3 children, just use the current WebKit.
* Comment 12 shows what happens if I run that same layout test in
my shiny new Mac development environment. Using WebKit from master
and NO code changes. And the answer is: I see the same spans. You
seem to have essentially the same thing.
Based on your response in Comment #13:
> It looks like this patch makes every <span> into an accessible element.
> that's sort of a big change. maybe it doesn't matter, but it will add
> a whole lot more elements to the tree
1. My patch doesn't do that. The current code does.
2. I'm guessing that is something you didn't realize.
3. I'm guessing my next attempt should filter out those spans for us all.
Please confirm.
Thanks!
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list