956690 - Sometimes the screen goes blank when scrolling fast through large pages

Status: VERIFIED FIXED

(Firefox for Metro Graveyard :: General, defect)

Description

[KarstenS]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

Steps to reproduce:

Load a larger webpage and scroll though it by using the finger touch.

Video: http://youtu.be/e3gnRz_5mIc

Page I used in video: http://forum.square-enix.com/ffxiv/threads/110173-Verz%C3%B6gerungen-(Lag)-beim-Spielen-von-FFXIV/page7

Device used is the Dell Venue 8 Pro tablet.

Tested with Aurora branch as I still do not get the nightly into metro mode [Bug 950986].


Actual results:

As seen in the video, the screen gets white and the page has to get reloaded to get shown again.


Expected results:

Scrolling though the sites without getting white.

Comment 1

[Jim Mathies [:jimm]]

Thought this was fixed, but maybe not. I not I think it's a dupe of another bug.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

This was supposedly fixed by bug 936500 but I also ran into it today on metro. Perhaps it has regressed.

Comment 3

[juan becerra [:juanb]]

While testing testing on an Acer Iconia W3 I noticed that when I tried scrolling before the page loaded, the page would go blank. If I had more than one tab open, toggling between tabs would then redraw the page.

I tried this with autoblog.com and flyozone.com/paragliders/en/products/ for example. Often times I would let the page load completely before scrolling and the page would also go blank (actually the page's background color, I think).

The tablet in question is Atom based. Other machines where I tried this didn't show the problem.

I will try finding a regression range.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

For the record this appears to be identical to bug 936500. The patch at https://bug936500.bugzilla.mozilla.org/attachment.cgi?id=8334564 can be used to reliably reproduce the problem. Getting a regression window would be very useful here.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

So I rolled my local build back to 56a287aa20fd (+ cherry-picked the patch from bug 945829) but was able to still reproduce the problem. So I'm not convinced that this bug was ever actually fixed. Or maybe it landed at around the same time as the thing that broke it again. Either way I don't see the ShouldBuildLayerEvenIfInvisible function ever return true due to the displayport being set. I stuck a printf in there and don't see it getting printed.

Comment 6

[Jim Mathies [:jimm]]

tbpl logs work well for reproducing this.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Chris, I assume you tested bug 936500 on B2G rather than Metro? Can you verify that that bug is still fixed on recent code using the same process that you tested earlier? I'm trying to figure out what happened - if Metro is just so different that it was never fixed on Metro, or if another patch landed just before yours that broke it, or something else.

Comment 8

[Chris Lord [:cwiiis]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #7)
> Chris, I assume you tested bug 936500 on B2G rather than Metro? Can you
> verify that that bug is still fixed on recent code using the same process
> that you tested earlier? I'm trying to figure out what happened - if Metro
> is just so different that it was never fixed on Metro, or if another patch
> landed just before yours that broke it, or something else.

I tested on b2g, and the bug still seems to be fixed to me, but let me make sure by triggering it programmatically... I wonder if we have a define somewhere that has meant this isn't fixed? I think tn checked in a fix over my fix that rolled back mine and did it properly, but I'm not sure of that.

Comment 9

[Chris Lord [:cwiiis]]

Yep, everything looks fine on b2g.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

(In reply to Chris Lord [:cwiiis] from comment #8)
> I think tn checked in a fix over
> my fix that rolled back mine and did it properly, but I'm not sure of that.

tn's fix was in bug 951467 but it didn't roll yours back. That was was supposed to fix it more but for some reason neither fix seems to have worked on metro.

Comment 11

[Rodrigo Silveira [:rsilveira] [:rodms]]

Not sure if it's the exact same issue but on the Surface pro using latest aurora metro I can reproduce this by simply scrolling this site: http://www.socialfly.com.br/videos/11-este-homem-resolve-deixar-a-baboseira-de-lado-e-resume-o-maior-do-problema-do-brasil-em-2-minutos

It doesn't need to be fast scroll and it's not a huge site either. Switching tabs does not bring it back. Even when the page is completely blank I still can touch where the video is supposed to be and I can hear the audio playing (no video).

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Attachment: Displaylist/frametree dump

I applied a patch that sets the displayport y-value to 2000 as soon as you scroll down by a pixel, so as to easily reproduce this problem. I also turned on display list dumping, and based on that, also added some code to dump the frame tree in nsDisplayOwnLayer::BuildLayer. Attached is the log. There is output from three paints in the log; the first paint is correct (just after page load) and the second and third paints are after I scroll down and the new displayport value is set. Note that in the first paint there is a layer with scrollId=3 but that layer disappears in the other two paints. The page I was using to test is at people.mozilla.com/~kgupta/long.html

tn, do you see what's going wrong here? It looks like in the bad paints the OwnLayer item doesn't have any ScrollInfoLayer or ScrollLayer children whereas it does have those in the good paint. This is even before the optimization pass, so it seems like the problem happens pretty early on. I don't fully if the mapping from the frame tree to the displaylist is wrong or if the frame tree itself is wrong.

Comment 13

[Timothy Nikkel (:tnikkel)]

I think that when we call nsIFrame::BuildDisplayListForChild for the root scroll frame we exit early here

http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.cpp#2147

because no ignore scroll frame is set on documents other than the display root (bug 959847 is for changing that). For a quick fix we could skip that check if the child is the root scroll frame and it has a display port set.

Comment 14

[Kartikaya Gupta (email:[e-mail])]

(In reply to Timothy Nikkel (:tn) from comment #13)
> For a quick fix we could skip that
> check if the child is the root scroll frame and it has a display port set.

Doing this works. Is there a reason we need to check if the child is the root scroll frame? Based on the comments in the code there I would think that we would want to skip any child that has a displayport set.

Comment 15

[Kartikaya Gupta (email:[e-mail])]

Attachment: Patch

I omitted the root scroll frame check for now, but I can put it in if you want.

Comment 16

[Timothy Nikkel (:tnikkel)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #14)
> (In reply to Timothy Nikkel (:tn) from comment #13)
> > For a quick fix we could skip that
> > check if the child is the root scroll frame and it has a display port set.
> 
> Doing this works. Is there a reason we need to check if the child is the
> root scroll frame? Based on the comments in the code there I would think
> that we would want to skip any child that has a displayport set.

Root scroll frames are special in that the dirty rect is already the display port here when the child is a root scroll frames. For all other scroll frames the dirty rect only gets changed to the display port in ScrollFrameHelper::BuildDisplayList. Secondly, for non-root scroll frames it doesn't matter how big our display port is, if the scrollport of the scroll frame doesn't intersect the dirty rect we aren't going to be drawing it because we only composite the scrolled content inside the scroll frame into the scrollport of the scroll frame. For root scroll frames the scroll port does not correspond to what will be drawn, so we can't do this.

Skipping children who don't intersect the dirty rect is a very important display list building optimization, so we should minimize when we undo this optimization. For root scroll frames it probably doesn't matter because I don't think there are any (important?) cases where we have decided to draw the document but we wouldn't descend into the root scroll frame.

Anyways, I thought of a better way to target this which is more accurate. Because we can't rely on the builder having the right ignore scroll frame set we can just check if the presshell has IgnoringViewportScrolling() true, and we have the root scroll frame as a child.

Comment 17

[Kartikaya Gupta (email:[e-mail])]

Attachment: Patch v2

Makes sense. This works too.

Comment 18

[Timothy Nikkel (:tnikkel)]

Comment on attachment 8367576 [details] [diff] [review]
Patch v2

I think we should add this new check in addition to the old one. It's more of a hack around the fact that we aren't setting the ignore scroll frame on the builder, once we are able to do that we can remove this hack.

Comment 19

[Kartikaya Gupta (email:[e-mail])]

Attachment: Patch v3

Comment 20

[Kartikaya Gupta (email:[e-mail])]

Thanks!

https://hg.mozilla.org/integration/mozilla-inbound/rev/b67fef4a7864

Comment 21

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/b67fef4a7864

Comment 22

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 8367613 [details] [diff] [review]
Patch v3

[Approval Request Comment]
Bug caused by (feature/regressing bug #): unknown
User impact if declined: when flinging around a page in metrofox it is possible for the page to blank out and requires a reload to fix
Testing completed (on m-c, etc.): locally so far
Risk to taking this patch (and alternatives if risky): potential for making layout a tad bit slower since we are skipping over an optimization in some cases, but this should be more correct. potentially affects other platforms so we should keep an eye out for regressions
String or IDL/UUID changes made by this patch: none

(Requesting uplift to 28 which might be on beta by the time this is approved)

Comment 23

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 8367613 [details] [diff] [review]
Patch v3

Still time before merge, approving for Aurora.

Comment 24

[Kartikaya Gupta (email:[e-mail])]

https://hg.mozilla.org/releases/mozilla-aurora/rev/3195656c537b

Comment 25

[KarstenS]

Seems to work. The site keeps displayed. But still getting partial black for a very short time, when scrolling fast.

Interesting side effect: My Dell Venue 8 Pro got very hot during regular surfing before that change. Now its only getting warm. Huge difference.

Comment 26

[Jim Mathies [:jimm]]

(In reply to KarstenS from comment #25)
> Seems to work. The site keeps displayed. But still getting partial black for
> a very short time, when scrolling fast.

This is covered bug 961682. 

> Interesting side effect: My Dell Venue 8 Pro got very hot during regular
> surfing before that change. Now its only getting warm. Huge difference.

Good news, thanks for reporting!

Comment 27

[Andrei Vaida [:avaida]]

User agents:
[1] Mozilla/5.0 (Windows NT 6.3; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
[2] Mozilla/5.0 )Windows NT 6.3; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0

I was able to confirm the fix for this issue on Surface Pro 2, Windows 8.1 Pro 64-bit, using:
- the latest Beta (Build ID: 20140213172947) [1]
- the latest Aurora (Build ID: 20140217004001) [2]

Additional note:
- Similar to Comment 25, on both latest Beta and latest Aurora, white rectangles can still be seen for a very short time while scrolling through the page. Sometimes the screen gets completely white for a fraction of a second. I've used the same test page specified in Comment 0 to verify this.

Comment 28

[codemanx]

I got a bit similar issue with latest Firefox 38.0.5 under Windows 8.1 64bit on a MacBook Air with Bootcamp 5.1:

On certain web pages, usually with long content and code blocks such as https://docs.arangodb.com/Aql/GraphOperations.html, there are certain scroll spots on which the area goes blank. After a few seconds, the content appears correctly. It can also happen during scrolling of code containers horizontally. Video: http://youtu.be/SxJ62-qwGHg

The issue doesn't appear to exist in Chrome. However, there's another issue I got with Firefox as well as with Chrome: https://youtu.be/aR5NLVTf0cU

Please advice! Could both have a common root cause, being the graphics driver (Intel HD 5000 afaik) or chip itself?

Comment 29

[Kartikaya Gupta (email:[e-mail])]

These don't look like the issue this bug was about. It would be a good idea to file separate new bugs for the two issues you found and we can investigate.