RESOLVED FIXED 141210
[iOS] Selection Callout should not immediately disappear on pages with frequent layouts
https://bugs.webkit.org/show_bug.cgi?id=141210
Summary [iOS] Selection Callout should not immediately disappear on pages with freque...
Joseph Pecoraro
Reported 2015-02-03 13:55:56 PST
* SUMMARY Selection Callout should not immediately disappear on pages with frequent layouts. At the same time, the caret should be blinking, instead of staying constant blue. * STEPS TO REPRODUCE 1. Load http://archive.org/web/ 2. Focus text field 3. Attempt to paste => callout dismisses immediately after showing * NOTES - JavaScript animation is triggering layout -> triggers selection update -> dismisses callout and re-updates caret
Attachments
[PATCH] Proposed Fix (6.32 KB, patch)
2015-02-03 14:06 PST, Joseph Pecoraro
enrica: review+
joepeck: commit-queue-
[PATCH] Proposed Fix (6.31 KB, patch)
2015-02-03 15:10 PST, Joseph Pecoraro
no flags
mitz
Comment 1 2015-02-03 14:00:20 PST
Joseph Pecoraro
Comment 2 2015-02-03 14:06:04 PST
Created attachment 245966 [details] [PATCH] Proposed Fix Not really sure if there is a way to test this. Any pointers?
WebKit Commit Bot
Comment 3 2015-02-03 14:08:28 PST
Attachment 245966 [details] did not pass style-queue: ERROR: Source/WebKit2/UIProcess/ios/WKContentViewInteraction.h:78: The parameter name "editorState" adds no information, so it should be removed. [readability/parameter_name] [5] Total errors found: 1 in 3 files If any of these errors are false positives, please file a bug against check-webkit-style.
Joseph Pecoraro
Comment 4 2015-02-03 15:10:02 PST
Created attachment 245972 [details] [PATCH] Proposed Fix Fixed style.
Enrica Casucci
Comment 5 2015-02-03 15:15:07 PST
Comment on attachment 245966 [details] [PATCH] Proposed Fix The patch looks good.I'm assuming you tested zooming on a page where a field is focused. Please check the windows build failure before submitting.
Enrica Casucci
Comment 6 2015-02-03 15:15:52 PST
Comment on attachment 245966 [details] [PATCH] Proposed Fix The patch looks good.I'm assuming you tested zooming on a page where a field is focused. Please check the windows build failure before submitting.
Joseph Pecoraro
Comment 7 2015-02-03 15:33:03 PST
(In reply to comment #6) > Comment on attachment 245966 [details] > [PATCH] Proposed Fix > > The patch looks good.I'm assuming you tested zooming on a page where a field > is focused. Yep, testing zooming is exactly why there is the force path. > Please check the windows build failure before submitting. This patch doesn't modify anything for Windows, so I'll assume it was just a passing thing.
WebKit Commit Bot
Comment 8 2015-02-03 16:18:46 PST
Comment on attachment 245972 [details] [PATCH] Proposed Fix Clearing flags on attachment: 245972 Committed r179578: <http://trac.webkit.org/changeset/179578>
WebKit Commit Bot
Comment 9 2015-02-03 16:18:49 PST
All reviewed patches have been landed. Closing bug.
Sam Weinig
Comment 10 2015-02-03 18:09:48 PST
Comment on attachment 245972 [details] [PATCH] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=245972&action=review > Source/WebKit2/UIProcess/ios/WKContentViewInteraction.h:75 > +struct WKSelectionDrawingInfo { This does not need, and should not have, a WK prefix. I realize there is a counter example right below, but that is wrong. > Source/WebKit2/UIProcess/ios/WKContentViewInteraction.h:76 > + enum class SelectionType { None, Plugin, Range }; We usually put this on multiple lines. > Source/WebKit2/UIProcess/ios/WKContentViewInteraction.h:81 > + WKSelectionDrawingInfo(); > + explicit WKSelectionDrawingInfo(const EditorState&); > + SelectionType type; > + WebCore::IntRect caretRect; > + Vector<WebCore::SelectionRect> selectionRects; This would read nicer if you put a space between the constructors and the members.
Note You need to log in before you can comment on or make changes to this bug.