1408756 - Can't drag and drop html elements in extension Options page in Firefox with out-of-process WebExtensions

Status: NEW

(WebExtensions :: Frontend, defect, P3)

Description

[Daniel]

Attachment: Settings Drag - WebExtension.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170926190823

Steps to reproduce:

I created a WebExtension with an options page, where I use drag events to let the user reorder a list of items. In Firefox 55 and before it worked, but from 56 on (including 57 beta), only the drag start event triggers, rendering drag impossible. This happens even if "open_in_tab" is set to true, so being on a different page doesn't seem to matter.

I've attached a WebExtensions project that shows the problem. It does use a third party library for drag events, Sortable.js, but you should be able to see what is happening regardless. It has a console.log for each event.

On Firefox 56 or 57 beta:
1. Install the extension, "Settings Drag - WebExtension", via about:debugging.
2. Open Debug for it.
3. Open the settings page.
4. Try dragging the 3 items. You should only see a print for drag start. The items will not move.


Actual results:

On Firefox and 57 beta, only start drag events are sent. Cannot move items that implement drag and drop.


Expected results:

Items should be draggable as normal, as happens in Firefox 55.

Comment 1

[Jasmin Bom [:jsmnbom]]

Cannot reproduce using
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Buildid: 20171013042429

Console output
> onStart <li style="" draggable="true" class="sortable-chosen sortable-ghost">
> onUpdate <li style="" draggable="false" class="">
> onEnd <li style="" draggable="false" class="">

Comment 2

[Daniel]

(In reply to bomjacob from comment #1)
> Cannot reproduce using
> Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101
> Firefox/57.0
> Buildid: 20171013042429
> 
> Console output
> > onStart <li style="" draggable="true" class="sortable-chosen sortable-ghost">
> > onUpdate <li style="" draggable="false" class="">
> > onEnd <li style="" draggable="false" class="">

Thank you for checking. Did you try with or without "open_in_tab": true?

I just tested it here (Win 10 x64, Firefox Developer Edition 57.0b8) and it seems I made a partial mistake in my original report. Yes, I can never get it to work if open_in_tab is not present (it isn't in my attached project), but it DOES work if open_in_tab is true (I said it didn't). HOWEVER, and this is what caused my mistake, if you then remove open_in_tab from the manifest and reload (case where drag doesn't work), and then try with open_in_tab: true again and reload, it won't work anymore.

Could you please tell me if you were using "open_in_tab"? Firefox tells me my build is up to date.

Comment 4

[Jasmin Bom [:jsmnbom]]

Even using "open_in_tab": true (which opens up moz-extension://{extension_id}/settings/settings.html) I can't reproduce.
I also tried setting it to true then opening options (it works)
then setting it to false and pressing reload in the about:debugging manager (still works)
and reloading the moz-extension page (still seems to work)
and then pressing options in the addons manager which opens it inline (also works)

I also tried the other way around (having it false then setting to true). The fact that this bug has a dupe probably means that it indeed a bug, but it's a bit concerning that I'm unable to reproduce it.

Comment 5

[bibicron]

A detail that maybe will help.
In case of "Selections Context Search" add-on, if I start dragging rows, the cursor will not even change to the drag-and-drop cursor.
Also as I mentioned, only the dragstart event is fired.

Comment 6

[Daniel]

It really is strange that it's not reproducible in some cases. I hadn't noticed the duplicate question, unfortunately. It says it's resolved. Does anyone know in what upcoming version?

Indeed, the cursor not changing is what also something that happens to me in the project I attached.

Comment 7

[Daniel]

Or is it "resolved" because this one has additional details? Apologies if that's the case. I'm new to the platform. :)

Comment 8

[Daniel]

Does someone have any idea why this happens? Possible workarounds? Especially since it doesn't seem to happen to everyone.

Because of this, users of my extension "Swift Selection Search" can't reorder their search engines by dragging, but only by using up and down buttons, which is slow and far from ideal. :(

Comment 9

[Neil Bird]

OK, yes, just hit this myself for my add on (https://addons.mozilla.org/en-US/firefox/addon/url-link/versions/beta?page=1#version-3.1.0beta4 / https://github.com/fnxweb/urllink).

Thought I was being dense somewhere.

I can reiterate all the findings here:  drag and drop doesn't work for “embedded” options pages, *does* work for “open_in_tab” options pages, & *doesn't* work if you have *ever* had that option set to false or not present in the manifest.json.

I can't yet determine whether moving from open_in_tab = false → true can be made to work by restarting Firefox as I've only been able to play with that via load-temporary-addon, in which case you have to uninstall/reinstall to make it work, reload doesn't cut it.


Two points of note:  I have deliberately made my preferences page work “stand-alone” so I could dev. the drag/etc. functionality outside of the extension (so if you unpack my XPI or checkout my repo, you can just load preferences.html).  That *always* works.

The other point, which may be more useful, is:  I have determined (for me, anyway) that everything works swimmingly on Linux, which is where I dev'd it.  There are no problems having an “embedded” options page using drag.

However, on Windows, while the stand-alone page works, and the options page as a new tab works (notwithstanding the reload issue), the “embedded” options page misbehaves as described above:  only the drag event is triggered, and then it seemingly stops with no other events (no dragover, dragenter or even dragend [not tried dragexit which I think is a legacy XUL event].


On Linux I've had 56, 57-dev and 57-formal work fine on Fedora 26 [64-bit, RPM and Mozilla bundles], and 57 on CentOS 7 [a 64-bit VM, Mozilla bundle].  These are all fine.

I've now tested Win10 [32-bit, in a VM] and Windows 7 [64-bit, native], both using the Mozilla 32-bit 57 bundle (en-GB) and both of these fail as above.

I guess there is a chance at this point that it's not Windows but the fact that it's a 32-bit build that's the problem, but I'd err on the side of Windows being the factor.

I'm going to push my extension with the open_in_tab for now and hope existing users don't have to uninstall/reinstall but only restart ...

Comment 10

[Neil Bird]

OK, verified that the open_in_tab options, erm, option *does* work around the problem, *BUT* you need to restart Firefox after updating the extension via AMO in order to “unbreak” it.  This does fortunately mean that users don't have to uninstall and reinstall the extension (thereby possibly losing their settings).

Comment 11

[Neil Bird]

Minor addendum to the above:  users don't always need to restart Firefox after updating an add-on that moves to using open_in_tab;  I suspect it works OK if they've not tried to open the preferences window within the current session when the add-on gets updated, and that the breakage occurs when the options page is actually opened “embedded”.

Comment 12

[Daniel]

Thanks for the detailed extra info, Neil! I'd like to add that I was (and am) using the 64 bit version of Firefox. I've never tried it on other OSs. It's curious that it works on Linux, though.

Comment 13

[Rob Wu [:robwu]]

Attachment: dropbug-options_ui-1408756.zip

Reproduced on Linux too, when I set extensions.webextensions.remote to true.
STR:
1. Visit about:config and set the extensions.webextensions.remote flag to false (on Windows, this defaults to true).
2. Load the attached extension at about:debugging.
3. Visit about:addons and click on the Preferences button.
4. Drag the top box to the second box.

5. Visit about:config and set the extensions.webextensions.remote flag to true.
6. Disable and re-enable the extension at about:addons.
7. Drag the top box to the second box.

Expected result:
- After step 4, both boxes should become green (=dragend and drop event fired).
- After step 7, both boxes should become green (=dragend and drop event fired).

Actual result:
- Step 4 behaves as expected.
- Step 7 fails: the color of the boxes do not change (=drag and drop events not fired).

Comment 14

[Rob Wu [:robwu]]

This gets even weirder.. I strongly suspect that some bookkeeping in the main (parent) process went wrong:

(i) When this bug is triggered, drag and drop is broken for all other pages in the same (extension) process. Since multiple extensions share this process, drag and drop is broken for all add-ons.

(ii) When a new drag operation is initiated, and the data is dropped (e.g. dragging the URL from the awesomebar to the tab strip to open a new tab), then the "dragend" event is fired in the embedded options page, even though the two drag operations are completely independent.


The following STR demonstrates these bugs using the attached extension from comment 13:
- steps 1-7 shows bugs (i)
- steps 1, 2, 6-9 shows bug (ii)

1. Visit about:config and set the extensions.webextensions.remote flag to true.
2. Load the extension from comment 13 at about:debugging.
3. Visit about:addons, click on Extensions and click on the Preferences button.
4. Click on the "Open same page in a new tab (for comparison)" link (in the options page).

5. In the moz-extension://.../options.html page that opens, drag the top box to the second box (this works as expected).

6. In the about:addons page, drag the top box to the second box (this fails, as shown in comment 13).

7. Refresh the page at step 5 (so that the boxes are not green any more) and repeat step 5 (i.e. drag and drop).

    FAIL: The boxes should be green, but they are not.

8. Open data:text/html,<textarea>xxx in a new tab, select the content of the textarea and drag and drop it to the same text area.
9. Look at the page from step 6.

   UNEXPECTED: The top box is green (= dragend event was fired because of step 8)

Comment 15

[Rob Wu [:robwu]]

Follow-up to comment 14:
(i) is caused by the fact that there may only be one "drag session", which is enforced by EventStateManager::DoDefaultDragStart at https://searchfox.org/mozilla-central/rev/6e96a3f1e44e286ddae5fdafab737709741d237a/dom/events/EventStateManager.cpp#2056

(ii) is caused by the fact that the end of a drag session is broadcast to all child processes by nsBaseDragService::EndDragSession at https://searchfox.org/mozilla-central/rev/6e96a3f1e44e286ddae5fdafab737709741d237a/widget/nsBaseDragService.cpp#437


This last EndDragSession is invoked by nsDragService::RunScheduledTask, which is scheduled via nsDragService::Schedule.
When I put a breakpoint in the main process, it is never triggered when I initiate a drag from the embedded options page.
In contrast,  it is triggered when I drag from the extension page in a tab (i.e. step 5 from comment 14):
- drag_motion_event_cb at https://searchfox.org/mozilla-central/rev/6e96a3f1e44e286ddae5fdafab737709741d237a/widget/gtk/nsWindow.cpp#6037
  (this would be responsible for drag events)
- invisibleSourceDragEnd at https://searchfox.org/mozilla-central/rev/6e96a3f1e44e286ddae5fdafab737709741d237a/widget/gtk/nsDragService.cpp#1741
  (this is responsible for the JS "dragend" event - the end of the "drag session").


Now, the question is why these signals are not observed when the drag is initiated from a remote embedded options page (<browser>).


To debug a local build:
Prepare:
1. mach run --debug --setpref extensions.webextensions.remote=true about:addons
2. Visit about:debugging and load the extension from comment 13.
3. Click on the "Extensions" panel at about:debugging, then the "Preferences" button to open the embedded options page.
4. Click on the "Open same page in a new tab (for comparison)" link in the options page

Debugging the broken case:
5. In the embedded options page at about:addons, drag the top box to the bottom box. (=reproduce bug)
6. Select and drag the name of the add-on at about:addons ("Name "), and release the mouse to terminate the stuck drag session. (=manual work-around)
7. Repeat step 3 to reset the color. (=reset test case)

Debugging the working case:
5. In the options page in the new tab, drag the top box to the bottom box.
6. Before reproducing step 5, reload the page (=reset test case)



For ease of reproduction, instead of reloading the page, you can also add a button to the options page that clears the color:

var resetter = document.createElement('button');
resetter.textContent = 'Reset colors';
resetter.onclick = function() { dndme.style.backgroundColor = drophere.style.backgroundColor = ''; };
document.body.appendChild(resetter);