diff options
author | Max <post@wickenrode.com> | 2016-11-04 02:30:27 +0100 |
---|---|---|
committer | Max <post@wickenrode.com> | 2016-11-04 02:30:27 +0100 |
commit | 013fff399923954233d0440675957afdb67c6f8c (patch) | |
tree | 77f0ed8cd34e4e7c404aa42049cbcf9360442c2a /Source/SPFavoritesController.h | |
parent | f77f8715cf1bcc8811804008fc5d3ac964988ce1 (diff) | |
download | sequelpro-013fff399923954233d0440675957afdb67c6f8c.tar.gz sequelpro-013fff399923954233d0440675957afdb67c6f8c.tar.bz2 sequelpro-013fff399923954233d0440675957afdb67c6f8c.zip |
Swap two method calls to prevent a crash with the 10.12 SDK (#2609)
With this change we no longer KVObserve an object we aren’t interested in anymore and the -tabView:didCloseTabViewItem: method actually matches its name now (before it was more of a tabView:willCloseTabViewItem: method).
Background:
Normally the tab bar cell observes its delegate’s (SPDatabaseDocument) isProcessing property. Changes to this will trigger an async redraw of the tab view. The redrawing itself may involve a timer and a call to the tab view delegate (SPWindowController). Now, when the window is being closed this would cause the connection to close, which would affect the isProcessing property. However this time, when the timer is being fired the window controller would already be dealloc’d (since the tab bar delegate is unretained) causing a use-after-free crash.
Previously -[PSMTabBarControl viewWillMoveToWindow:] stepped in at the right time and killed the timer before it could fire but on 10.12 the calls have shifted so the timer actually gets to fire and crash.
This change solves the issue by not even letting the tab bar come to the point where it creates the problematic timer.
Diffstat (limited to 'Source/SPFavoritesController.h')
0 files changed, 0 insertions, 0 deletions