1315245 - The text on www.addtext.com can't be moved if Pointer Events is preffed on

Status: RESOLVED FIXED

(Core :: DOM: Events, defect, P3)

Description

[Alexandru Simonca [:asimonca], Release Desktop QA]

[Affected versions]:
- Firefox Nightly 52.0a1

[Affected platforms]:
- Windows 10 x64

[Steps to reproduce]:
Make sure that the build has e10s enabled. If not, go to about:config and right-click -> new -> boolean to add the pref "browser.tabs.remote.force-enable" and set it to "true".
1. Go to about:config and search for the pref "dom.w3c_pointer_events.enabled" and set it to "true".
2. Go to www.addtext.com 
3. Load a picture by "drag and drop" and move the text saying "Your text here".

[Expected result]:
- The text can be moved anywhere on the surface of the picture.

[Actual result]:
- The text can not be moved.

[Regression range]:
- This is not a regression since this feature is new.

[Additional notes]:
- This only happens when the pref "dom.w3c_pointer_events.enabled" is set to "true". The text can be moved if the pref is set to "false".

Comment 1

[Alexandru Simonca [:asimonca], Release Desktop QA]

Attachment: bug addtext 3.mp4

Comment 2

[Ming-Chou Shih [:stone]]

Attachment: Part1: Don't dispatch event to AccessibleCaretEventHub when the event status is nsEventStatus_eConsumeNoDefault

Stop dispatching the event to AccessibleCaretEventHub when it's defaultPrevented. It's happened when the user calls preventDefault on ePointerDown, we also set the subsequent mouse events as defaultPrevented until the button is released.

Comment 3

[Ming-Chou Shih [:stone]]

Attachment: Part2: StopTrackingDragGesture when preventDefault is called

Comment 4

[Ming-Chou Shih [:stone]]

This website calls preventDefault on pointerdown to suppress the subsequent mouse events. Current implementations only stop firing mouse events to content so the mousedown will trigger drag gesture. Stop processing drag gesture when the mousedown is defaultPrevented could fix it.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8818462 [details] [diff] [review]
Part2: StopTrackingDragGesture when preventDefault is called

This looks odd. Why isn't 
*aStatus == nsEventStatus_eConsumeNoDefault if default is prevented.
This hints like a bug elsewhere.

Please explain.

Comment 6

[Ming-Chou Shih [:stone]]

Attachment: Part2: Don't reset nsEventStatus in EventStateManager::PreHandleEvent

Our current implementations reset nsEventStatus to nsEventStatus_eIgnore in EventStateManager::PreHandleEvent. Checked [1] and looks like it's not intentional. Wondering if it's safe to remove it?

[1] http://searchfox.org/mozilla-central/diff/77fd9c26528b17225462de745340ea35442e0431/content/events/src/nsEventStateManager.cpp#70

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

aha, probably not safe to change that. Ok, rather unusual setup here, but not worth to block this bug because of that.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8818462 [details] [diff] [review]
Part2: StopTrackingDragGesture when preventDefault is called

Could you add a comment here why we need to check both 
nsEventStatus_eConsumeNoDefault != *aStatus and !aEvent->DefaultPrevented()

Comment 9

[Ming-Chou Shih [:stone]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3225537291ad7fc1004d849a2bfced1ed76dc72b

Comment 10

[Ming-Chou Shih [:stone]]

Attachment: Part1: Don't dispatch event to AccessibleCaretEventHub when the event status is nsEventStatus_eConsumeNoDefault

Updated the patch summary

Comment 11

[Ming-Chou Shih [:stone]]

Attachment: Part2: StopTrackingDragGesture when preventDefault is called.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/42954e822c47
Part 1: Don't dispatch event to AccessibleCaretEventHub when the event status is nsEventStatus_eConsumeNoDefault. r=smaug
https://hg.mozilla.org/integration/mozilla-inbound/rev/0b69c1a656b3
Part 2: StopTrackingDragGesture when preventDefault is called. r=smaug

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/42954e822c47
https://hg.mozilla.org/mozilla-central/rev/0b69c1a656b3

Comment 14

[Sylvestre Ledru [:Sylvestre]]

I guess this will ride the train

Comment 15

[Alexandru Simonca [:asimonca], Release Desktop QA]

Hi,
This issue just started reproducing on Ubuntu with the same repro steps, on Nightly 55.0a1. Should I file another bug?

User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID 	20170515100238

Comment 16

[Alexandru Simonca [:asimonca], Release Desktop QA]

Hi Stone,
Could you take a look at this, too?

Comment 17

[Ming-Chou Shih [:stone]]

Sure.

Comment 18

[Alexandru Simonca [:asimonca], Release Desktop QA]

Hello,
This issue just started reproducing using the same STR when using touch on Windows 10 x64 in the latest Nightly build. Should I reopen this bug or log another one?

Comment 19

[Ming-Chou Shih [:stone]]

Either way is fine with me. Thanks.

Comment 20

[Ming-Chou Shih [:stone]]

(In reply to Alexandru Simonca, QA (:asimonca) from comment #18)
> Hello,
> This issue just started reproducing using the same STR when using touch on
> Windows 10 x64 in the latest Nightly build. Should I reopen this bug or log
> another one?

I also can't drag the text with touch on chrome. Could you help to confirm it?

Comment 21

[Ming-Chou Shih [:stone]]

(In reply to Ming-Chou Shih [:stone] from comment #20)
> (In reply to Alexandru Simonca, QA (:asimonca) from comment #18)
> > Hello,
> > This issue just started reproducing using the same STR when using touch on
> > Windows 10 x64 in the latest Nightly build. Should I reopen this bug or log
> > another one?
> 
> I also can't drag the text with touch on chrome. Could you help to confirm
> it?

Tested with Edge and it also behaves the same.

Comment 22

[Alexandru Simonca [:asimonca], Release Desktop QA]

Hi, 
I have just tested this again with Chrome and Edge. Moving the text doesn't work on Chrome but DOES work on Edge, for me. I tested it on a Windows 10 x64 Surface 4.

Comment 23

[Ming-Chou Shih [:stone]]

(In reply to Alexandru Simonca, QA (:asimonca) from comment #22)
> Hi, 
> I have just tested this again with Chrome and Edge. Moving the text doesn't
> work on Chrome but DOES work on Edge, for me. I tested it on a Windows 10
> x64 Surface 4.

Analyzed the js code of the website and found that this is related to the touch event listener. The touch event listener of the content stops the drag functionality. On Edge, touch event API is disabled by default so the drag functionality works. I had my laptop configured with touch event API enabled on Edge, that's why I can't drag the text. Please let me know if any questions. Thanks.

Comment 24

[Alexandru Simonca [:asimonca], Release Desktop QA]

Does this mean that the issue is site specific? Does it only happen on this site?

Comment 25

[Ming-Chou Shih [:stone]]

(In reply to Alexandru Simonca, QA (:asimonca) from comment #24)
> Does this mean that the issue is site specific? Does it only happen on this
> site?

I think it is.