Handle multiple fragments in the getCharNumberAtPosition SVGTextQuery

Handle multiple fragments in the getCharNumberAtPosition SVGTextQuery

The start position (and thus indirectly end position) used to compute the
extents of a glyph to check against the point is computed based on the
'processedCharacter' query data state. Said state is only updated after
each text box has been processed, meaning that for a text box with
multiple fragments, the offset of the fragment within the box needs to be
included to get the correct start/end position.

BUG=387725
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=176936

[pdr., 2014-06-24 20:44:08]

On 2014/06/23 16:37:01, fs wrote:

Tricky code :/

Why is this fix needed here but not elsewhere, such as
SVGTextQuery::executeQuery?

[fs, 2014-06-25 08:15:59]

On 2014/06/24 20:44:08, pdr wrote:
> On 2014/06/23 16:37:01, fs wrote:
> 
> Tricky code :/

Indeed. Lots of different offset spaces.

> Why is this fix needed here but not elsewhere, such as
> SVGTextQuery::executeQuery?

The simple answer is that this is the only place that uses |processedCharacters|
in this way to compute offsets. The mapStartEndPositionsIntoFragmentCoordinates
method then swiftly subtracts |processedCharacters| again - which means the
offset is essentially the offset within the text box... So, as you noted above,
this unnecessarily tricky for something that essentially wants to iterate
through all the glyphs of a fragment. I've been working a bit on CL that I hope
should reduce the trickiness a bit here.

[pdr., 2014-06-25 16:07:20]

On 2014/06/25 08:15:59, fs wrote:
> On 2014/06/24 20:44:08, pdr wrote:
> > On 2014/06/23 16:37:01, fs wrote:
> > 
> > Tricky code :/
> 
> Indeed. Lots of different offset spaces.
> 
> > Why is this fix needed here but not elsewhere, such as
> > SVGTextQuery::executeQuery?
> 
> The simple answer is that this is the only place that uses
|processedCharacters|
> in this way to compute offsets. The
mapStartEndPositionsIntoFragmentCoordinates
> method then swiftly subtracts |processedCharacters| again - which means the
> offset is essentially the offset within the text box... So, as you noted
above,
> this unnecessarily tricky for something that essentially wants to iterate
> through all the glyphs of a fragment. I've been working a bit on CL that I
hope
> should reduce the trickiness a bit here.

LGTM, thanks for writing up that explanation.

[fs, 2014-06-25 17:04:50]

The CQ bit was checked by fs@opera.com

[commit-bot: I haz the power, 2014-06-25 17:05:25]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/fs@opera.com/349573005/20001

[commit-bot: I haz the power, 2014-06-25 17:08:19]

Change committed as 176936