GNOME Bugzilla – Bug 549529
Improve our handling of caret-moved events when Gecko is controlling the caret
Last modified: 2009-03-10 00:05:47 UTC
Gecko can be controlling the caret for a couple reasons: 1. The user has chosen this option. 2. We're in an environment in which we've decided not to control caret navigation (e.g. ARIA). In the first case, we often fail to speak the new caret location; in the latter, we sometimes double-braille and/or double-speak it. While one could argue that this strikes a balance so that we break even, it would probably be better for us to fix things. :-)
Created attachment 117431 [details] [review] revision 1 (the gosh I hope I got it right version) The attached fixes the bulk of the "BUG?"s (some marked, many not but on my radar) in the regression tests related to ARIA. Yea! As an added bonus, it seems to improve our ability to read lines arrowed to in Firefox and Thunderbird when Gecko is controlling the caret. Yea! Reminder: The native Gecko caret navigation is still significantly busted which is why we default to controlling the caret ourselves. This patch does not in any way attempt to remedy that. It should just cause us to speak the correct line wherever Gecko happens to place us. That said, on a predominately text-based site, the Gecko-controlled caret doesn't seem to be doing all that badly with this patch. Seems slightly peppier too. Anyhoo, please beat on this. Thanks!
This patch (combined with some other stuff I'm working on) causes us to both speak and braille the selected state of text when Gecko is controlling the caret -- which is certainly a step in the right direction. Therefore making this a blocking bug for the text selection bug.
The only thing I'm noticing with this patch is that selection is now brailled but not spoken. I have tested several pages with gecko controling the caret.
Thanks Mike! Please also test in Thunderbird with Gecko controlling the caret. As for selection, the fact that it is brailled is a happy side effect of this patch, though braille still needs tweaking (like when selection crosses object boundaries). I haven't addressed speech at all in this patch, but am working on it. I just want to be sure this patch is good -- and then get it checked in -- so that I can use its changes as part of the selection work.
If I let gecko control the caret with latest thunderbird trunk I am not able to arrow through bugzilla messages at all.
1) Is that with the patch or without? 2) Is the behavior with the patch different or the same?
Both with and without. I thought you were implying that this patch should fix the problem.
It fixes it in HTML/non-plain text messages (not bugzilla). At least for me. Right now I want to deal with some of the remaining OOo issues, but after that I would be happy to look at Gecko-controlled access to Bugzilla messages. If you could keep testing the patch in the meantime as-is, I'd appreciate it because if it doesn't break anything I'll check it in so I can work on selection.
I'm not seeing any other issued related to this patch. I think it is OK to check in if you think it is ready.
Thanks Mike. I do think it's ready, and I do think it improves quite a few things. Plus methinks a tarball deadline approacheth. :-) Patch committed to trunk. Moving this to pending. While I haven't investigated it yet, I suspect the issue you raised is part of a bug related to getTextLineAtCaret(). Regardless, I'll open a new bug for it if need be (i.e. if it doesn't get fixed as a happy side effect of other work).