Bug 85081 – accessibility/misspelled-attributed-string.html test sometimes throws exceptions

• Status: RESOLVED
• Resolution: FIXED
• Component: Accessibility

[chris fleizach]

It seems that sometimes results from the spell checker can return a range that is outside the bounds of what we've expected

We should put more range checking into our attributed string methods


2012-04-19 11:28:28.275 WebProcess[4804:403] *** Terminating app due to uncaught exception 'NSRangeException', reason: 'NSMutableRLEArray objectAtIndex:effectiveRange:: Out of bounds'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff9a5e4fc6 __exceptionPreprocess + 198
	1   libobjc.A.dylib                     0x00007fff8e343d5e objc_exception_throw + 43
	2   CoreFoundation                      0x00007fff9a5e4dfa +[NSException raise:format:arguments:] + 106
	3   CoreFoundation                      0x00007fff9a5e4d84 +[NSException raise:format:] + 116
	4   Foundation                          0x00007fff951a228d -[NSRLEArray objectAtIndex:effectiveRange:] + 117
	5   Foundation                          0x00007fff951a49b1 -[NSConcreteMutableAttributedString addAttribute:value:range:] + 166
	6   WebCore                             0x0000000108d9a519 _ZL28AXAttributedStringAppendTextP25NSMutableAttributedStringPN7WebCore4NodeEPKti + 2393
	7   WebCore                             0x0000000108d9966b -[WebAccessibilityObjectWrapper doAXAttributedStringForTextMarkerRange:] + 1387
	8   WebCore                             0x0000000108da490d -[WebAccessibilityObjectWrapper doAXAttributedStringForRange:] + 205
	9   WebCore                             0x0000000108da9c37 -[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:] + 19975

[chris fleizach]

Created attachment 139230 [details]
patch

[Darin Adler]

Comment on attachment 139230 [details]
patch

If the ranges can be “wrong” then we might want to do a more complete test than just testing is the end of the range is past the end of the string. For example, if a location is large, then adding the length to it might overflow, so NSMaxRange could be less than the string length. To handle that case too, we'd also want to check if the location is > [attString length]. A good way to do that would be a helper function named isValidRange or something like that.

But if the type of wrong ranges we are getting are guaranteed to not have any overflow, then this patch might be OK.

However, I think a “why” comment explaining the reason for these checks would be good.

[chris fleizach]

(In reply to comment #2)
> (From update of attachment 139230 [details])
> If the ranges can be “wrong” then we might want to do a more complete test than just testing is the end of the range is past the end of the string. For example, if a location is large, then adding the length to it might overflow, so NSMaxRange could be less than the string length. To handle that case too, we'd also want to check if the location is > [attString length]. A good way to do that would be a helper function named isValidRange or something like that.
> 
> But if the type of wrong ranges we are getting are guaranteed to not have any overflow, then this patch might be OK.
> 

We should also check against overflow. good idea. will do so

> However, I think a “why” comment explaining the reason for these checks would be good.

Yep

[chris fleizach]

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