Steps To Reproduce: 1. Open http://xxsionxx.blog17.fc2.com/ 2. Scroll down to the middle of page 3. Attempt to scroll element at the left side of page mouse over scrollbar and turn mouse wheel 4. Attempt to scroll the other element mouse over scrollbar and turn mouse wheel 5. Repeat step4 Actual Results: Sometomes not scroll the element. It seems transaction scroll timeout is broken Expected Results: these element should scroll properly

Force enabled APZ and e10s, first broken pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c3376e427908&tochange=1b0655f6b110 Regressed by:bug 1147223

[Tracking Requested - why for this release]:

Tracking because regression and affects usability of FF.

I can reproduce this on Windows 8.1. A quick investigation seems to indicate badness with the event regions resulting in bad hit-testing in the compositor. I need to do a debug build to investigate further.

Note that there's a not-yet-landed event regions fix in bug 1177018 (the Part 2 patch); you may want to test with that applied before digging in.

Hm, I rebuilt with that patch applied and it seems to make the situation worse :( It's kind of intermittent to begin with though so it's hard to tell.

Test case breaks 100% of the time for me, so it looks like bug 1177018 did not affect this particular issue. It looks similar though. When the page first loads there is a single PaintedLayer covering the content, with individual d-t-c regions for each nested scrollframe. If any of these scrollframes is scrolled, the subframe is layerized, and a new invisible layer appears in front of the other content layers. This invisible layer has a hit region for the entire content area, but is missing a d-t-c region for the now-active subframe. If the wheel transaction ends, the scrollframe can no longer scroll. Attempting to scroll other subframes will similarly work once, and then stop forever, since the d-t-c region is removed and the invisible layer is stealing events. So it looks like either the invisible layer, or the hit region, or both are a bug in layout.

Based on the above description the next step is probably to reproduce with the prefs layout.display-list.dump and layers.dump-decision set to true. That will tell us which display items are going into this invisible layer and hopefully that should be sufficient information to determine what the root cause is.

When we add event regions for an inactive scrollframe, we do so by placing a new nsDisplayLayerEventRegions on top of our existing items. The intent is this item only carries a d-t-c region for the frame. However, the constructor for nsDisplayLayerEventRegions adds the rest of the frame as a hit region. This region may end up overlapping other content, causing the item to get pushed into its own layer, which then incorrectly eats up APZ events.

This patch removes AddFrame() from the nsDisplayLayerEventRegions constructor. AddInactiveSubframe now adds the scrollport as a hit region instead, and other callsites use AddFrame() manually.

David, is APZ enabled in 42 (and 43) by default? I wonder if we should uplift that or not. Thanks

umm, I can still reproduce the problem on latest m-c tinderbox build and latest m-i tinderbox build . I do not think this is fixed. https://hg.mozilla.org/mozilla-central/rev/d01dd42e654b8735d86f9e7c723cc869a3b56798 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 ID:20151009024347 https://hg.mozilla.org/integration/mozilla-inbound/rev/3188b162ee535793e8a7d8072937bec76f12475f Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 ID:20151009035448

(In reply to Alice0775 White from comment #16) > umm, > I can still reproduce the problem on latest m-c tinderbox build and latest > m-i tinderbox build . > I do not think this is fixed. > > https://hg.mozilla.org/mozilla-central/rev/ > d01dd42e654b8735d86f9e7c723cc869a3b56798 > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 > ID:20151009024347 > > https://hg.mozilla.org/integration/mozilla-inbound/rev/ > 3188b162ee535793e8a7d8072937bec76f12475f > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 > ID:20151009035448 Anyway, I've filed Bug 1213324.

(In reply to Sylvestre Ledru [:sylvestre] from comment #15) > David, is APZ enabled in 42 (and 43) by default? I wonder if we should > uplift that or not. > Thanks No it's still nightly-only.

OK, thanks. Updating the tracking flags accordingly.