Bug 49353 – ComplexTextController not prepared to handle multiple runs

• Status: RESOLVED
• Resolution: INVALID
• Component: Text

[Ned Holbrook]

If, for whatever reason, CoreText were to return multiple runs for a given text run, ComplexTextController would return incorrect results. Currently ComplexTextRun::indexAt() always returns a run-based index, but if collectComplexTextRunsForCharactersCoreText() were to generate multiple ComplexTextRun objects they would not consistently be run-based since they are just using the string index array from each run, which would start at the location of that run in the string; the same goes for ComplexTextRun::characters() and ComplexTextRun::stringLocation().

[Ned Holbrook]

Created attachment 73555 [details]
Proposed changes.

Comment on attachment 73555 [details]
Proposed changes.

View in context: https://bugs.webkit.org/attachment.cgi?id=73555&action=review

Wow, the code was totally wrong. I said r+ but I think there’s room for improvement.

> WebCore/platform/graphics/mac/ComplexTextController.h:167
> +    const int m_end;

Huh? I can’t cq+ because of this.

> WebCore/platform/graphics/mac/ComplexTextControllerCoreText.cpp:54
>      m_coreTextIndices = CTRunGetStringIndicesPtr(m_coreTextRun.get());
> -    if (!m_coreTextIndices) {
> +    if (!m_coreTextIndices || runRange.location) {

You can save the function call to CTRunGetStringIndicesPtr() if runRange.location is non-zero. I’d to it like this:
m_coreTextIndices = runRange.location ? 0 : CTRunGetStringIndicesPtr(m_coreTextRun.get())
if (!m_coreTextIndices) { …

> WebCore/platform/graphics/mac/ComplexTextControllerCoreText.cpp:58
> +        for (unsigned i = 0; i < m_glyphCount; ++i)
> +            m_coreTextIndicesVector[i] -= runRange.location;

This loop should arguably be inside an if (runRange.location) block.

[Ned Holbrook]

(In reply to comment #2)
> (From update of attachment 73555 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=73555&action=review
> 
> Wow, the code was totally wrong. I said r+ but I think there’s room for improvement.

I'm happy to make the changes you suggested, give me a minute to prepare a new patch.
 
> > WebCore/platform/graphics/mac/ComplexTextController.h:167
> > +    const int m_end;
> 
> Huh? I can’t cq+ because of this.

Is it against WebKit style to make immutable member variables const? It was purely a defensive change, but I'll back it out.

[Ned Holbrook]

Created attachment 73576 [details]
Changes per review.

Comment on attachment 73576 [details]
Changes per review.

View in context: https://bugs.webkit.org/attachment.cgi?id=73576&action=review

> WebCore/platform/graphics/mac/ComplexTextControllerCoreText.cpp:59
> +        if (runRange.location)
> +            for (unsigned i = 0; i < m_glyphCount; ++i)
> +                m_coreTextIndicesVector[i] -= runRange.location;

The WebKit style guidelines say that a multi-line block needs to be in braces. I’ll fix this when I land the patch.

[Ned Holbrook]

(In reply to comment #5)
> The WebKit style guidelines say that a multi-line block needs to be in braces. I’ll fix this when I land the patch.

That's cute: check-webkit-style didn't catch this. Thanks!

Fixed in <http://trac.webkit.org/projects/webkit/changeset/71795>. I forgot that I said I’d fix the style so I did that in <http://trac.webkit.org/projects/webkit/changeset/71796>.

[WebKit Review Bot]

http://trac.webkit.org/changeset/71795 might have broken SnowLeopard Intel Release (Tests)
The following tests are not passing:
fast/text/atsui-spacing-features.html

(In reply to comment #8)
> http://trac.webkit.org/changeset/71795 might have broken SnowLeopard Intel Release (Tests)
> The following tests are not passing:
> fast/text/atsui-spacing-features.html

Investigating.

I am really sorry. I now think that this patch was completely wrong and the code was completely right. There are actually existing test cases where CTLineGetGlyphRuns() returns multiple runs, and they were handled correctly. I mistakenly thought that this patch was about a situation that doesn’t and currently couldn’t occur in our tests (which is why it could be allowed without a test).

I am going to revert the change.

All ComplexTextRuns from a given call to collectComplexTextRunsForCharactersCoreText() should reference the substring indicated by the caller to that function (which is the basis for the CTLine created in it); the indices from all CTRuns are all relative to that same string, and don’t require any adjustment.

Reverted in <http://trac.webkit.org/changeset/71800>.

[Ned Holbrook]

(In reply to comment #12)
> Reverted in <http://trac.webkit.org/changeset/71800>.

Clearly I misunderstood the results of some of the hacking I was doing on the controller, and I appreciate both your attentiveness to this bug and its resolution. Thanks.