1910452 - Drag-and-drop should be considered in content analysis

Status: RESOLVED FIXED

(Firefox :: Data Loss Prevention, task)

Description

[David Parks [:handyman]]

This is a new bug to continue the work in bug 1871222, which we moved away from for bookkeeping reasons.

Comment 1

[David Parks [:handyman]]

Attachment: Bug 1910452: Test drag and drop with content analysis r=#dlp-reviewers!

The mock situation is such that we reuse a lot of the static ContentAnalysis
class behavior involved in drag and drop here. We only need to block some
methods and mock AnalyzeRemoteDropEvent.

This test is very similar to browser_dragdrop.js -- it just adds content
analysis to that test.

Comment 2

[David Parks [:handyman]]

Attachment: Bug 1910452: Intercept drop events for content analysis r=smaug!,#dlp-reviewers!

Sends OOP drop events to content analysis for approval before sending them to
the DOM. This first happens in EventStateManager::DispatchCrossProcessEvent,
where we detect the potential need for content analysis (and present a modal
dialog on the tab). The drag session then ends as usual in the parent process
but remains open on the related widget in the process where it would be sent to
the DOM while the drop is being analyzed. The child process will send either
CancelAnalyzeDropEvent, if CA isn't needed, or AnalyzeDropEvent, if it is. On
AnalyzeDropEvent, CA will respond by sending ContentAnalysisDropResult back to
the child with the verdict, which will result in either a drop event (on
approval) or dragLeave (otherwise). Calls to EndDragSession are delayed during
this.

Comment 3

[David Parks [:handyman]]

Attachment: Bug 1910452: Part 1 - Intercept drop events for content analysis r=smaug!,#dlp-reviewers!

Sends OOP drop events to content analysis for approval before sending them to
the DOM. It intercepts drop events at the browser level and sends them to CA
before calling stopPropagation and preventDefault on them. (CA also presents a
modal dialog over the tab.) The drag session then ends as usual in the parent
process but remains open on the related browser in the process where it would be
sent to the DOM while the drop is being analyzed. While CA runs, the browser
dispatches an eQueryDropTargetHittest event to locate the drop target while the
event screen coordinates are still valid. When CA is complete, a drop or
dragLeave event is sent to the drop target (dragLeave if the drop was not
approved by CA). Calls to EndDragSession are delayed during this.

Comment 4

[David Parks [:handyman]]

Attachment: Bug 1910452: Part 2 - Test that drag-drop respects content analysis r=#dlp-reviewers!

This reuses parts of the dom/events test to test that content analysis is
consulted and respected for in-browser drags with drops in the same frame and
between frames/windows with same or different origin.

Comment 5

[David Parks [:handyman]]

Attachment: Bug 1910452: Part 3 - Fix some issues with synthesizeMockDragAndDrop r=m_kato!

This fixes four issues:

1. The test didn't provide enough movement to generate a drag session on the
   source before moving to the target. This meant that, when they were in
   different windows, Gecko wouldn't send dragleave to the source or dragenter
   to the target. It also never sent dragenter to the source in the first
   place. This remedies that.
2. dragenter and dragleave weren't properly handled because the test was sending
   dragleaves instead of dragexits (the latter being what Gecko expects and the
   former being synthesized from that -- see e.g. nsNativeDragTarget::DragLeave).
   This now uses dragexits and sets the proper expectations.
3. expectProtectedDataTransferAccess was needlessly complicated and, after #1,
   gave the wrong answers for some events like dragenter called on the source.
4. The event handler wasn't checking for exceptions and the drop handler was
   intentionally causing one, which was causing it to miss the rest of its
   execution.

Comment 6

[David Parks [:handyman]]

Attachment: Bug 1910452: Part 4 - Wait for iframe to load in drag and drop tests r=m_kato!

This was causing "AbortError: Actor 'SpecialPowers' destroyed before query
'Spawn' was resolved" failures.

Comment 7

[David Parks [:handyman]]

Attachment: Bug 1910452: Part 5 - Release content analysis cache request on main thread r=#dlp-reviewers!

Without this, we assert when releasing the request on the background thread when
we hit an error, such as the DLP agent not running.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/db9d1823ea80
Part 1 - Intercept drop events for content analysis r=smaug,dlp-reviewers,gstoll,reusable-components-reviewers,mstriemer
https://hg.mozilla.org/integration/autoland/rev/778a6530fceb
Part 2 - Test that drag-drop respects content analysis r=dlp-reviewers,gstoll
https://hg.mozilla.org/integration/autoland/rev/f50209dd351a
Part 3 - Fix some issues with synthesizeMockDragAndDrop r=m_kato
https://hg.mozilla.org/integration/autoland/rev/b3503e3442a2
Part 4 - Wait for iframe to load in drag and drop tests r=m_kato
https://hg.mozilla.org/integration/autoland/rev/48d0e3a22a05
Part 5 - Release content analysis cache request on main thread r=dlp-reviewers,gstoll

Comment 10

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/db9d1823ea80
https://hg.mozilla.org/mozilla-central/rev/778a6530fceb
https://hg.mozilla.org/mozilla-central/rev/f50209dd351a
https://hg.mozilla.org/mozilla-central/rev/b3503e3442a2
https://hg.mozilla.org/mozilla-central/rev/48d0e3a22a05

Comment 11

[Greg Stoll :gstoll]

Attachment: Bug 1910452: Part 1 - Intercept drop events for content analysis r=smaug!,#dlp-reviewers!

Sends OOP drop events to content analysis for approval before sending them to
the DOM. It intercepts drop events at the browser level and sends them to CA
before calling stopPropagation and preventDefault on them. (CA also presents a
modal dialog over the tab.) The drag session then ends as usual in the parent
process but remains open on the related browser in the process where it would be
sent to the DOM while the drop is being analyzed. While CA runs, the browser
dispatches an eQueryDropTargetHittest event to locate the drop target while the
event screen coordinates are still valid. When CA is complete, a drop or
dragexit event is sent to the drop target (drop if it was approved by CA). Calls
to EndDragSession are delayed during this.

Original Revision: https://phabricator.services.mozilla.com/D219201

Comment 12

[Greg Stoll :gstoll]

Attachment: Bug 1910452: Part 2 - Test that drag-drop respects content analysis r=#dlp-reviewers!

This reuses parts of the dom/events test to test that content analysis is
consulted and respected for in-browser drags with drops in the same frame and
between frames/windows with same or different origin.

Original Revision: https://phabricator.services.mozilla.com/D219549

Comment 13

[Greg Stoll :gstoll]

Attachment: Bug 1910452: Part 3 - Fix some issues with synthesizeMockDragAndDrop r=m_kato!

This fixes four issues:

1. The test didn't provide enough movement to generate a drag session on the
   source before moving to the target. This meant that, when they were in
   different windows, Gecko wouldn't send dragleave to the source or dragenter
   to the target. It also never sent dragenter to the source in the first
   place. This remedies that.
2. dragenter and dragleave weren't properly handled because the test was sending
   dragleaves instead of dragexits (the latter being what Gecko expects and the
   former being synthesized from that -- see e.g. nsNativeDragTarget::DragLeave).
   This now uses dragexits and sets the proper expectations.
3. expectProtectedDataTransferAccess was needlessly complicated and, after #1,
   gave the wrong answers for some events like dragenter called on the source.
4. The event handler wasn't checking for exceptions and the drop handler was
   intentionally causing one, which was causing it to miss the rest of its
   execution.

Original Revision: https://phabricator.services.mozilla.com/D219550

Comment 14

[Greg Stoll :gstoll]

Attachment: Bug 1910452: Part 4 - Wait for iframe to load in drag and drop tests r=m_kato!

This was causing "AbortError: Actor 'SpecialPowers' destroyed before query
'Spawn' was resolved" failures.

Original Revision: https://phabricator.services.mozilla.com/D219551

Comment 15

[Greg Stoll :gstoll]

Attachment: Bug 1910452: Part 5 - Release content analysis cache request on main thread r=#dlp-reviewers!

Without this, we assert when releasing the request on the background thread when
we hit an error, such as the DLP agent not running.

Original Revision: https://phabricator.services.mozilla.com/D220617

Comment 16

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: DLP won't cover drag and drop interception point
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: (QA team has a detailed test plan for this feature)
• Risk associated with taking this patch: medium
• Explanation of risk level: there are a few known regressions, but the only bad ones for non-DLP reasons will be uplifted as well
• String changes made/needed: no
• Is Android affected?: no

Comment 17

[Greg Stoll :gstoll]

Attachment: Bug 1910452: Part 1 - Intercept drop events for content analysis

Sends OOP drop events to content analysis for approval before sending them to
the DOM. It intercepts drop events at the browser level and sends them to CA
before calling stopPropagation and preventDefault on them. (CA also presents a
modal dialog over the tab.) The drag session then ends as usual in the parent
process but remains open on the related browser in the process where it would be
sent to the DOM while the drop is being analyzed. While CA runs, the browser
dispatches an eQueryDropTargetHittest event to locate the drop target while the
event screen coordinates are still valid. When CA is complete, a drop or
dragexit event is sent to the drop target (drop if it was approved by CA). Calls
to EndDragSession are delayed during this.

Comment 18

[Greg Stoll :gstoll]

Attachment: Bug 1910452: Part 2 - Test that drag-drop respects content analysis

This reuses parts of the dom/events test to test that content analysis is
consulted and respected for in-browser drags with drops in the same frame and
between frames/windows with same or different origin.

Original Revision: https://phabricator.services.mozilla.com/D219549

Comment 19

[Greg Stoll :gstoll]

Attachment: Bug 1910452: Part 3 - Fix some issues with synthesizeMockDragAndDrop

This fixes four issues:

1. The test didn't provide enough movement to generate a drag session on the
   source before moving to the target. This meant that, when they were in
   different windows, Gecko wouldn't send dragleave to the source or dragenter
   to the target. It also never sent dragenter to the source in the first
   place. This remedies that.
2. dragenter and dragleave weren't properly handled because the test was sending
   dragleaves instead of dragexits (the latter being what Gecko expects and the
   former being synthesized from that -- see e.g. nsNativeDragTarget::DragLeave).
   This now uses dragexits and sets the proper expectations.
3. expectProtectedDataTransferAccess was needlessly complicated and, after #1,
   gave the wrong answers for some events like dragenter called on the source.
4. The event handler wasn't checking for exceptions and the drop handler was
   intentionally causing one, which was causing it to miss the rest of its
   execution.

Original Revision: https://phabricator.services.mozilla.com/D219550

Comment 20

[Greg Stoll :gstoll]

Attachment: Bug 1910452: Part 4 - Wait for iframe to load in drag and drop tests

This was causing "AbortError: Actor 'SpecialPowers' destroyed before query
'Spawn' was resolved" failures.

Original Revision: https://phabricator.services.mozilla.com/D219551

Comment 21

[Greg Stoll :gstoll]

Attachment: Bug 1910452: Part 5 - Release content analysis cache request on main thread

Without this, we assert when releasing the request on the background thread when
we hit an error, such as the DLP agent not running.

Original Revision: https://phabricator.services.mozilla.com/D220617

Comment 22

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: DLP won't cover drag and drop interception point
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: (QA team has a detailed test plan for this feature)
• Risk associated with taking this patch: medium
• Explanation of risk level: there are a few known regressions, but the only bad ones for non-DLP reasons will be uplifted as well
• String changes made/needed: no
• Is Android affected?: no

Comment 23

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/befe8321772d
https://hg.mozilla.org/releases/mozilla-esr128/rev/726fb6cadff4
https://hg.mozilla.org/releases/mozilla-esr128/rev/39c1eb7dfc59
https://hg.mozilla.org/releases/mozilla-esr128/rev/a3334fe3774d
https://hg.mozilla.org/releases/mozilla-esr128/rev/4869c672edfa