Bug 132911 – sourceFrameOnScreenForShareItem: can be off by a pixel

• Component: WebKit Misc.
• Status: RESOLVED FIXED

[Brady Eidson]

sourceFrameOnScreenForShareItem: can be off by a pixel

This is due largely to sub pixel layout and conversions between FloatRects and IntRects.

In radar at <rdar://problem/16878020>

[Brady Eidson]

Created attachment 231456 [details]
Patch v1

This splits off the client rect calculation into a utility method (which will also be used in bug 132912), and that method is guaranteed to keep everything in terms of floats.

Only a single rounding conversion from Float->Int rect takes place.

This fixes the known cases of off-by-one-pixel errors.

[Simon Fraser (smfr)]

Comment on attachment 231456 [details]
Patch v1

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

> Source/WebKit/mac/WebCoreSupport/WebContextMenuClient.mm:404
> +        return NSRect();

Isn't there an NSEmptyRect or similar? I'm not sure this is constructing an empty rect.

> Source/WebKit/mac/WebCoreSupport/WebContextMenuClient.mm:409
> +        return NSRect();

Ditto.

> Source/WebKit/mac/WebCoreSupport/WebContextMenuClient.mm:414
> +    // FIXME: Ideally we'd like to convert the content rect to screen coordinates
> +    // without the lossy float -> int conversion.
> +    // Creating a rounded int rect works well in practice, but might still lead to
> +    // off-by-one-pixel problems in edge cases.

You should file a bugzilla/radar to track this and reference it here.

[Brady Eidson]

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

[Darin Adler]

Comment on attachment 231456 [details]
Patch v1

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

>> Source/WebKit/mac/WebCoreSupport/WebContextMenuClient.mm:404
>> +        return NSRect();
> 
> Isn't there an NSEmptyRect or similar? I'm not sure this is constructing an empty rect.

NSZeroRect