Last Comment Bug 743590 - [Azure] League Of Legends website has big black bars on either side
: [Azure] League Of Legends website has big black bars on either side
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: 14 Branch
: x86_64 Windows 7
: -- normal (vote)
: mozilla15
Assigned To: Bas Schouten (:bas.schouten)
:
Mentors:
http://na.leagueoflegends.com/
Depends on:
Blocks: 715768 740815
  Show dependency treegraph
 
Reported: 2012-04-08 15:45 PDT by Leman Bennett [Omega]
Modified: 2012-05-20 13:41 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Screenshot (1.29 MB, image/png)
2012-04-08 15:46 PDT, Leman Bennett [Omega]
no flags Details
semi reduced html (765.58 KB, application/x-zip)
2012-04-18 07:10 PDT, Alice0775 White
no flags Details
semi reduced html (649.56 KB, application/x-zip)
2012-04-18 07:29 PDT, Alice0775 White
no flags Details
another sample html (1.00 KB, application/x-zip)
2012-04-18 18:17 PDT, Alice0775 White
no flags Details
Properly mark ThebesLayer content invalid when changing content type. (963 bytes, patch)
2012-04-19 12:46 PDT, Bas Schouten (:bas.schouten)
jmuizelaar: review+
Details | Diff | Review

Description Leman Bennett [Omega] 2012-04-08 15:45:22 PDT
Rendering and then scrolling the League Of Legends website to the very top will result in generating big black bars on either side of the page.

1. Turn on Azure-Thebes Wrapper
2. Load the url
3. Scroll Down
4. Scroll back to the top.

Observe the black patches.

Also, they go away if you shift the focus back and forth to Nightly.
Comment 1 Leman Bennett [Omega] 2012-04-08 15:46:29 PDT
Created attachment 613202 [details]
Screenshot

Screenshot of the issue.
Comment 2 Leman Bennett [Omega] 2012-04-11 18:45:25 PDT
Here's another example: http://mozillamemes.tumblr.com/

Scroll the page and notice that the background turns black behind the columns.
Comment 3 Bas Schouten (:bas.schouten) 2012-04-11 19:37:37 PDT
I suspect this might be one of the component alpha bugs I introduced (and landed fixes for today on m-i). Try seeing if it's gone in tomorrow's nightly (if the patches make it to m-c in time).
Comment 4 Leman Bennett [Omega] 2012-04-12 18:13:56 PDT
Using an hourly cset: 576a14e57ea6, The issue remains.
Comment 5 Alice0775 White 2012-04-12 19:13:50 PDT
Confirmed with gfx.content.azure.enabled=true in
http://hg.mozilla.org/mozilla-central/rev/576a14e57ea6
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120412 Firefox/14.0a1 ID:20120412160832

Regression pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c95b597b5f08&tochange=9fa58c6060c5
Comment 6 Alice0775 White 2012-04-12 22:39:56 PDT
Last good : e36fabc31211
First bad : 9fa58c6060c5
Comment 7 Bas Schouten (:bas.schouten) 2012-04-18 06:25:31 PDT
I believe some of our component alpha fixes may have fixed this. I can no longer reproduce this on inbound, can anyone else?
Comment 8 Bas Schouten (:bas.schouten) 2012-04-18 06:30:06 PDT
(In reply to Leman Bennett (Omega X) from comment #2)
> Here's another example: http://mozillamemes.tumblr.com/
> 
> Scroll the page and notice that the background turns black behind the
> columns.

Hrm, I do see an artifact here but only when I scroll down all the way on the last meme.. I really would like a minimized testcase, I have no idea what's going on :(
Comment 9 Alice0775 White 2012-04-18 07:10:25 PDT
Created attachment 616113 [details]
semi reduced html
Comment 10 Alice0775 White 2012-04-18 07:29:22 PDT
Created attachment 616122 [details]
semi reduced html
Comment 11 Alice0775 White 2012-04-18 18:17:39 PDT
Created attachment 616403 [details]
another sample html
Comment 12 Bas Schouten (:bas.schouten) 2012-04-19 12:09:24 PDT
(In reply to Alice0775 White from comment #11)
> Created attachment 616403 [details]
> another sample html

This is an excellent stand-alone testcase. Hopefully this will let me solve the issue.
Comment 13 Bas Schouten (:bas.schouten) 2012-04-19 12:46:18 PDT
Created attachment 616705 [details] [diff] [review]
Properly mark ThebesLayer content invalid when changing content type.

When a ThebesLayer changes the content type of the primary surface, we need to mark the content of our surface invalid.

While in this code I noticed right now we create a redundant DrawTarget here that will later be overwritten. This isn't a big issue but it is a waste, so I should fix it at some point. I'll file a bug for this.
Comment 14 Jeff Muizelaar [:jrmuizel] 2012-04-20 20:45:41 PDT
Comment on attachment 616705 [details] [diff] [review]
Properly mark ThebesLayer content invalid when changing content type.

Are we likely to forget anymore of these?
Comment 15 Bas Schouten (:bas.schouten) 2012-04-21 08:18:56 PDT
(In reply to Jeff Muizelaar [:jrmuizel] from comment #14)
> Comment on attachment 616705 [details] [diff] [review]
> Properly mark ThebesLayer content invalid when changing content type.
> 
> Are we likely to forget anymore of these?

Not likely I don't think, I tried to re-check all of them. But you never know.
Comment 16 Kyle Huey [:khuey] (khuey@mozilla.com) 2012-04-25 20:35:27 PDT
https://hg.mozilla.org/mozilla-central/rev/f1132feeb481
Comment 17 Gary [:streetwolf] 2012-04-26 05:53:12 PDT
Bas

It's possible this patch also fixed bug https://bugzilla.mozilla.org/show_bug.cgi?id=700088 which after updating to cset http://hg.mozilla.org/mozilla-central/rev/cc5254f9825f now works fine.

Do you think so?

Note You need to log in before you can comment on or make changes to this bug.