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>
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.
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.
http://trac.webkit.org/changeset/168847
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