Summary: | CMD+R / CMD+Q is considered as user interaction and beforeunload alert is shown | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Chris Dumez <cdumez> | ||||||||||||||||||||||||||
Component: | DOM | Assignee: | Chris Dumez <cdumez> | ||||||||||||||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||||||||||||||
Severity: | Normal | CC: | achristensen, beidson, bfulgham, buildbot, cdumez, commit-queue, dbates, esprehn+autocc, ggaren, japhet, kangil.han, rmondello, rniwa, sam | ||||||||||||||||||||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||||||||||||||||||||
Version: | WebKit Nightly Build | ||||||||||||||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||||||||||||
Bug Depends on: | 169936 | ||||||||||||||||||||||||||||
Bug Blocks: | 178183 | ||||||||||||||||||||||||||||
Attachments: |
|
Description
Chris Dumez
2017-03-22 22:20:00 PDT
Created attachment 305166 [details]
Patch
Created attachment 305167 [details]
Patch
Comment on attachment 305167 [details] Patch Attachment 305167 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/3392801 New failing tests: editing/mac/input/kotoeri-enter-to-confirm-and-newline.html fast/events/js-keyboard-event-creation.html fast/events/arrow-keys-on-body.html editing/selection/editable-div-clear-on-keydown.html fast/events/key-events-in-input-button.html fast/events/selectionchange-user-initiated.html fast/events/beforeunload-alert-user-interaction.html fast/html/details-keyboard-show-hide.html fast/forms/radio/radio_checked_name.html fast/events/onchange-setvalue.html accessibility/mac/checkbox-posts-value-change-notification-after-activation-with-space.html http/tests/navigation/keyboard-events-during-provisional-navigation.html fast/events/special-key-events-in-input-text.html fast/forms/button-spacebar-click.html fast/forms/submit-to-blank-multiple-times.html fast/events/keydown-function-keys.html fast/frames/focus-controller-crash-change-event.html platform/mac/fast/events/objc-event-api.html fast/events/keyboardevent-code.html fast/events/key-events-in-input-text.html fast/forms/input-image-submit.html fast/forms/enter-clicks-buttons.html fast/events/keyboardevent-key.html Created attachment 305170 [details]
Archive of layout-test-results from ews102 for mac-elcapitan
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Comment on attachment 305167 [details] Patch Attachment 305167 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/3392810 New failing tests: editing/mac/input/kotoeri-enter-to-confirm-and-newline.html fast/events/js-keyboard-event-creation.html fast/events/arrow-keys-on-body.html editing/selection/editable-div-clear-on-keydown.html fast/events/key-events-in-input-button.html fast/events/selectionchange-user-initiated.html fast/events/beforeunload-alert-user-interaction.html fast/html/details-keyboard-show-hide.html fast/forms/radio/radio_checked_name.html fast/events/onchange-setvalue.html accessibility/mac/checkbox-posts-value-change-notification-after-activation-with-space.html http/tests/navigation/keyboard-events-during-provisional-navigation.html fast/events/special-key-events-in-input-text.html fast/forms/button-spacebar-click.html fast/forms/submit-to-blank-multiple-times.html fast/events/keydown-function-keys.html fast/frames/focus-controller-crash-change-event.html platform/mac/fast/events/objc-event-api.html fast/events/keyboardevent-code.html fast/events/key-events-in-input-text.html fast/forms/input-image-submit.html fast/forms/enter-clicks-buttons.html fast/events/keyboardevent-key.html Created attachment 305171 [details]
Archive of layout-test-results from ews117 for mac-elcapitan
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews117 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Comment on attachment 305167 [details] Patch Attachment 305167 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/3392849 New failing tests: http/tests/navigation/keyboard-events-during-provisional-navigation.html fast/forms/submit-to-blank-multiple-times.html fast/events/selectionchange-user-initiated.html fast/events/js-keyboard-event-creation.html fast/forms/radio/radio_checked_name.html fast/events/onchange-setvalue.html fast/events/arrow-keys-on-body.html fast/forms/button-spacebar-click.html fast/frames/focus-controller-crash-change-event.html fast/html/details-keyboard-show-hide.html fast/events/keyboardevent-code.html accessibility/mac/checkbox-posts-value-change-notification-after-activation-with-space.html fast/events/beforeunload-alert-user-interaction.html fast/events/special-key-events-in-input-text.html fast/events/key-events-in-input-button.html fast/events/keydown-function-keys.html fast/events/key-events-in-input-text.html fast/forms/input-image-submit.html editing/selection/editable-div-clear-on-keydown.html fast/forms/enter-clicks-buttons.html fast/events/keyboardevent-key.html Created attachment 305172 [details]
Archive of layout-test-results from ews106 for mac-elcapitan-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews106 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6
Created attachment 305197 [details]
Patch
Instead of differentiating between keyup/keydown, could we instead find out if the event was handled at all by the page and base it off that? (In reply to Sam Weinig from comment #11) > Instead of differentiating between keyup/keydown, could we instead find out > if the event was handled at all by the page and base it off that? Probably, I was trying to match Firefox's behavior though since they are the only ones doing this at the moment. Also wouldn't this mean that we would show the alert on CMD+Q of the body had a keydown handler? (In reply to Chris Dumez from comment #12) > (In reply to Sam Weinig from comment #11) > > Instead of differentiating between keyup/keydown, could we instead find out > > if the event was handled at all by the page and base it off that? > > Probably, I was trying to match Firefox's behavior though since they are the > only ones doing this at the moment. > > Also wouldn't this mean that we would show the alert on CMD+Q of the body > had a keydown handler? Took a quick look to see how easy to see if the key event was handled. I looked at the boolean returned by dispatchEvent() and event.wasDefaultHandled() flags but they did not seem to help recognize the case where the user pressed a key in an editable field (which does not have an event handler). ping? Corresponding Gecko code: nsCOMPtr<nsINode> node = do_QueryInterface(aTargetContent); if (node && (aEvent->mMessage == eKeyUp || aEvent->mMessage == eMouseUp || aEvent->mMessage == eWheel || aEvent->mMessage == eTouchEnd || aEvent->mMessage == ePointerUp)) { nsIDocument* doc = node->OwnerDoc(); while (doc && !doc->UserHasInteracted()) { doc->SetUserHasInteracted(true); doc = nsContentUtils::IsChildOfSameType(doc) ? doc->GetParentDocument() : nullptr; } } So they indeed treat KeyUp as user interaction with the document but not KeyDown. Created attachment 306093 [details]
Patch
Comment on attachment 306093 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=306093&action=review r=me > Source/WebCore/dom/Document.h:1156 > + void markUserDidInteractWithPage() { m_userDidInteractWithPage = true; } I would just use normal "set" syntax here: setUserDidInteractWithPage(bool). > Source/WebCore/page/EventHandler.cpp:3153 > + // Delay updating document flag indicating the user has interacted with the page until the KeyUp so we do not > + // treat keyboard shortcuts such as CMD+R / CMD+Q as user interaction with the page. It's odd to special case Q and R. There are other user actions that we don't treat as interaction with the page -- such as Cmd-L to focus the location field and change location. I think it would be better to use the set of all key combinations that Safari treats as special. (In reply to Geoffrey Garen from comment #17) > It's odd to special case Q and R. Ricky reminded me that this patch just implements the logic to wait for keyUp, not to select any specific keystrokes. (I noticed that the first time I read this patch, and then forgot. :( ) Created attachment 306961 [details]
Patch
Created attachment 306995 [details]
WIP Patch
Created attachment 307037 [details]
Patch
New (more reliable) approached based on Sam's suggestion. We now only treat as user interaction with the page key events that were actually handled. Comment on attachment 307037 [details] Patch Attachment 307037 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/3531085 New failing tests: fast/events/beforeunload-alert-handled-keydown.html Created attachment 307057 [details]
Archive of layout-test-results from ews121 for ios-simulator-wk2
The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews121 Port: ios-simulator-wk2 Platform: Mac OS X 10.11.6
Created attachment 307060 [details]
Patch
Comment on attachment 307060 [details]
Patch
Nice. r=me
Comment on attachment 307060 [details] Patch Clearing flags on attachment: 307060 Committed r215404: <http://trac.webkit.org/changeset/215404> All reviewed patches have been landed. Closing bug. |