Fanolian Reporter
	Description • 9 years ago

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20150907030206

Steps to reproduce:

0. It is e10s only. OPTIONAL: disable smooth scrolling at about:preferences#advanced to maximise the effect.
1. In a new profile, load http://www.developertown.com/hamburger-menu/ . Switch to another tab (any tab can do).
2. Cautiously move the mouse into content window without hovering on any links.
3. Scroll up or down once using mouse wheel.


Actual results:

The newly displayed area flashes on first scroll. Subsequent scrolls do not flash until I switch tab and back.


Expected results:

No flashes.

Note:
1. If I hover on a link before first scroll, there will be no flashing.
2. With smooth scrolling on, the affected area is much smaller.
3. There is no flashing if I open the link in a non-e10s window.
4. I cannot seem to reproduce it by scrolling with scrollbar or keyboard.


Last good Nightly: 2015-08-23
First bad Nightly: 2015-08-24

Last good revision: 22c34579ae0720e7d3dc39a22b9d33f13bc0198b
First bad revision: 8a6045d14d6bd348a3b5bfeb55a9321e680cc93e
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=22c34579ae0720e7d3dc39a22b9d33f13bc0198b&tochange=8a6045d14d6bd348a3b5bfeb55a9321e680cc93e

Inbound:
Last good revision: 44034f41ef1cf911c6629c9fd8f9c8bad1bf9eaa
First bad revision: 35f538038395489cafccbdfe18f0f86d682d8e9d
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=44034f41ef1cf911c6629c9fd8f9c8bad1bf9eaa&tochange=35f538038395489cafccbdfe18f0f86d682d8e9d


Other affected links:
https://forum-en.guildwars2.com/forum
https://brendaneich.com/2013/05/c-is-for-cookie/ , which is found in a similar issue Bug 873124.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 1 • 9 years ago

Fanolian, thanks for finding the regression window, that helps a lot!

BenWa, can you look into this? We're probably doing a full repaint when we shouldn't be, or something.

	Benoit Girard (:BenWa) Assignee
	Comment 2 • 9 years ago

This is because we suppress the displayport and we don't trigger a repaint after.

The problem is worse on windows because we don't have pad out the display port at all. On mac we pad it to tiles so even if we suppress it, we can usually paint on time because we have a tiny displayport.

We've talked about aligning the windows displayport to (virtual) tiles. Doing this would also fix this bug.

We could make unsuppressing the displayport trigger a repaint to fill the displayport but this means that we can trigger a costly paint when the user is cycling tabs. I'd rather go with aligning.

	Benoit Girard (:BenWa) Assignee
	Comment 3 • 9 years ago

(In reply to Benoit Girard (:BenWa) from comment #2)
> We've talked about aligning the windows displayport to (virtual) tiles.
> Doing this would also fix this bug.

The more I think about this one, the more I think just have a bit of padding to the next 'tile' wouldn't be enough to fix this. But it would help a bit.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 4 • 8 years ago

Are you still able to reproduce this on Nightly? We've made a number of optimizations/fixes since this bug was filed and it might no longer be an issue.

	Fanolian Reporter
	Comment 5 • 8 years ago

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #4)
> Are you still able to reproduce this on Nightly? We've made a number of
> optimizations/fixes since this bug was filed and it might no longer be an
> issue.

I can still reproduce it occasionally in Nightly, but only on some specific regions.
I cannot tell how to determine an affected region. It is now down to trial-and-error rather than, IIRC, reliably reproducible at most regions when I first reported the problem.

Attached is a new video showing the issue on current Nightly.
I have since upgraded to Windows 10 with latest drivers using the same hardware as the initial report.

	Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]]
	Comment 6 • 8 years ago

I've managed to reproduce this on the latest Aurora build(46.0a2) on Windows 8.1 x64. This only reproduces with e10s enabled.

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160208004010

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 7 • 8 years ago

I can reproduce the grey bar appearing, and if I enable the apz.minimap.enabled pref, I can see that this is checkerboarding (the blue box goes outside the green box). However, for me, it only happens for a brief period and then it paints correctly. In the video it looks like the checkerboarding remains permanently, until something triggers a repaint; that shouldn't be happening and is a pretty bad bug.

Fanolian, can you enable the apz.minimap.enabled pref and take another video? I want to make sure that the problem you're seeing is the same that I am seeing. Once you reproduce it, please also go to about:checkerboard, find the checkerboard report that corresponds to the issue (you'll have to check the timestamps), click on it, copy the raw log from the textarea at the bottom of the page, and attach it to this bug. That will give us a little more information (specifically the requested displayport values) which might tell us why the displayport doesn't move with the scroll. Thanks!

	Fanolian Reporter
	Comment 8 • 8 years ago

I can no longer reproduce the permanent checkerboarding even if I use the same build and scroll at the exact region, or very near it. Actually that was also my first time encountering such a bad behavior so I recorded that. Perhaps I didn't eliminate other factors, like restarting my computer before testing and recording.


Below is the raw log of the very first scroll, i.e. scrolling up at https://forum-en.guildwars2.com/forum where the permanent was supposed to be, in the attached video:

RENDERTRACE 1868.17 rect brown 0 0 1199 2481 // page
RENDERTRACE 1868.17 rect lightgreen 0 896 1199 1024 // painted displayport
RENDERTRACE 1883.09 rect red 0 912 1199 795 // viewport
RENDERTRACE 1884.77 rect brown 0 0 1199 2481 // page
RENDERTRACE 1884.77 rect lightgreen 0 896 1199 1024 // painted displayport
RENDERTRACE 1899.84 rect red 0 912 1199 795 // viewport
RENDERTRACE 1901.52 rect brown 0 0 1199 2481 // page
RENDERTRACE 1901.52 rect lightgreen 0 896 1199 1024 // painted displayport
RENDERTRACE 1916.57 rect red 0 912 1199 795 // viewport
RENDERTRACE 1918.32 rect brown 0 0 1199 2481 // page
RENDERTRACE 1918.32 rect lightgreen 0 896 1199 1024 // painted displayport
RENDERTRACE 1933.19 rect red 0 912 1199 795 // viewport
RENDERTRACE 2300.79 rect brown 0 0 1199 2481 // page
RENDERTRACE 2300.79 rect lightgreen 0 896 1199 1024 // painted displayport
RENDERTRACE 2316.8 rect red 0 912 1199 795 // viewport
RENDERTRACE 2526.27 rect yellow 0 0 1199 2481 // requested displayport velocity (0,0)
 -- checkerboarding starts below --
RENDERTRACE 2535.5 rect red 0 798 1199 795 // viewport
RENDERTRACE 2538.99 rect brown 0 0 1199 2481 // page
RENDERTRACE 2539.03 rect lightgreen 0 896 1199 1024 // painted displayport
RENDERTRACE 2551.32 rect red 0 798 1199 795 // viewport
RENDERTRACE 2572.86 rect brown 0 0 1199 2481 // page
RENDERTRACE 2572.87 rect lightgreen 0 0 1199 2481 // painted displayport painttime 46.6383
Checkerboarded for 2 frames (47.9611 ms), 117502 peak, 5249 severity.

	Fanolian Reporter
	Comment 9 • 8 years ago

(In reply to Fanolian from comment #8)
> Below is the raw log of the very first scroll, i.e. scrolling up at
> https://forum-en.guildwars2.com/forum where the permanent was supposed to be
permanent -> permanent checkerboading

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 10 • 8 years ago

Thanks. Not getting perma-checkerboarding any more is good news. That means the only issue left is that it's easier to checkerboard right after switching tabs, because of the (intentional) change in bug 1186662. We should probably do something to expand the displayport after the tab switch is complete so that we don't have this problem. BenWa, do you think it makes sense to schedule a repaint after doing the unsuppress, so that we do a second paint with the larger displayport?

	Benoit Girard (:BenWa) Assignee
	Comment 11 • 8 years ago

Yes, I think it would.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 12 • 8 years ago

Marking this fixed by bug 1255054. I verified in the March 10 nightly (OS X) that after a tab switch we unsuppress the displayport and repaint the larger area so the checkerboarding doesn't happen as easily.