You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our app, observing certain properties does not result in a KVO change notification when the property changes. This seems to affect float- and double-type properties only, although not every property of this type seems to be affected. The properties are direct, i.e. not derived from other key paths.
While we haven’t been able to track it down to a test case, here is what we found:
For affected properties, will/didChangeValueForKey: is called with key == null
Consequently, calling will/didChangeValueForKey: manually within these methods causes KVO to work for them
It seems that _keyFromSelector() in NSKVOSwizzling.mm is returning nil here, i.e. the associated key object is not found
_NSKVOEnsureKeyWillNotify() is called correctly, and the associated key object is set on the object
However, it seems like the selector pointer is not the same in _NSKVOEnsureKeyWillNotify() and notifyingSetImpl(), which is why the associated key object is not found.
Any ideas on how to debug this further would be appreciated.
The text was updated successfully, but these errors were encountered:
Root caused this one: we're using objc associated objects to track selector<->key mappings. libobjc2's association logic would only search the most shallow association table in the stack.
Therefore, when you associate more than REFERENCE_LIST_SIZE (10, at the moment) keys with an object, certain keys may become inaccessible.
Fix pending investigation; filing a bug over there and working on the association table.
In our app, observing certain properties does not result in a KVO change notification when the property changes. This seems to affect float- and double-type properties only, although not every property of this type seems to be affected. The properties are direct, i.e. not derived from other key paths.
While we haven’t been able to track it down to a test case, here is what we found:
Any ideas on how to debug this further would be appreciated.
The text was updated successfully, but these errors were encountered: