Summary: | [GTK] Space characters in source document interfere with reported caret offset | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Joanmarie Diggs <jdiggs> | ||||||
Component: | Accessibility | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | apinheiro, mario | ||||||
Priority: | P2 | Keywords: | Gtk | ||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | PC | ||||||||
OS: | Linux | ||||||||
Bug Depends on: | |||||||||
Bug Blocks: | 25531 | ||||||||
Attachments: |
|
Created attachment 80348 [details]
Patch proposal + unit tests
Attaching a patch proposal and the new unit test needed.
Comment on attachment 80348 [details]
Patch proposal + unit tests
Looks sane!
Committed r76822: <http://trac.webkit.org/changeset/76822> |
Created attachment 79949 [details] test case There are three paragraphs in the attached test case. Each paragraph's (displayed) text is the same length. Aside from the different word order in paragraph three, what distinguishes these paragraphs is whitespace in the source document: * p1 - no extraneous whitespace * p2 - one word per line (i.e. extraneous newline chars) * p3 - one word per line plus crazy use of space chars p1 and p2 seem to work as expected for all aspects of AtkText. p3 has problems with the reported caret offset (both during caret-moved events and when the caretOffset is requested). From Accerciser: In [1]: p1 = acc.queryText() In [2]: p1.getText(0, -1) Out[2]: 'Is this paragraph borked?' In [3]: p2 = acc.queryText() In [4]: p2.getText(0, -1) Out[4]: 'Is this paragraph borked?' In [5]: p3 = acc.queryText() In [6]: p3.getText(0, -1) Out[6]: 'This paragraph is borked!' In [7]: p1.characterCount Out[7]: 25 In [8]: p2.characterCount Out[8]: 25 In [9]: p3.characterCount Out[9]: 25 ^^^ Proof that most things are ok :-) ^^^ When moving by word, starting from the top of the file in Epiphany: object:text-caret-moved(2, 0, None) source: [paragraph | ] application: [application | epiphany-browser] object:text-caret-moved(7, 0, None) source: [paragraph | ] application: [application | epiphany-browser] object:text-caret-moved(17, 0, None) source: [paragraph | ] application: [application | epiphany-browser] object:text-caret-moved(24, 0, None) source: [paragraph | ] application: [application | epiphany-browser] object:text-caret-moved(2, 0, None) source: [paragraph | ] application: [application | epiphany-browser] object:text-caret-moved(7, 0, None) source: [paragraph | ] application: [application | epiphany-browser] object:text-caret-moved(17, 0, None) source: [paragraph | ] application: [application | epiphany-browser] object:text-caret-moved(24, 0, None) source: [paragraph | ] application: [application | epiphany-browser] object:text-caret-moved(4, 0, None) source: [paragraph | ] application: [application | epiphany-browser] ^^^ This is all fine too. :-) ^^^ But here's where the crazy whitespace begins in the source document: object:text-caret-moved(40, 0, None) source: [paragraph | ] application: [application | epiphany-browser] object:text-caret-moved(97, 0, None) source: [paragraph | ] application: [application | epiphany-browser] object:text-caret-moved(468, 0, None) source: [paragraph | ] application: [application | epiphany-browser] As a reminder: In [9]: p3.characterCount Out[9]: 25 ;-) ;-) Also at this point: In [10]: p3.caretOffset Out[10]: 468 In terms of WebKit Bugzilla, I cannot justify calling this a P1. BUT, in terms of other priorities, including Yelp 3 accessibility... If possible, please drop everything else and consider this a P1. The impact of this bug is Orca's going to get bogus caret-moved events and speak the wrong words any time there is extra space characters present. This will also interfere with Orca's ability to correctly report text selection. And we need sufficient time for the fixed WebKitGtk to get picked up downstream before GNOME 3. Sorry I just now noticed this and thanks in advance for prioritizing it!!