Closed Bug 1315245 Opened 6 years ago Closed 4 years ago

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

Categories

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

52 Branch
x86_64
Windows 10
defect

Tracking

()

RESOLVED FIXED
mozilla53
Tracking Status
firefox53 --- fixed

People

(Reporter: asimonca, Assigned: stone)

References

Details

Attachments

(3 files, 3 obsolete files)

[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".
Priority: -- → P3
Assignee: nobody → sshih
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.
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.
Attachment #8818461 - Flags: review?(bugs)
Attachment #8818462 - Flags: review?(bugs)
Attachment #8818461 - Flags: review?(bugs) → review+
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.
Attachment #8818462 - Flags: review?(bugs) → review-
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
Attachment #8818462 - Attachment is obsolete: true
Attachment #8818773 - Flags: feedback?(bugs)
aha, probably not safe to change that. Ok, rather unusual setup here, but not worth to block this bug because of that.
Attachment #8818773 - Flags: feedback?(bugs) → feedback-
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()
Attachment #8818462 - Flags: review- → review+
Keywords: checkin-needed
Pushed by ryanvm@gmail.com:
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
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/42954e822c47
https://hg.mozilla.org/mozilla-central/rev/0b69c1a656b3
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
I guess this will ride the train
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
Hi Stone,
Could you take a look at this, too?
Flags: needinfo?(sshih)
Sure.
Flags: needinfo?(sshih)
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?
Flags: needinfo?(sshih)
Either way is fine with me. Thanks.
Flags: needinfo?(sshih)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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?
Flags: needinfo?(alexandru.simonca)
(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.
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.
Flags: needinfo?(alexandru.simonca)
(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.
Does this mean that the issue is site specific? Does it only happen on this site?
Flags: needinfo?(sshih)
(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.
Flags: needinfo?(sshih)
Status: REOPENED → RESOLVED
Closed: 6 years ago4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.