GNOME Bugzilla – Bug 566181
Changes made to Firefox 3.2 caret-moved events cause Orca to provide unreliable access during the use of the Find toolbar
Last modified: 2009-01-05 19:18:00 UTC
At some point in Firefox 3.2 we started getting detail1 values of -1 for the caret-moved events for unfocused content during a find. At first I thought this was a bogus value; now I'm not so sure. We seem to get the correct value when we're actually moving within the content. During a find, the caret is in the entry in the toolbar; not in the content. *shrug* Regardless.... We don't want to base the new caret offset -- or the current line on this value. Fortunately, we should be able to count on the selection range instead -- and do so reliably across FF 3.0, 3.1, and 3.2.
Created attachment 125589 [details] [review] fix plus a regression test update Yet another straightforward, Gecko-limited fix that has been regression tested with Firefox 3.0.5, 3.1beta2, and 3.2 (trunk build). And pylinted. And it brings us yet another step closer to a tri-version, single-set group of tests. And it fixes a rather annoying bug for our bleeding-edge users. And hence I've committed this one to trunk. Given that this patch is more than a one-liner, however, I'll move this one to pending.
Nice work. :-) Joanie -- while this is more than a one-liner, it seems appropriate for gnome-2-24. What do you think?
I agree. Done. The regression tests are so different now that I didn't commit the test change; just the fix. :-) Readjusting the milestone.