|
| 1 | +2017-05-04 Wenson Hsieh < [email protected]> |
| 2 | + |
| 3 | + [WK2] Add support for keeping the selection in a focused editable element when dragging begins |
| 4 | + https://bugs.webkit.org/show_bug.cgi?id=171585 |
| 5 | + <rdar://problem/31544320> |
| 6 | + |
| 7 | + Reviewed by Beth Dakin and Zalan Bujtas. |
| 8 | + |
| 9 | + Covered by 4 API tests. |
| 10 | + |
| 11 | + * dom/DocumentMarker.h: |
| 12 | + |
| 13 | + Introduces the DraggedContent DocumentMarker type, which applies to the Range in the DOM that is being used as |
| 14 | + a drag source. Also adds DraggedContentData, which contains nodes found by the TextIterator in the process of |
| 15 | + finding Ranges to mark. |
| 16 | + |
| 17 | + (WebCore::DocumentMarker::AllMarkers::AllMarkers): |
| 18 | + * dom/DocumentMarkerController.cpp: |
| 19 | + (WebCore::DocumentMarkerController::addDraggedContentMarker): |
| 20 | + (WebCore::shouldInsertAsSeparateMarker): |
| 21 | + (WebCore::DocumentMarkerController::addMarker): |
| 22 | + |
| 23 | + When adding DocumentMarkers of type DraggedContent, keep adjacent RenderReplaced elements separate, rather than |
| 24 | + merging them into existing RenderedDocumentMarkers. This is because the data for each of these (i.e. the target |
| 25 | + node) needs to be preserved. |
| 26 | + |
| 27 | + (WebCore::DocumentMarkerController::markersFor): |
| 28 | + |
| 29 | + Bail and return an empty list if the map of document markers cannot possibly contain a dragged content marker. |
| 30 | + |
| 31 | + * dom/DocumentMarkerController.h: |
| 32 | + * page/DragController.h: |
| 33 | + * page/DragState.h: |
| 34 | + |
| 35 | + Add draggedContentRange to DragState. This tracks the Range that is being dragged; it is created when the drag |
| 36 | + session has begun, and ends when drag session finishes (either via WebPage::dragEnded or WebPage::dragCancelled). |
| 37 | + |
| 38 | + * page/EventHandler.cpp: |
| 39 | + (WebCore::repaintContentsOfRange): |
| 40 | + (WebCore::EventHandler::dragCancelled): |
| 41 | + |
| 42 | + Called when a drag is cancelled in the UI process without a session ever getting a chance to begin. We use this |
| 43 | + as a hook to remove all DraggedContent document markers from the document of the dragged content range. |
| 44 | + |
| 45 | + (WebCore::EventHandler::didStartDrag): |
| 46 | + |
| 47 | + Called when a drag session has begun in the UI process. We use this as a hook to set up document markers for the |
| 48 | + Range of content being dragged. |
| 49 | + |
| 50 | + (WebCore::EventHandler::dragSourceEndedAt): |
| 51 | + |
| 52 | + Called when a drag session ends. We use this as a hook to remove all DraggedContent document markers from the |
| 53 | + document of the dragged content range. |
| 54 | + |
| 55 | + (WebCore::EventHandler::draggedElement): |
| 56 | + * page/EventHandler.h: |
| 57 | + * page/FocusController.cpp: |
| 58 | + (WebCore::shouldClearSelectionWhenChangingFocusedElement): |
| 59 | + |
| 60 | + Prevent the selection from clearing when the previously focused element is editable and also contains the drag |
| 61 | + source element. Ideally, we should experiment with clearing out the selection whenever the element is blurred |
| 62 | + (and not have additional restrictions on editability and containing the drag source), but this change is much |
| 63 | + riskier. |
| 64 | + |
| 65 | + (WebCore::FocusController::setFocusedElement): |
| 66 | + * rendering/InlineTextBox.cpp: |
| 67 | + (WebCore::InlineTextBox::paint): |
| 68 | + |
| 69 | + Use RenderText::draggedContentStartEnd to find the range of text (if any) that is dragged content, and paint |
| 70 | + these ranges of text at a lower alpha using TextPainter::paintTextInRange. |
| 71 | + |
| 72 | + * rendering/RenderReplaced.cpp: |
| 73 | + (WebCore::draggedContentContainsReplacedElement): |
| 74 | + |
| 75 | + Determines whether or not the element being rendered is contained within a dragged content range. Assuming that |
| 76 | + the DraggedContent type flag is set in DocumentMarkerController, we first look to see whether or not the |
| 77 | + container node is in the document marker map. If so, instead of consulting node offset ranges (since this is, in |
| 78 | + the worst-case, linear in the number of sibling nodes per RenderReplaced) we simply check the DraggedContentData |
| 79 | + to see if the current element being rendered matches one of the target nodes. |
| 80 | + |
| 81 | + (WebCore::RenderReplaced::paint): |
| 82 | + |
| 83 | + If the element rendered by this RenderReplaced is dragged content, then render it at a low alpha. |
| 84 | + |
| 85 | + * rendering/RenderText.cpp: |
| 86 | + (WebCore::RenderText::draggedContentRangesBetweenOffsets): |
| 87 | + |
| 88 | + Determines what range of text, if any, contains dragged content by consulting the Document's DocumentMarkers. |
| 89 | + |
| 90 | + * rendering/RenderText.h: |
| 91 | + * rendering/TextPainter.cpp: |
| 92 | + (WebCore::TextPainter::paintTextInRange): |
| 93 | + |
| 94 | + Teach TextPainter to only paint a given range in a TextRun. |
| 95 | + |
| 96 | + * rendering/TextPainter.h: |
| 97 | + |
| 98 | + Add TextPainter support for specifying special text offset ranges when rendering a TextRun, such that each |
| 99 | + special range in text is rendered after applying some modification to the GraphicsContext. |
| 100 | + |
1 | 101 | 2017-05-04 Jeremy Jones < [email protected]>
|
2 | 102 |
|
3 | 103 | Crash when pointer lock element is removed before pointer lock allowed arrives.
|
|
0 commit comments