1683376 - Tab detach without translucency and having the ghost image match the tab design

Status: NEW

(Firefox :: Theme, enhancement, P5)

Description

[Jared Wein [:jaws] (please needinfo? me)]

As part of the Proton work, we should change the tab detach ghost image to remove the translucency and style the ghost image to match the tab design.

Comment 1

[Neil Deakin]

I'm commenting here from a question asked elsewhere:

Since I don't see any other info, I'm assuming the bug here is to make the drag feedback image match what the tab looks like, or is there some other look it is supposed to follow?

You can make the dragged image whatever you want using a canvas if needed using setDragImage. Removing the transparency is the bigger hurdle here.

Windows is the least flexible for this. The feedback image is drawn by a system component that applies a translucent gradient to whatever image we supply, but as far as I know, there is no means to change this appearance.

I believe Mac also applies a default translucency above the one specified by the DRAG_TRANSLUCENCY constant.

The main solution would be to add a mechanism that draws and moves a native widget(window) around following the mouse pointer, and doesn't necessarily use the native drag and drop api (or at least not entirely). A partial implementation of this exists using a <panel> element, but it doesn't work with multiple monitors with different resolutions. We probably should do this for tab dragging anyway, as it isn't really the same sort of dragging behaviour as others. But it would require quite a bit of platform-specific work.

On Linux, we follow a different codepath for tab dragging where we use a <panel> for the drag feedback like I mentioned earlier, and it does allow you to change the transparency and works on multiple screens.

Comment 2

[Micah [:mtigley] (she/her)]

(In reply to Neil Deakin from comment #1)

The main solution would be to add a mechanism that draws and moves a native widget(window) around following the mouse pointer, and doesn't necessarily use the native drag and drop api (or at least not entirely). A partial implementation of this exists using a <panel> element, but it doesn't work with multiple monitors with different resolutions. We probably should do this for tab dragging anyway, as it isn't really the same sort of dragging behaviour as others. But it would require quite a bit of platform-specific work.

On Linux, we follow a different codepath for tab dragging where we use a <panel> for the drag feedback as I mentioned earlier, and it does allow you to change the transparency and works on multiple screens.

From what I gathered, this means we don't have platform-specific support to have dragging the <panel> element work on multiple screens for Windows and Mac and we should try to implement the support for this (just as it does on Linux). It isn't obvious to me where it differs on Linux so that it works on multiple screens. Would you be able to point out where/why that might be?

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

From what I understand, we can drag panels across screens on Windows and Mac but we run in to issues with different screen DPIs. @micah, for your work I think we could try to ignore it, and then fix the multiple monitors issues afterwards. Potentially we could disable the <panel> code if we can't fix the multiple monitors issues and detect that the user has multiple monitors.

Comment 4

[Neil Deakin]

GTK has an API which lets one specify a widget for the drag feedback image. We use this to pass the underlying native widget for the panel and GTK does all of the work for us. Other platforms don't have this and only support fixed images, so we need to draw and move the panel around ourselves. A <panel> always uses the same DPI as the window it came from so moving the panel to another screen will use the DPI and other settings from the window still on the first screen.

One option is to create a hidden window with a panel in it that gets moved around.

Alternatively, we could use a top-level window instead of a panel. For this, we would need to change nsBaseDragService::OpenDragPopup to open a window instead and nsBaseDragService::DragMoved to move the window when the drag position changes.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Hmm, does InitializeFromWindow allow us to use a widget, and in that case does windows still apply the translucency there? (Not sure, just asking)

Comment 6

[Neil Deakin]

I believe that InitializeFromWindow only differs in that the bitmap image is sourced from a message sent to that window rather than supplying the image directly. It doesn't render the contents of the window as the drag image, and still applies the transparency. I haven't actually tested it though.

Comment 7

[Romain Testard [:RT]]

I'm marking as a P5 since it's not blocking Proton, we'll review priority as we get closer to Proton ship date and have capacity to address it.

Comment 8

[Blake Winton (:bwinton) (:☕️)]

As per guidance from Vicky, for tracking, we're marking all the bugs that people are working on as P1.

Comment 9

[Blake Winton (:bwinton) (:☕️)]

Whoops, sorry, didn't see Romain's message. Moving back to a P5, and un-assigning Micah, since it's not a priority. 🙂