Opened 2 years ago

Closed 2 years ago

Last modified 22 months ago

#22434 closed defect (worksforme)

drag and drop filter is ineffective in e10s mode

Reported by: cypherpunks Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff52-esr, tbb-e10s, tbb-7.0-issues, tbb-regression
Cc: brade, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When press and move the scroll-bar

[05-29 18:33:33] Torbutton INFO: The DataTransfer is available

Child Tickets

Change History (8)

comment:1 Changed 2 years ago by gk

Status: newneeds_information

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?

comment:2 Changed 2 years ago by cypherpunks

Status: needs_informationnew

Are you starters? O_o
It's your dran'n'drop patch which is triggered by every mouse move with left button down, because it's incompatible with e10s.

comment:3 Changed 2 years ago by gk

Resolution: not a bug
Status: newclosed

on-datatransfer-available is 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.

comment:4 Changed 2 years ago by cypherpunks

No comments.

comment:5 Changed 2 years ago by mcs

Cc: brade mcs added
Keywords: tbb-7.0-issues tbb-regression added
Resolution: not a bug
Status: closedreopened
Summary: Your patch is broken on e10sdrag and drop filter is ineffective in e10s mode

I am reopening this bug. Kathy and I encountered this issue while working on #22471 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-available filter 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)

comment:6 Changed 2 years ago by mcs

Resolution: worksforme
Status: reopenedclosed

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-available mechanism. 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.

comment:7 in reply to:  6 Changed 2 years ago by gk

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-available mechanism. 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 :) )?

comment:8 Changed 22 months ago by cypherpunks

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@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:932:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:813:7
this.PromiseWalker.scheduleWalkerLoop/<@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:747:11
 1 nsContextMenu.js:576
Note: See TracTickets for help on using tickets.