WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
53323
[GTK] character range extents is off when the end of a wrapped line is included
https://bugs.webkit.org/show_bug.cgi?id=53323
Summary
[GTK] character range extents is off when the end of a wrapped line is included
Joanmarie Diggs
Reported
Friday, January 28, 2011 8:26:40 PM UTC
This may be another aspect of
Bug #53300
. But since they seem differentish.... Steps to reproduce: 1. Open the test case from
Bug #53300
(
https://bugs.webkit.org/attachment.cgi?id=80446
) and resize the window so that the text wraps as follows: It's not pinin,' it's passed on! This parrot is no more! It has ceased to be! It's expired and gone to meet its maker! This is a late parrot! It's a stiff! Bereft of life, it [...] 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 In [4]: text.getRangeExtents(0, 59, WINDOW_COORDS) Out[4]: (8, 8, 333, 17) 3. Repeat the test using Gedit. In [5]: text = acc.queryText() In [6]: text.getTextAtOffset(0, TEXT_BOUNDARY_LINE_START) Out[6]: ("It's not pinin,' it's passed on! This parrot is no more! It ", 0, 60) In [7]: text.getRangeExtents(0, 60, WINDOW_COORDS) Out[7]: (6, 94, 472, 17) In [8]: text.getRangeExtents(0, 59, WINDOW_COORDS) Out[8]: (6, 94, 472, 17) As a result of the above difference, Orca's "flat review" feature presents multiple lines, rather than just one line, at a time. It would be quite helpful if the extents from WebKitGtk could match what we see from Gtk Text widgets.
Attachments
Patch proposal + unit tests
(5.02 KB, patch)
2011-01-31 11:27 PST
,
Mario Sanchez Prada
mrobinson
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Mario Sanchez Prada
Comment 1
Saturday, January 29, 2011 3:08:55 PM UTC
(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 :-)
Mario Sanchez Prada
Comment 2
Saturday, January 29, 2011 3:27:59 PM UTC
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.
Mario Sanchez Prada
Comment 3
Saturday, January 29, 2011 3:31:18 PM UTC
(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
Mario Sanchez Prada
Comment 4
Monday, January 31, 2011 7:27:01 PM UTC
Created
attachment 80666
[details]
Patch proposal + unit tests Attaching patch proposal + unit test
Martin Robinson
Comment 5
Monday, January 31, 2011 11:27:29 PM UTC
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."
Mario Sanchez Prada
Comment 6
Tuesday, February 1, 2011 9:54:46 AM UTC
Committed
r77234
: <
http://trac.webkit.org/changeset/77234
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug