drag and drop filter is ineffective in e10s mode
When press and move the scroll-bar
[05-29 18:33:33] Torbutton INFO: The DataTransfer is availableActivity
Could you be a bit more verbose? For starters it would be good to know which patch you are talking about. Then what exactly does not work anymore would be good to know as well. Finally, which operating system and which Tor Browser are you using? How can we reproduce your problem?
Trac:
Status: new to needs_information-
on-datatransfer-availableis fired by Mozilla's code, we are just observing it. If you think Mozilla should not fire that one, please open a bug at https://bugzilla.mozilla.org/. And mouse move while left button down is the classical definition for dragging things. So, it seems to me we don't break anything here.Trac:
Status: new to closed
Resolution: N/A to not a bug 
I am reopening this bug. Kathy and I encountered this issue while working on #22471 (moved) and the other tickets related to the download warning prompt (we had to move the drag and drop filter into its own component within Torbutton, and encountered this bug while testing our changes).
I have not done any investigation to determine the root cause, but our
on-datatransfer-availablefilter is not effective when e10s is enabled. I reproduced this problem using Tor Browser 7.0.2 on OSX 10.12.5. Here is a page that may be used to demonstrate the problem: https://pearlcrescent.com/tor/22434.html (JS required)Trac:
Summary: Your patch is broken on e10s to drag and drop filter is ineffective in e10s mode
Keywords: N/A deleted, tbb-7.0-issues, tbb-regression added
Status: closed to reopened
Resolution: not a bug to N/A
Cc: N/A to brade, mcs-
It seems that this is not really a problem, even though the behavior is confusing when electrolysis is enabled.
Testing by dragging from Tor Browser to another application shows that our filtering is effective in Tor Browser 7.x (Kathy and I tested by dragging from Tor Browser to Firefox). So there is not a potential proxy leak.
The confusing part is that when electrolysis is enabled, the drag filter does not affect the data that stays within the browser (e.g., if you drag between two Tor Browser windows). The content process must have its own copy of the transfer data which is not subject to filtering via the
on-datatransfer-availablemechanism. I think this is okay (although arguably it is an upsteam bug), so I am going to close this ticket again. Please reopen if you disagree.Trac:
Status: reopened to closed
Resolution: N/A to worksforme -
Replying to mcs:
It seems that this is not really a problem, even though the behavior is confusing when electrolysis is enabled.
Testing by dragging from Tor Browser to another application shows that our filtering is effective in Tor Browser 7.x (Kathy and I tested by dragging from Tor Browser to Firefox). So there is not a potential proxy leak.
The confusing part is that when electrolysis is enabled, the drag filter does not affect the data that stays within the browser (e.g., if you drag between two Tor Browser windows). The content process must have its own copy of the transfer data which is not subject to filtering via the
on-datatransfer-availablemechanism. I think this is okay (although arguably it is an upsteam bug), so I am going to close this ticket again. Please reopen if you disagree.Thanks, re upstream bug: do you think it is worth filing one (and if so would you mind doing so :) )?
DevTools are also not happy with this Mozilla bug:
20:13:00.240 A promise chain failed to handle a rejection. Did you forget to '.catch', or did you forget to 'return'? See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise Date: Thu Aug 31 2017 20:12:51 GMT+0000 (UTC) Full Message: TypeError: inspector.selection is undefined Full Stack: nsContextMenu.prototype.inspectNode/<@chrome://browser/content/nsContextMenu.js:576:11 Handler.prototype.process@re[/gre/modules/Promise.jsm](/gre/modules/Promise.jsm) -> re[/gre/modules/Promise-backend.js:932:23](/gre/modules/Promise-backend.js:932:23) this.PromiseWalker.walkerLoop@re[/gre/modules/Promise.jsm](/gre/modules/Promise.jsm) -> re[/gre/modules/Promise-backend.js:813:7](/gre/modules/Promise-backend.js:813:7) this.PromiseWalker.scheduleWalkerLoop/<@re[/gre/modules/Promise.jsm](/gre/modules/Promise.jsm) -> re[/gre/modules/Promise-backend.js:747:11](/gre/modules/Promise-backend.js:747:11) 1 nsContextMenu.js:576mentioned in issue #22618 (moved)