Summary: | [GTK] character range extents is off when the end of a wrapped line is included | ||||||
---|---|---|---|---|---|---|---|
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: |
|
Description
Joanmarie Diggs
2011-01-28 12:26:40 PST
(In reply to comment #0) > This may be another aspect of Bug #53300. But since they seem differentish.... As usual, can't tell for sure at this point, but IMHO this could be caused *exactly* because of the very same reason than for bug 53300: poor handling of offsets near linebreaks, because of the upstream/downstream stuff regarding to positions, I'd bet. Now working on bug 53300 to see if I can get something out of this. Who knows, perhaps we can fix the two bugs in a row, if we finally confirm this is a duplicate of the other one :-) Just a quick comment I forgot to make before: (In reply to comment #0) > [...] > 2. Launch Accerciser, select the accessible object associated with the paragraph from the test case. Then in the iPython console: > > In [1]: text = acc.queryText() > In [2]: text.getTextAtOffset(0, TEXT_BOUNDARY_LINE_START) > Out[2]: ("It's not pinin,' it's passed on! This parrot is no more! It ", 0, 60) > In [3]: text.getRangeExtents(0, 60, WINDOW_COORDS) > Out[3]: (8, 8, 333, 34) <--- Two lines high The actual problem here is not getRangeExtents() returning a result meaning "two lines high" but text.getTextAtOffset() returning 60 when it should be returning 59 in case it doesn't count the linebreak as the last character of the line. So when you ask for the extents from 0 till 60 you're actually asking "from the beginning of the first line to the beginning of the second one" This makes me wonder whether ORCA expects the linebreak to be actually exposed or not as part of the first line, as just another offset position... guess it does, though. (In reply to comment #2) > [...] > This makes me wonder whether ORCA expects the linebreak to be actually exposed or not as part of the first line, as just another offset position... guess it does, though. Stupid me, I didn't see the " " after "It" in the returned text, so 60 is correct after all, and that is how the linebreak is represented. Sorry for the noise. I should keep my thoughts for myself instead of wildly dumping them here :P Created attachment 80666 [details]
Patch proposal + unit tests
Attaching patch proposal + unit test
Comment on attachment 80666 [details] Patch proposal + unit tests View in context: https://bugs.webkit.org/attachment.cgi?id=80666&action=review > Source/WebCore/ChangeLog:12 > + requested interval shouldn't include the last character- "character-" --> "character." Committed r77234: <http://trac.webkit.org/changeset/77234> |