RESOLVED FIXED 171585
[WK2] Add support for keeping the selection in a focused editable element when dragging begins
https://bugs.webkit.org/show_bug.cgi?id=171585
Summary [WK2] Add support for keeping the selection in a focused editable element whe...
Wenson Hsieh
Reported 2017-05-02 17:57:20 PDT
Attachments
First pass (51.45 KB, patch)
2017-05-02 20:55 PDT, Wenson Hsieh
no flags
Fix OpenSource iOS build (51.38 KB, patch)
2017-05-02 21:58 PDT, Wenson Hsieh
no flags
Handle multiple dragged content ranges in RenderText (51.83 KB, patch)
2017-05-03 11:00 PDT, Wenson Hsieh
bdakin: review+
Remove TextEffectsRange, move relevant logic to InlineTextBox. (48.48 KB, patch)
2017-05-03 21:20 PDT, Wenson Hsieh
no flags
Remove TextEffectsRange, move relevant logic to InlineTextBox. (48.52 KB, patch)
2017-05-03 21:23 PDT, Wenson Hsieh
no flags
Rebased on master (48.87 KB, patch)
2017-05-03 21:30 PDT, Wenson Hsieh
no flags
Rebased on master (again) (48.89 KB, patch)
2017-05-03 21:55 PDT, Wenson Hsieh
buildbot: commit-queue-
Archive of layout-test-results from ews112 for mac-elcapitan (1.86 MB, application/zip)
2017-05-04 00:45 PDT, Build Bot
no flags
Uploading for EWS pass (48.83 KB, patch)
2017-05-04 13:12 PDT, Wenson Hsieh
no flags
Wenson Hsieh
Comment 1 2017-05-02 20:55:22 PDT
Created attachment 308888 [details] First pass
Wenson Hsieh
Comment 2 2017-05-02 21:58:58 PDT
Created attachment 308889 [details] Fix OpenSource iOS build
Wenson Hsieh
Comment 3 2017-05-03 11:00:47 PDT
Created attachment 308926 [details] Handle multiple dragged content ranges in RenderText
Beth Dakin
Comment 4 2017-05-03 14:19:48 PDT
Comment on attachment 308926 [details] Handle multiple dragged content ranges in RenderText View in context: https://bugs.webkit.org/attachment.cgi?id=308926&action=review r=me, though it would be good to get Simon, Myles, Dean, or Alan to take a look at some point. > Source/WebCore/dom/DocumentMarkerController.cpp:142 > + DocumentMarker::DraggedContentData draggedContentData { markedText.node() }; Could textPiece ever be null? If not, this is okay. If so, you should add a null check.
zalan
Comment 5 2017-05-03 14:34:29 PDT
(In reply to Beth Dakin from comment #4) > Comment on attachment 308926 [details] > Handle multiple dragged content ranges in RenderText > > View in context: > https://bugs.webkit.org/attachment.cgi?id=308926&action=review > > r=me, though it would be good to get Simon, Myles, Dean, or Alan to take a > look at some point. Wenson and I had a quick chat about textEffectsModifier logic.
Beth Dakin
Comment 6 2017-05-03 14:40:49 PDT
(In reply to zalan from comment #5) > (In reply to Beth Dakin from comment #4) > > Comment on attachment 308926 [details] > > Handle multiple dragged content ranges in RenderText > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=308926&action=review > > > > r=me, though it would be good to get Simon, Myles, Dean, or Alan to take a > > look at some point. > Wenson and I had a quick chat about textEffectsModifier logic. 👍
Wenson Hsieh
Comment 7 2017-05-03 21:20:08 PDT
Created attachment 309010 [details] Remove TextEffectsRange, move relevant logic to InlineTextBox.
Wenson Hsieh
Comment 8 2017-05-03 21:23:39 PDT
Created attachment 309011 [details] Remove TextEffectsRange, move relevant logic to InlineTextBox.
Wenson Hsieh
Comment 9 2017-05-03 21:30:09 PDT
Created attachment 309012 [details] Rebased on master
Wenson Hsieh
Comment 10 2017-05-03 21:35:37 PDT
(In reply to Beth Dakin from comment #4) > Comment on attachment 308926 [details] > Handle multiple dragged content ranges in RenderText > > View in context: > https://bugs.webkit.org/attachment.cgi?id=308926&action=review > > r=me, though it would be good to get Simon, Myles, Dean, or Alan to take a > look at some point. > > > Source/WebCore/dom/DocumentMarkerController.cpp:142 > > + DocumentMarker::DraggedContentData draggedContentData { markedText.node() }; > > Could textPiece ever be null? If not, this is okay. If so, you should add a > null check. I think this will be ok. Even if the target node is null, this will just initialize the DraggedContentData to have a null targetNode (a RefPtr). In the two places where we use this, (shouldInsertAsSeparateMarker and draggedContentContainsReplacedElement), we handle the !targetNode case gracefully, and won't crash trying to dereference null.
Wenson Hsieh
Comment 11 2017-05-03 21:55:02 PDT
Created attachment 309014 [details] Rebased on master (again)
Build Bot
Comment 12 2017-05-04 00:45:38 PDT
Comment on attachment 309014 [details] Rebased on master (again) Attachment 309014 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/3670184 New failing tests: media/modern-media-controls/media-documents/background-color-and-centering.html
Build Bot
Comment 13 2017-05-04 00:45:39 PDT
Created attachment 309024 [details] Archive of layout-test-results from ews112 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews112 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Wenson Hsieh
Comment 14 2017-05-04 13:12:50 PDT
Created attachment 309095 [details] Uploading for EWS pass
WebKit Commit Bot
Comment 15 2017-05-04 15:28:26 PDT
Comment on attachment 309095 [details] Uploading for EWS pass Clearing flags on attachment: 309095 Committed r216212: <http://trac.webkit.org/changeset/216212>
Simon Fraser (smfr)
Comment 16 2017-08-06 21:44:38 PDT
Comment on attachment 308926 [details] Handle multiple dragged content ranges in RenderText View in context: https://bugs.webkit.org/attachment.cgi?id=308926&action=review > Source/WebCore/rendering/InlineTextBox.cpp:555 > + auto draggedContentRanges = renderer().draggedContentRangesBetweenOffsets(m_start, m_start + m_len); It's a shame that we're slowing down the paint code for something that almost never happens. draggedContentRangesBetweenOffsets() shows up on profiles. It's small, but still, is there a better way to avoid this work when the user isn't dragging?
Tim Horton
Comment 17 2017-08-06 22:27:28 PDT
File a new bug! There’s surely a way.
Note You need to log in before you can comment on or make changes to this bug.