We can get rid of this inclusion thanks to the new d&d API, i'll make this depend on single bugs about getting rid of the dependencies we have. Currently: - Places - search.xml - browser and tabbrowser files the only things we can't replace atm are nsDragAndDrop.dragDropSecurityCheck and transferUtils. The former ideally should be done automatically by the D&D API since it seems sensible, otherwise we could move it to an util file. The latter is an util with just one method, can easily be moved, maybe to contentAreaUtils?
other things inside nsDragAndDrop: - nsTransferable is a wrapper for nsITransferable, used in nsClipboard.js - FlavourSet is used only in Places, will get rid of it - transferUtils is used in search.xml and tabbrowser.xml
Places part is done (apart bug 545121), remaining work is waiting for bug 545714 that should make easier to implement bug 545125.
Created attachment 443390 [details] [diff] [review] removes the last vestiges of nsDragAndDrop.js
Comment on attachment 443390 [details] [diff] [review] removes the last vestiges of nsDragAndDrop.js >diff --git a/browser/base/content/tabbrowser.xml b/browser/base/content/tabbrowser.xml Can you expose canDropLink on browserDragAndDrop and use it in _setEffectAllowedForDataTransfer, and then get rid of _supportedLinkDropTypes entirely? >diff --git a/browser/base/content/test/browser_drag.js b/browser/base/content/test/browser_drag.js >+ tab1.control.selectedItem = tab1; gBrowser.selectedTab = tab1 would be clearer, no?
Created attachment 445366 [details] [diff] [review] removes the last vestiges of nsDragAndDrop.js version 2 Like so?
Comment on attachment 445366 [details] [diff] [review] removes the last vestiges of nsDragAndDrop.js version 2 >diff --git a/browser/base/content/tabbrowser.xml b/browser/base/content/tabbrowser.xml >+ if (!dt.types.contains("text/x-moz-text-internal") && Is there any harm in allowing this one? It is handled by drop(), right?
Created attachment 447527 [details] [diff] [review] address comment