360789 - White/brown/gray sporadic squares when refreshing a page

Status: RESOLVED WORKSFORME

(Core Graveyard :: GFX, defect)

Description

[u88484]

I've seen a few times with the 2006111405 build on XP where there are a bunch of white squares down the left side of the page during loading of that page and on refresh of a page there are brown squares sporadically around the page. Reload again and the brown squares are in the same spots. Only page I can reproduce this on is www.cnn.com.

Load www.cnn.com and hit enter in the location bar or hit the refresh button and two brown squares show up on the blue navigation bar above the 'Education' link

Comment 1

[u88484]

Attachment: screenshot of the brown squares

Comment 2

[Brian Polidoro]

This seems to first appear in the 2006111405 nightly.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-11-13+04%3A00%3A00&maxdate=2006-11-14+05%3A00%3A00&cvsroot=%2Fcvsroot
Maybe Bug 130078?

This page shows the problem too.  

Comment 3

[Robert Roessler]

It is not clear what you are saying the problem is... on my XP SP2 system running 2006111409, several areas of the cnn.com page *do* get painted with the XP dialog background color during a refresh.  But this is a transient effect, as the the areas are quickly replaced with the page's actual content before the refresh is completed.

So is the objection to the choice of temporary "placeholder" color during the rendering of the page, or is there some issue with these squares *not* being replaced with content by the time the refresh completes?

Comment 4

[u88484]

I can understand the plugin placeholders or the ads but not like 30 squares down the left side of the screen or all through the page. cnn.com was the only place that i was quick enough to get a screenshot of and it really doesn't reflect the amount or randomness of the squares. The point is, this is a regression caused by something because it just started recently.

Comment 5

[u88484]

BTW this doesn't only happen on refresh, I've seen it multiple times upon visiting sites for the first time and also pages (or some of the content) that should be in my cache

Comment 6

[Robert Roessler]

Hmmm... I note from your screenshot that you are running a "minefield" build - which you did not mention.  So your "2006111405" may have more differences than I thought relative to my "2006111409", which is a nightly SM trunk build.

Someone more up on the build family terminology would know more how much difference is likely to be present.

Comment 7

[u88484]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/200611604 Minefield/3.0a1

I figured the trunk in the version box would suffice but I forgot I filed this in core so this could have been Firefox or SM.

Comment 8

[Jim Jeffery not reading bug-mail 1/2/11]

The problem is also very easy to see here: 

http://wilderssecurity.com/forumdisplay.php?f=32

There is a series of white boxes down the left side, and often, if you do refreshes, a variable sized 'white-box' may appear in the middle of the screen. 

If these 'place-holders' must be used, then can they be made transparent...
IMO its just plain "ugly".

I too am using trunk/Minefield builds, latest nightly:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061116 Minefield/3.0a1 Firefox ID:2006111611 [cairo]

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think I'm not seeing this on Linux. Is anyone?

Comment 10

[-fullmetaljacket-]

linux's user: http://forums.mozillazine.org/viewtopic.php?p=2604854#2604854

Comment 11

[u88484]

Attachment: linux user screenshot

Here is a screenshot from a linux user. Note: I haven't seen it like this on windows where the toolbars and statusbar are covered at all.

Comment 12

[u88484]

Attachment: Brown box over toolbars (Windows)

Disregard me previous comment about not seeing the toolbars covered on Windows. See screenshot.

Comment 13

[Jim Jeffery not reading bug-mail 1/2/11]

Whatever https://bugzilla.mozilla.org/show_bug.cgi?id=130078 attempted to fix which created things discussed here, I have found today it is also creating a significant impact on video playback from embedded videos. 

CPU shoots up to approx 95%+ and white flashing boxes are observed in the playback making the video very choppy and broken.  I went back to a Minefield build before the patch was introduced and the playback is fine on my older slow system with CPU only running about 15%.

I further suspect the patch in question as causing these issues is affecting bfcache as well.  On this older build if a page is static has not changed it does not redraw... with the patch the pages are redrawn everytime refresh is pressed, not so prior to the patch.  

I'm not sure what issue the patch was trying to fix, but a patch dating back to 2002, surely has been changed with the introduction of cairo/thebes and the speed improvements that were noted in Windows is now, to my observations, very slow and is destroying any gains that were made.  

I'm further concerned that when the re-flow branch lands, with its page display issues is going to further complicate the overall page display problems. 

Any change that the suspect bug could be re-evaluated as necessary at this point and perhaps backed out until its understood what's going on internally? 

I'm no coder, so its only my gut feeling that something is seriously amiss with the patch.  There have been no complaints to my knowledge with Minefield builds, and some of have been using them for months now.. with no detriment to the display of web pages, and in fact improvements have been notable until the landing of this patch. 

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'll try to fix this bug here and then we'll see where we stand. The fix in bug 130078 is definitely the right thing to do, architecturally.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: reduced testcase

This exceptionally simple testcase causes chrome to flicker on Linux when you reload it by pressing enter in the URL bar. I reduced it from cnn.com and I think it's the same problem.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Apparently it also causes chrome flicker on Windows.

The testcase only "works" if you set the IFRAME width to 0. (Height 0 doesn't do it.) And it only works if you set the URL to something that doesn't exist (about:neterror doesn't do it). Weird... I suspect this is related to ProcessPendingUpdates but I can't figure out why it's affecting the chrome.

Comment 17

[Martijn Wargers (dead)]

Attachment: testcase2

I see it with this testcase too, while reloading. For a brief moment I see the chrome color of the background (which is brownish for me). I used to not see that.
I'm seeing this happening on a lot of websites (maybe all), where certain brown boxes appear while another url is loading.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think there is a separate issue where the chrome background is showing through during a reload. I'll try to fix it, but it's a lot less serious than the boxes randomly jumping around.

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm digging in here. It looks like the chrome is getting blanked when we do the initial reflow of the error document, in rootFrame->Reflow.

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix?

The problem was that we were scrolling the error window during reflow, and with GTK2 nsWindow::Scroll calls gdk_window_process_all_updates to force a synchronous repaint of the newly visible area. But THAT was causing repaints of our chrome which were failing --- I'm actually not completely sure why, probably something to do with update batching. Anyway, I don't think we should be calling gdk_window_process_all_updates here. If I remove it, things still look good both with Xgl and a regular X server, so we don't seem to need it and I bet it's hurting performance. If we do need to synchronously paint the newly visible area I can do that explicitly in the view manager, much less of a sledgehammer solution.

So I'd appreciate it if people can try this patch and determine a) if it helps with the problems reported here and b) if it makes scrolling look worse.

Comment 21

[Martijn Wargers (dead)]

(In reply to comment #20)
> So I'd appreciate it if people can try this patch and determine a) if it helps
> with the problems reported here and b) if it makes scrolling look worse.

It doesn't fix the problems I'm seeing, neither with the testcases, nor with regular websites. Asaics, it doesn't make scrolling worse in any way. I'm on windowsxp, testing on a mingw debug build of Firefox.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Alright, can anyone confirm that it helps Linux?

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

As I suspected, we're not repainting the chrome during this scroll operation because we've disabled refresh during the initial reflow of the error document. 

But this should be OK as long as we don't force synchronous paints, and my patch should be fixing at least the testcase for Windows...

Comment 24

[Martijn Wargers (dead)]

(In reply to comment #23)
> But this should be OK as long as we don't force synchronous paints, and my
> patch should be fixing at least the testcase for Windows...

Well, it doesn't for me here. Maybe someone else can test too?

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This was a regression from 130078, and that was backed out ages ago, so this is no longer a bug, right Martijn?

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think the problem here was mainly that paint batching started affecting both content and chrome since after bug 130078 they had the same root view manager. This is grist for the compositor.

Comment 27

[Martijn Wargers (dead)]

Yeah, I think this bug can be resolved->worksforme. Kurt, do you agree?

Comment 28

[u88484]

Yep, I have not seen this is a long time. Both test cases also do not show the problem. WFM