Avoid sending notifications about toolbar items' enabled state needlessly.
Tiling is expensive, but even if the toolbar item ignores redundant `setEnabled:` calls, the cost of notifications alone can really add up when there are many toolbar items.
`CPEvent timestamp` is now in seconds so the double click delay has to be adjusted. Also slightly increased double click interval to account for lower precision.
This would make the popover open with the wrong coordinates if the positioning view was in a window different than the main window, such as a utility window which can't become the main window.
E.g. a dictionary is expressed as @{key1: value1}, an array like @[value2, value2], a string like @"<value>".
Also don't put all child objects into quotation marks - that makes them all look like strings.
Apparently Rhino doesn't have `<input element>.setAttribute` and an error would be thrown in `CPCompatibility.j`: `Cannot find function setAttribute in object [object Object].`
We were compensating for a bug in Safari, older versions of Chrome and Firefox in our input placement. But new Chrome and neither IE 8 nor IE 9 needed it which resulted in the text being off in those browsers.
Locking down the line height and vertical alignment explicitly seems to work in Safari 6, Chrome 21, Firefox 14 and IE 8 (although Chrome and IE exhibit some unrelated horizontal jumping.)
This was caused by making text display generally 1 px taller to allow for fractional pixels at the bottom to show. This should however not be allowed to affect positioning (even if there is a fractional pixel below vertically centred text the text should not move up 0.5 px.)
Only the first responder of the key window should receive text input. This is important in multi-window apps or windows with sheets.
In the multi window case it should be possible to switch between two windows with first responder text fields and keep right on typing. First responder status should not be lost, but new typing should always go into the first responder text field of the key window.
For sheets, a text field which was active when the sheet opened should not receive input nor look active while the sheet is open.
If a window contained a text field which was the initial first responder, and the window was displaying a sheet, clicking on the window would cause the text field to alternate between being the first responder and not.
This was caused by the window `orderFront:` setting its first responder to the initial responder if there wasn't any responder yet. This would cause the text field to focus, even that the window wasn't the key window, and then on the next click the text field would blur which would make the text field automatically resign its first responder status.
The solution is to leave the first responder status alone if a window which isn't the key window is `orderFront:`ed. This appears to be more sensible UX in general. You don't expect the first responder of non-key windows to change when you click it's background.
Alexander Ljungberg
Antoine Mercadal