Bugzilla

(In reply to Mike Conley (:mconley) (:⚙️) from comment #5)
> A workaround for this is to press "Escape" to end the drag operation, which should put the browser back into an interactive state.
> 
> Hey Marco, I presume it's expected that we open the Bookmarks _menu_ when dragging a tab, right? Presumably, we need to be ending the drag session if the user hasn't finished the drag properly... do you know whereabouts in the codebase we'd need to do that?

Yes, it's expected that we open menus when the user is hovering them, and once the operation is complete the menu should stay open to show the newly inserted item, the menu should also close on a timer if the user drags out of it.
On Windows everything works exactly like that, just tested it.
And according to comment 2 it also works correctly with widget.gtk.grab-pointer = 0.

I think the problem here is in the DnD code that handles the drag session and how it interacts with FVWM and widget.gtk.grab-pointer.

(In reply to Mike Conley (:mconley) (:⚙️) from comment #5)
> A workaround for this is to press "Escape" to end the drag operation, which should put the browser back into an interactive state.
> 
> Hey Marco, I presume it's expected that we open the Bookmarks _menu_ when dragging a tab, right? Presumably, we need to be ending the drag session if the user hasn't finished the drag properly... do you know whereabouts in the codebase we'd need to do that?

Yes, it's expected that we open certain menus when the user is hovering them, and once the operation is complete the menu should stay open to show the newly inserted item, the menu should also close on a timer if the user drags out of it.
On Windows everything works exactly like that, just tested it.
And according to comment 2 it also works correctly with widget.gtk.grab-pointer = 0.

I think the problem here is in the DnD code that handles the drag session and how it interacts with FVWM and widget.gtk.grab-pointer.