Rendering problem in Nightly with touch screen

VERIFIED FIXED in mozilla52

Status

()

defect
P1
normal
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: hans.brouwer, Unassigned)

Tracking

({regression})

49 Branch
mozilla52
Unspecified
Windows
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s+)

Details

(Whiteboard: steps in comment 2, gfx-noted, aes+, tpi:+, )

Reporter

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160407164938

Steps to reproduce:

I'm using Firefox 46.0.1

I went to the website : http://turnjs.com/#samples/steve-jobs/18
(Turn js flipbook). When you try to turn a page it doesn't show the content properly. 

I tried this in Firefox 45.0.2 on an other computer and it is working fine.
After upgrading this instance of 45.0.2 to 46.0.1 it shows the same issue as on my own computer. 
Downgrading my own computer to 45.0.2 solves the issue.


Actual results:

While turning the pages it shows the lowest z-index object


Expected results:

While turning the pages show the uppermost z-index object.

Comment 1

3 years ago
I think it's already fixed in Aurora/Nightly.

Could you download Aurora and confirm on your side, please.
https://www.mozilla.org/en-US/firefox/developer/all/
Flags: needinfo?(hans.brouwer)
Reporter

Comment 2

3 years ago
I did, and indeed the "rendering" problem is solved in release 48.0a2 (2016-05-12).
However an other problem shows up with the touch interface. 
Some swiping feature is reacting in a different way compared to 45.0.2

Steps to reproduce:
1) Goto website: http://95.85.48.168/books.html
2) Open the book to page 2 (tap on the right handside of the book)
3) Drag the upper right (or bottom right) corner to another position. The corner should follow your finger movement. 

In 45.0.2 it does, in 48.0a2 it doesn't.

This only applies to touch screens, not to mouse movements.

Comment 3

3 years ago
So there is probably a regression in 48 (or even in 47) with touch screens.
As I don't own a computer with a touch screen, could you download the tool Mozregression to find a regression range, please.
See http://mozilla.github.io/mozregression/ for details.

You can run the command "mozregression --good=45".
When you get the final pushlog, paste it here.

Comment 4

3 years ago
As the OP has issues about running Mozregression (due to Chinese firewall), I'll CC someone from QA with a touch screen to test the issue from comment #2 with Firefox 48 and 49.
Flags: needinfo?(hans.brouwer) → needinfo?(petruta.rasa)
Summary: Rendering problem in Firefox 46.0.1 → Rendering problem in Firefox 46.0.1 with touch screen
I could only reproduce this in 49.0a1 2016-05-17 under a Microsoft Surface Pro 2 with Windows 10 64-bit.
Dragging works as expected when http://95.85.48.168/books.html is opened with a clean profile. The issue reproduces only after restarting the browser. Afterwards, dragging the book corners will have no effect.

48.0a2 2016-05-17 doesn't have the issue.
Blocks: 1180706
Status: UNCONFIRMED → NEW
Component: Untriaged → Panning and Zooming
Ever confirmed: true
Flags: needinfo?(petruta.rasa)
Product: Firefox → Core
Whiteboard: steps in comment 2
Version: 46 Branch → 49 Branch
Forgot to mention that the regression range points to bug 1180706.
Summary: Rendering problem in Firefox 46.0.1 with touch screen → Rendering problem in Nightly with touch screen
Flags: needinfo?(bugmail.mozilla)
Whiteboard: steps in comment 2 → steps in comment 2, gfx-noted
So on FF 47 beta, I see the following behaviour:
e10s disabled -> works
e10s enabled, APZ disabled -> doesn't work
e10s enabled, APZ enabled, no APZ touch support -> doesn't work
e10s enabled, APZ enabled, APZ touch support -> works

So it seems like e10s broke touch event support, and until we enable APZ touch support (via dom.w3c_touch_events.enabled) it stays broken. In the e10s disable case, however, touch events aren't actually getting delivered to the content, they are getting converted to mouse events. So what e10s actually broke is the conversion of touch inputs to mouse events.
tracking-e10s: --- → ?
Component: Panning and Zooming → Widget: Win32
Flags: needinfo?(bugmail.mozilla)
(The good news here is that on touchscreen device, e10s is disabled by default because of the accessibility code, so in theory this shouldn't be a big problem)

Updated

3 years ago
Priority: -- → P1
Target Milestone: --- → mozilla50
just hooking this up someplace where it won't get lost. This impacts Windows touch screen users once they get e10s.
Blocks: e10sa11y2

Updated

3 years ago
OS: Unspecified → Windows
Whiteboard: steps in comment 2, gfx-noted → steps in comment 2, gfx-noted, aes+
Hey kats, is there a tracking bug for remaining apz + dom.w3c_touch_events.enabled work?
Flags: needinfo?(bugmail.mozilla)
Bug 1244402 is what we're using to track it.
Flags: needinfo?(bugmail.mozilla)

Updated

3 years ago
Blocks: 1244402
This behaves fine on Nightly if e10s is enabled, because then you get APZ and touch events as well. Inverting dependency, as this needs the touch events to ride the trains before it will be fixed in release.
No longer blocks: 1244402, 1180706
Depends on: 1244402, 1180706
Whiteboard: steps in comment 2, gfx-noted, aes+ → steps in comment 2, gfx-noted, aes+, tpi:+
Now that touch events are riding the trains I'm going to call this fixed in 52. Note that e10s still needs to be enabled in 52 to get proper touch events support.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: mozilla50 → mozilla52
Verified using Nightly 52.0a1 2016-11-13 under Microsoft Surface PRO Win 10 64-bit, e10s on; the book pages on http://95.85.48.168/books.html can be dragged.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.