60506 2011-05-09 14:40:09 -0700 REGRESSION: drag caret isn't drawn in Mac DRT 2011-08-05 12:06:15 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Unspecified Unspecified NEW P1 Critical --- 1 rniwa webkit-unassigned ap aroben darin enrica eric mjs sam oldest_to_newest 400764 0 rniwa 2011-05-09 14:40:09 -0700 Mac DumpRenderTree has regressed and no longer draws drag caret: http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/editing/selection/drag-in-iframe-expected.png This is unrelated to the regression introduced in r86039, which is tracked in the bug 60505. As far as I investigated, In mouseMoveToX (DumpRenderTree/mac/EventSendingController.mm), draggingInfo is null and draggingUpdated is never called. Even if I forced to call draggingUpdated, dragData->containsCompatibleContent() returns false in DragController::canProcessDrag (which is in turn called by DragController::concludeEditDrag) and never sets drag caret. Unfortunately, I don't know enough about Mac port to fix this regression. 400806 1 ap 2011-05-09 15:21:34 -0700 Do you happen to know what revision caused the regression? Perhaps it can be just reverted? 400808 2 ap 2011-05-09 15:22:03 -0700 Also, does this only affect DRT, or the browser, too? 400814 3 rniwa 2011-05-09 15:28:55 -0700 (In reply to comment #1) > Do you happen to know what revision caused the regression? Perhaps it can be just reverted? Unfortunately no. I'm suspecting http://trac.webkit.org/changeset/43890 but that's just my speculation. It didn't help that Mac test bots don't run pixel tests. We should add a drag caret position in render tree dump in the future so that render tree dump difference catch this kind of regression in the future. (In reply to comment #2) > Also, does this only affect DRT, or the browser, too? This bug only affects DRT. It's not updating DragCaretController properly. However, there is a pending bug 60505 that broke this feature (due to this feature not being tested).