Bug 81630 – "Attempt to insert nil value " exception when calling attributed string APIs on content with a custom font

• Component: HTML Editing
• Status: RESOLVED FIXED

[Adele Peterson]

"Attempt to insert nil value " exception when calling attributed string APIs on content with a custom font

[Adele Peterson]

Created attachment 132755 [details]
patch

I'm not sure if the way I'm referencing the font in the TestWebKitAPI project file is kosher.  If it is not, I can just check in another copy of Ahem.

[Alexey Proskuryakov]

Comment on attachment 132755 [details]
patch

Can this just use a layout test instead? We expose these methods through textInputController in DumpRenderTree. WebKitTestRunner is currently more limited, but it will definitely support this eventually, too.

[Adele Peterson]

I do have a layout test that works in DRT, but since I couldn't get it to work in WebKitTestRunner, even while trying to add the feature to textInputController, I switched to making an API test.  I couldn't figure out how to call attributedSubstringForProposedRange from WebKitTestRunner/InjectedBundle/TextInputController.cpp.  Do you think that is possible?

(In reply to comment #2)
> (From update of attachment 132755 [details])
> Can this just use a layout test instead? We expose these methods through textInputController in DumpRenderTree. WebKitTestRunner is currently more limited, but it will definitely support this eventually, too.

[Alexey Proskuryakov]

I see, so the issue here is that we need to do the conversion in another process. That won't work with textInputController indeed.

If you have attributedSubstringForProposedRange implemented in WTR, I'd encourage you to see if you can land that and unskip some of the tests that are currently skipped in mac-wk2.

Patch looks good to me, but I don't know the answer to your question about Ahem.

[Adele Peterson]

(In reply to comment #4)
> I see, so the issue here is that we need to do the conversion in another process. That won't work with textInputController indeed.
> 
> If you have attributedSubstringForProposedRange implemented in WTR, I'd encourage you to see if you can land that and unskip some of the tests that are currently skipped in mac-wk2.

No, I just have an empty implementation.

> 
> Patch looks good to me, but I don't know the answer to your question about Ahem.

(In reply to comment #1)
> Created an attachment (id=132755) [details]
> patch
> 
> I'm not sure if the way I'm referencing the font in the TestWebKitAPI project file is kosher.  If it is not, I can just check in another copy of Ahem.

Please give TestWebKitAPI its own copy.

[Adele Peterson]

Created attachment 132884 [details]
patch

Updated with a new copy of Ahem for TestWebKitAPI

[Adele Peterson]

http://trac.webkit.org/changeset/111436

Comment on attachment 132884 [details]
patch

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

> Tools/TestWebKitAPI/Tests/mac/AttributedString.mm:88
> +    EXPECT_TRUE([[attrString string] isEqual:@"Lorem"]);

You could have used EXPECT_WK_STREQ here. When it fails, prints the actual string (as opposed to just the fact that it’s not the expected one).

[Adele Peterson]

Created attachment 132902 [details]
updated the test

Comment on attachment 132902 [details]
updated the test

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

> Tools/ChangeLog:5
> +        Reviewed by .

Me!

[Adele Peterson]

That's what I had in there, but I didn't want to be presumptuous :)

http://trac.webkit.org/changeset/111443

(In reply to comment #11)
> (From update of attachment 132902 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=132902&action=review
> 
> > Tools/ChangeLog:5
> > +        Reviewed by .
> 
> Me!