webView:shouldChangeSelectedDOMRange:toDOMRange:affinity:stillSelecting: should be called before webViewDidChangeSelection: when using the mouse on an editable area: - moving the cursor with arrow keys, with or without extending the selection with shift, will call both the SHOULD and the DID method - clicking or doubleclicking will call the DID method, but not the SHOULD method
Created attachment 2973 [details] test case Create a cocoa app in xcode, replace main.m with the attachment and add the WeKit.framework to the project.
Created attachment 2975 [details] patch with changelog entries This is the first patch I develop that drills through all the glue layers, please advise.
It looks like this bug may be a partial duplicate of 3967.
Comment on attachment 2975 [details] patch with changelog entries Formatting problem -- if statements say "if(" and should say "if (" instead. Ideally we should also have a layout test. We added support to the layout test engine for reporting editing delegate output, and you can create mouse events using the DOM events support -- with these two things together you should be able to make a layout test that would work. Otherwise, looks good.
Created attachment 3201 [details] patch with changelog entries Updated for current HEAD, seems to work fine.
Comment on attachment 3201 [details] patch with changelog entries Looks good. Marking review- because there's still no layout test. If there was a test I'd have done review+.
Darin, will the test cases from 3967 suffice? As I mentioned above, this bug is pretty much a duplicate of that, so the test cases I generated for that should work. Do I need to upload them and explicitly attach to this bug?
Created attachment 3240 [details] layout test (crashes webcore) This is an attempt at building a layout test that should use the new editing delegate support in DumpRenderTree. Unfortunately I don't know much about DOM2 events, so I don't know if my JS code is correct. I can only get WebCore to crash. I will file the bug for the crash, I would need someone to look at the JS in the layout test to know if it is correct, and this bug should depend on the layout test crash bug.
A test program is not a substitute for a layout test. We don't have any way to run a compiled test program in an automated way. So the tests attached to bug 3967 don't help with the lack of layout test.
Comment on attachment 3201 [details] patch with changelog entries I guess we can't easily make a layout test for this, so r=me.
I've tried out this patch against the test application that I made for bug 3967, and I can confirm that the callback I is getting called in my test. What do we need to do to get this checked in? :-)