"Attempt to insert nil value " exception when calling attributed string APIs on content with a custom font
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.
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.
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.
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.
(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.
Created attachment 132884 [details] patch Updated with a new copy of Ahem for TestWebKitAPI
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).
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!
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!