User Agent: Mozilla/5.0 (Windows NT 6.3; Trident/7.0; Touch; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; Tablet PC 2.0; InfoPath.3; BRI/2; MDDRJS; rv:11.0) like Gecko Steps to reproduce: On touchscreen drag to scroll is broken

Reproduced on Nightly 33.0a1 2014-06-29 using an Ultrabook with Win 8 64-bit.

Daniel: when you say "touchscreen drag to scroll is broken", does it not scrolling it all? Or does it scroll but incorrectly?

(In reply to Chris Peterson (:cpeterson) from comment #2) > Daniel: when you say "touchscreen drag to scroll is broken", does it not > scrolling it all? Or does it scroll but incorrectly? Instead of scrolling, the text your finger is above just gets selected.

Move old M2 P3 bugs to M4 (because tracking-e10s=m5+ flag doesn't exist yet).

Reproduced 35.0a1 (2014-09-14) - MS Surface Pro (1) - Windows 8.1 Pro/64Bit Cannot use touch to scroll either on main pane or using scrollbar.

downgrading, this can wait until m5.

This bug is very annoying. I'm disabling e10s in the meanwhile.

Hi, I'm on 37.0a1 (2014-12-25)64-bit, on 64-bit Windows 8.1. I've noticed that scrolling works properly when using two fingers instead of just one.

I'm unable to test electrolysis on several of my systems until this is fixed, but I'm struggling to find info on what/when these milestones are, so that I know when to jump back in. Does M2.3 from here (https://wiki.mozilla.org/Electrolysis/Roadmap) = M5? And which of those milestones is the current one?

(In reply to voracity from comment #10) > I'm unable to test electrolysis on several of my systems until this is > fixed, but I'm struggling to find info on what/when these milestones are, so > that I know when to jump back in. Does M2.3 from here > (https://wiki.mozilla.org/Electrolysis/Roadmap) = M5? And which of those > milestones is the current one? I've just updated https://wiki.mozilla.org/Electrolysis and https://wiki.mozilla.org/Electrolysis/Roadmap with a current set of milestones.

This is mostly there, except I need a more reliable way of triggering calls to UpdateParentScrollInfo.

This is a work around to get touch scroll working with e10s. It's not clear if we'll ever have the data to fix this right but Apz frame metrics data and touch region data might be useful down the road.

Comment on attachment 8562057 [details] [diff] [review] patch > bool displayPanFeedback = false; > for (nsIFrame* current = targetFrame; current; > current = nsLayoutUtils::GetCrossDocParentFrame(current)) { > >+ // e10s - mark remote content as draggable. Not draggable. Pannable perhaps? in this method there is "If that's the case, the current touch gesture * will be used as a pan gesture; otherwise it will be a regular * mousedown/mousemove/click event." so I assume that comment is just bogus, since we certainly don't want to prevent mousedown/move/click events. Can't test that. Please do test.

(In reply to Olli Pettay [:smaug] from comment #14) > in this method there is > "If that's the case, the current touch gesture > * will be used as a pan gesture; otherwise it will be a regular > * mousedown/mousemove/click event." > > so I assume that comment is just bogus, since we certainly don't want to > prevent mousedown/move/click events. > Can't test that. Please do test. True statement really, just a little misleading. When detected by the gesture module a pan gesture will get converted. But things that aren't considered panning (like finger taps) are handled independently. So you can click and pan with these changes. But you can't simulate a mouse down, mouse drag, and mouse up. We can live with that.

Verified using Nihglty 39.0a1 2015-03-09 on an Ultrabook with Win 8 64-bit. Notes: - The scrolling is working on e10s windows, but it seems to be less smoothly than in regular window. - Having a regular window and an e10s window side by side, scrolling in the regular window and then directly in the e10s window will cause both windows content to scroll. I will add a screencast if this is not already logged in bugzilla. This may not be related to e10s, I will investigate more tomorrow.

(In reply to Petruta Rasa [QA] [:petruta] from comment #20) > Verified using Nightly 39.0a1 2015-03-09 on an Ultrabook with Win 8 64-bit. > > Notes: - The scrolling is working on e10s windows, but it seems to be less > smoothly than in regular window. Should I file a new bug for this? > - Having a regular window and an e10s window side by side, scrolling in the > regular window and then directly in the e10s window will cause both windows > content to scroll. I will add a screencast if this is not already logged in > bugzilla. This may not be related to e10s, I will investigate more tomorrow. It seems that this issue reproduces back to Firefox 27.0.1, so it's not recent and not related to e10s. I will check to see if it's already logged.

(In reply to Petruta Rasa [QA] [:petruta] from comment #21) > (In reply to Petruta Rasa [QA] [:petruta] from comment #20) > > Verified using Nightly 39.0a1 2015-03-09 on an Ultrabook with Win 8 64-bit. > > > > Notes: - The scrolling is working on e10s windows, but it seems to be less > > smoothly than in regular window. > > Should I file a new bug for this? Sure. I noticed we don't async scroll have you remove your finger after a fling. That might be the bug the poster's referring to. > > - Having a regular window and an e10s window side by side, scrolling in the > > regular window and then directly in the e10s window will cause both windows > > content to scroll. I will add a screencast if this is not already logged in > > bugzilla. This may not be related to e10s, I will investigate more tomorrow. > > It seems that this issue reproduces back to Firefox 27.0.1, so it's not > recent and not related to e10s. I will check to see if it's already logged. Definitely needs filing.

Thanks Jim! I'm marking this issue as verified based on above comments.

Version: 40.0a1(2015-04-09) Scrollbars should always be draggable, but it didn't.