Closed Bug 956690 Opened 6 years ago Closed 6 years ago

Sometimes the screen goes blank when scrolling fast through large pages

Categories

(Firefox for Metro Graveyard :: General, defect)

28 Branch
x86
Windows 8.1
defect
Not set

Tracking

(firefox28 verified, firefox29 verified)

VERIFIED FIXED
Firefox 29
Tracking Status
firefox28 --- verified
firefox29 --- verified

People

(Reporter: karsten.schilder, Assigned: kats)

References

Details

(Whiteboard: [metro] [gfx] r=ff29)

Attachments

(2 files, 2 obsolete files)

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.
OS: All → Windows 8.1
Hardware: All → x86
Whiteboard: [triage]
Whiteboard: [triage] → [triage] [defect] p=0
Thought this was fixed, but maybe not. I not I think it's a dupe of another bug.
This was supposedly fixed by bug 936500 but I also ran into it today on metro. Perhaps it has regressed.
Summary: When scrolling faster by finger touch through larger pages → Sometimes the screen goes blank when scrolling fast through large pages
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [triage] [defect] p=0 → [beta28] [defect] p=0
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.
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.
Whiteboard: [beta28] [defect] p=0 → [beta28] [defect] p=8
tbpl logs work well for reproducing this.
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.
Flags: needinfo?(chrislord.net)
Whiteboard: [beta28] [defect] p=8 → [metro] [beta28] [gfx]
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
Flags: needinfo?(chrislord.net)
Yep, everything looks fine on b2g.
(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.
Whiteboard: [metro] [beta28] [gfx] → [metro] [gfx]
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).
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.
Flags: needinfo?(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.
Flags: needinfo?(tnikkel)
(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.
Blocks: 964403
Assignee: nobody → bugmail.mozilla
Attached patch Patch (obsolete) — Splinter Review
I omitted the root scroll frame check for now, but I can put it in if you want.
Attachment #8367513 - Flags: review?(tnikkel)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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.
Attachment #8367513 - Flags: review?(tnikkel)
Attached patch Patch v2 (obsolete) — Splinter Review
Makes sense. This works too.
Attachment #8367513 - Attachment is obsolete: true
Attachment #8367576 - Flags: review?(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.
Attachment #8367576 - Flags: review?(tnikkel)
Attached patch Patch v3Splinter Review
Attachment #8367576 - Attachment is obsolete: true
Attachment #8367613 - Flags: review?(tnikkel)
Attachment #8367613 - Flags: review?(tnikkel) → review+
https://hg.mozilla.org/mozilla-central/rev/b67fef4a7864
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
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)
Attachment #8367613 - Flags: approval-mozilla-aurora?
No longer blocks: metrobacklog
Comment on attachment 8367613 [details] [diff] [review]
Patch v3

Still time before merge, approving for Aurora.
Attachment #8367613 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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.
(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!
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.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Whiteboard: [metro] [gfx] → [metro] [gfx] r=ff29
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?
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.
You need to log in before you can comment on or make changes to this bug.