1159665 - [e10s] Drag-and-drop of tabs not working in content frame script

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[dw-dev]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150305021524

Steps to reproduce:

I am the developer of the 'Tile Tabs' and 'Tile View' add-ons.  Both these add-ons allow a tab to be Shift+Dragged over the contents of another tab, causing the tabs to be tiled side-by-side.  [Note: Both add-ons call event.preventDefault() to avoid the dragged tab being detached from the tab bar].

Current versions of both add-ons handle the drag-and-drop operations in the chrome process, but for e10s windows it would be better handle the 'dragover' and 'drop' events in a frame script in the content process.

However, this is not possible at present, because when a tab (A) is dragged over the contents of another tab (B), the 'dragover' event is only fired if tab (B) is the first tab (initial tab) in the browser.


Actual results:

The 'dragover' event is fired when a tab is dragged over the contents of the first tab in the browser, but not when dragged over the contents of other tabs in the browser.


Expected results:

The 'dragover' event should be fired when a tab is dragged over the contents of any tab in the browser.

Comment 1

[Dave Townsend [:mossop]]

(In reply to dw-dev from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101
> Firefox/36.0
> Build ID: 20150305021524
> 
> Steps to reproduce:
> 
> I am the developer of the 'Tile Tabs' and 'Tile View' add-ons.  Both these
> add-ons allow a tab to be Shift+Dragged over the contents of another tab,
> causing the tabs to be tiled side-by-side.  [Note: Both add-ons call
> event.preventDefault() to avoid the dragged tab being detached from the tab
> bar].
> 
> Current versions of both add-ons handle the drag-and-drop operations in the
> chrome process, but for e10s windows it would be better handle the
> 'dragover' and 'drop' events in a frame script in the content process.

Why is that?

> However, this is not possible at present, because when a tab (A) is dragged
> over the contents of another tab (B), the 'dragover' event is only fired if
> tab (B) is the first tab (initial tab) in the browser.
> 
> 
> Actual results:
> 
> The 'dragover' event is fired when a tab is dragged over the contents of the
> first tab in the browser, but not when dragged over the contents of other
> tabs in the browser.

Can you provide some example code that demonstrates what you're seeing?

Comment 2

[Dave Townsend [:mossop]]

Waiting on a reply from the reporter here.

Comment 3

[dw-dev]

> User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101
> Firefox/36.0
> Build ID: 20150305021524
> 
> Steps to reproduce:
> 
> I am the developer of the 'Tile Tabs' and 'Tile View' add-ons.  Both these
> add-ons allow a tab to be Shift+Dragged over the contents of another tab,
> causing the tabs to be tiled side-by-side.  [Note: Both add-ons call
> event.preventDefault() to avoid the dragged tab being detached from the tab
> bar].
> 
> Current versions of both add-ons handle the drag-and-drop operations in the
> chrome process, but for e10s windows it would be better handle the
> 'dragover' and 'drop' events in a frame script in the content process.

>Why is that?

Sorry for the delay in replying.

When I reported this problem, I was in the middle of updating my 'Tile Tabs' and 'Tile View' add-ons to be fully compatible with the e10s drag-and-drop functionality implemented in Bug 936092.

A feature of these add-ons is that you can Shift+Drag a tab (A) over the contents of another tab (B) to tile tab A next to tab B.  Similarly, you can Ctrl+Drag a tab (A) over the contents of another tab (B) to load the URI of tab A into tab B.

I had an idea that I might be able to simplify the code in Tile Tabs and Tile View by handling these drag-and-drop operations (into a tab's content area) entirely within a frame script in the content process.  I was testing a prototype of this idea when I discovered the problem that I have reported.

Since then, I have realized that it is still best to handle these particular drag-and-drop operations in the chrome process (whilst still avoiding CPOW's).  This means the problem I have reported is no longer a blocker for Tile Tabs and Tile View, but it is still an inconsistency in the Firefox drag-and-drop implementation.


> However, this is not possible at present, because when a tab (A) is dragged
> over the contents of another tab (B), the 'dragover' event is only fired if
> tab (B) is the first tab (initial tab) in the browser.
> 
> 
> Actual results:
> 
> The 'dragover' event is fired when a tab is dragged over the contents of the
> first tab in the browser, but not when dragged over the contents of other
> tabs in the browser.

>Can you provide some example code that demonstrates what you're seeing?

It is not the easiest thing to demonstrate, because normally when you drag a tab it detaches from the tab bar.

Please find attached 'TileTabs-Bug1159665-Demo.xpi', which is a stripped down variant of Tile Tabs containing only the code that is necessary to allow Ctrl+Drag of a tab button onto another tab's contents.

Follow these steps to reproduce the reported problem:

1. Start e10s Firefox.
2. Install 'TileTabs-Bug1159665-Demo.xpi'.
3. Open two new tabs (B & C) in addition to the initial tab (A).
4. Select tab A.
5. Ctrl+Drag tab B (or tab C) onto the contents of tab A and drop.  You should see an alert popup displaying "Drop".
6. Select tab B.
7. Ctrl+Drag tab A (or tab C) onto the contents of tab B and drop. Nothing happens.  The drop event is not fired!

I don't understand why the behaviour with tab A selected is different to the behaviour with tab B selected.

Comment 4

[dw-dev]

Attachment: TileTabs Bug 1159665 Demo add-on (incorrect type)

Comment 5

[dw-dev]

Correction point 7 in Comment 3:

7. Ctrl+Drag tab A (or tab C) onto the contents of tab B and drop.  Tab A (or tab C) detaches from the tab bar.  The drop event is not fired in the content process!

Comment 6

[dw-dev]

Attachment: TileTabs Bug 1159665 Demo add-on

Comment 7

[Jim Mathies [:jimm]]

So have you solved this in your addon? I t sounds like you have and we can resolve this invalid.

Comment 8

[Jim Mathies [:jimm]]

Smaug, would you mind looking this over to see if we're potentially missing important drag events here?

Comment 9

[dw-dev]

This problem is no longer a blocker for my Tile Tabs and Tile View add-ons, because I have now implemented their drag-and-drop operations entirely in the chrome process, not in the content process.

So, with regards to my Tile Tabs and Tile View add-ons, as far as I am concerned this bug can be closed.

However, the problem I reported, which can be reproduced using the attached demo add-on (TileTabs-Bug1159665-Demo.xpi), is still an inconsistency in the Firefox drag-and-drop implementation.

Comment 10

[dindog]

I am using a userchrome.js that listen to the drag & drop of link and text of content page.
And I find that the script will break because Firefox won't detect "drop" event, if the e10s is enabled.
Other event like "dragstart", "dragover","dragend","drag" is fine.

Should I file an new issue or it's a duplicate of this bug?

Comment 11

[dindog]

(In reply to dindog from comment #10)
> I am using a userchrome.js that listen to the drag & drop of link and text
> of content page.
> And I find that the script will break because Firefox won't detect "drop"
> event, if the e10s is enabled.
> Other event like "dragstart", "dragover","dragend","drag" is fine.
> 
> Should I file an new issue or it's a duplicate of this bug?
I can reproduce my problem with a simple html testpage, so I filed anyway. If it's an duplicate, please closed it.
Bug 1181043

Comment 12

[Tracy Walker [:tracy]]

(In reply to dw-dev from comment #9)

> So, with regards to my Tile Tabs and Tile View add-ons, as far as I am
> concerned this bug can be closed.

marking fixed per the reporter/add-on developers comment