[Webkit-unassigned] [Bug 8850] cocoa bindings - crash when DOM nodes are deleted while NSTreeController+NSTableView are bound

bugzilla-daemon at opendarwin.org bugzilla-daemon at opendarwin.org
Wed Jun 28 10:06:44 PDT 2006


http://bugzilla.opendarwin.org/show_bug.cgi?id=8850


speth at end.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #9057 is|0                           |1
           obsolete|                            |
   Attachment #9081|                            |review?
               Flag|                            |




------- Comment #13 from speth at end.com  2006-06-28 10:06 PDT -------
Created an attachment (id=9081)
 --> (http://bugzilla.opendarwin.org/attachment.cgi?id=9081&action=view)
patch implementing comment #11

this patch pretty much follows what I outlined above.  it seems to work fine,
but i have not run any performance tests on it.

Also, i did not separate the KVO messages.  Normally, I'd agree that it is
wrong to have them back to back like that, but childNodes is special.. Every
call to childNodes produces a different DOMNodeList object, so strictly
speaking, the value did change.  As far as KVO is concerned, the contents of
the DOMNodeList are opaque.  The contents would be accessed by additional keys
on a keyPath, which would be responsible for triggering their own change
messages.  I think this adheres to the KVO contract.

In my mind it's somewhat like an accessor that increments the value each
time... willChange and didChange could be called as often as we'd like, we'd
just have to make a determination as to what makes sense.  Given that the
DOMNodeList itself only receives notifications after the fact, this seems right
to me. Plus, it works.

But if anyone has a better idea about where to put the willChange, let's move
it.


-- 
Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list