[Webkit-unassigned] [Bug 218462] REGRESSION(r261570): [GTK] Drag of unknown type aborted on motion above WebView under X11

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Nov 4 08:32:53 PST 2020


https://bugs.webkit.org/show_bug.cgi?id=218462

--- Comment #2 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(In reply to Milan Crha from comment #1)
> The below backtrace is coming from the DropTarget constructor. If I
> understand it correctly, then the mouse cursor motion creates another
> WebView (because webkit asked for the selection data during the motion),

OK wow, so Evolution needs to create a new webview to get the selection data (for whatever reason)? And we wind up with two different DropTargets both receiving the drop and interfering with each other...?

> for
> which Evolution prints the message. I do not think WebKit should ask the
> data during the drag operation, it should ask it only on the drop operation.

Are you sure? Requesting drag data early to decide whether to accept it is allowed by GTK. (What's not really allowed is our delayed async acceptance, which could be causing problems....)

> There is a comment in the sources:
>     // WebCore needs the selection data to decide, so we need to preload the
>     // data of targets we support. Once all data requests are done we start
>     // notifying the web process about the DND events.
> 
> With respect of the notifications, you need to provide status of the drag,
> thus remove:
> 
>     if (operation == m_operation)
>         return;
> 
> from void DropTarget::didPerformAction().

Hm, does that fix the bug? If so, then let's do it. Otherwise, I'm not so sure it's really needed to update the status of the drag to be the same as it was before? GTK expects us to do the update unconditionally, but it also expects us to do so before our drag-data-received callback returns, which we don't do.

This function should probably be renamed to avoid confusion. here would be good, because didPerformAction is not called where you would expect. It's called when the web process asyncronously responds to *every* drag operation (entered, updated, exited), not just the final action.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201104/afaeaf6e/attachment-0001.htm>


More information about the webkit-unassigned mailing list