WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
202418
MouseEvent altKey property only changes on dragStart
https://bugs.webkit.org/show_bug.cgi?id=202418
Summary
MouseEvent altKey property only changes on dragStart
Jay C
Reported
2019-10-01 12:03:54 PDT
Created
attachment 379924
[details]
Screen recording of problem Safari Version 13.0.1 macOS Version 10.14.6 (18G95) While dragging a draggable element, `event.altKey` should change to true/false depending if I hold the option key on my Mac. In Firefox, I can start a drag, and then toggle the option key to see the altKey value change from false to true. I do not need to have the option key pressed before I start dragging. In Safari, I have to start the drag operation with option already held down in order for the MouseEvent's altKey property to be true. If I let go of the option key, the altKey value never changes. In Safari, if I start a drag event without holding the option key down, the MouseEvent's altKey property will never change. Here is a video logging out the value of altKey as I dragEnter and dragOver the items on the left. The item I am dragging has the following in its dragStart handler ``` e.dataTransfer.effectAllowed = 'copyMove' e.dataTransfer.dropEffect = 'move' ``` the item I am dropping on has the following events. e.altKey will *always* be false in webkit if I don't start the drag operation with option held down. It will *always* be true if I start the drag operation with option held down. ``` function dropHandler(e) { e.preventDefault() e.dataTransfer.effectAllowed = 'copyMove' ... // If we're copying if (e.altKey) { fieldCopyHandler(oldDocumentId, thisDocumentId, fieldId) } else { fieldMoveHandler(oldDocumentId, thisDocumentId, fieldId) } } function dragEnterHandler(e) { console.log(e.altKey) } function dragOverHandler(e) { console.log(e.altKey) } ``` I have attached a video
Attachments
Screen recording of problem
(34.95 MB, video/quicktime)
2019-10-01 12:03 PDT
,
Jay C
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Jay C
Comment 1
2019-10-01 12:12:52 PDT
I wrote out a long bug report when submitting this, but not seeing that text here so I will rewrite it (ugh). Problem: The MouseEvent's "altKey" property doesn't change when pressing/releasing the option key. Example: I have a set of list items that I can drag and drop, and another set of list items that can handle a drop. in the drag start handler for the items I can drag, I have set the dataTransfer effectAllowed value to "copyMove". in the drop Handler, dragEnter handler, and dragOver handler on the droppable list items, I am logging out the altKey property. If I start the drag operation with the option key held down, the altKey property will always be true, no matter if I release the key or not. If I start the drag operation without the option key held down, the altKey property will always be false, no matter what I do. I have attached a screen recording showing Firefox vs Safari
Radar WebKit Bug Importer
Comment 2
2019-10-02 08:03:56 PDT
<
rdar://problem/55909813
>
Jay C
Comment 3
2019-10-02 09:10:53 PDT
This may be related to
https://bugs.webkit.org/show_bug.cgi?id=101853
as I am seeing that as well with the same dropevent
Stefano Delli Ponti
Comment 4
2020-04-01 05:58:47 PDT
I confirm this bug also in Safari 13.1 and macOS 10.15.4. The problem has been present in Safari for at least three years, perhaps more. Unfortunately I don't remember the first version where it appeared, but I am sure it was not present at the beginning. Both Chrome and Firefox allow to discover the values of the modifier keys after starting dragging, keeping them updated if changed later. I think that a workaround can be to query the dataTransfer.effectAllowed, which is changed dynamically when toggling ctrl, alt or meta. Unfortunately I didn't find a way to query for the shiftKey status.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug