Last Comment Bug 360789 - White/brown/gray sporadic squares when refreshing a page
: White/brown/gray sporadic squares when refreshing a page
Status: RESOLVED WORKSFORME
: regression
Product: Core Graveyard
Classification: Graveyard
Component: GFX (show other bugs)
: Trunk
: x86 Windows XP
: -- normal with 1 vote (vote)
: mozilla1.9alpha8
Assigned To: Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
: Hixie (not reading bugmail)
Mentors:
http://www.cnn.com
Depends on:
Blocks: 130078
  Show dependency treegraph
 
Reported: 2006-11-15 06:55 PST by u88484
Modified: 2009-01-22 10:17 PST (History)
17 users (show)
vladimir: blocking1.9+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
screenshot of the brown squares (254.87 KB, image/png)
2006-11-15 06:56 PST, u88484
no flags Details
linux user screenshot (47.52 KB, image/png)
2006-11-17 06:32 PST, u88484
no flags Details
Brown box over toolbars (Windows) (42.27 KB, image/png)
2006-11-17 08:01 PST, u88484
no flags Details
reduced testcase (38 bytes, text/html)
2006-11-20 19:55 PST, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
no flags Details
testcase2 (223 bytes, text/html)
2006-11-21 01:13 PST, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details
fix? (2.26 KB, patch)
2006-11-21 13:58 PST, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
no flags Details | Diff | Splinter Review

Description u88484 2006-11-15 06:55:21 PST
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 2006-11-15 06:56:39 PST
Created attachment 245650 [details]
screenshot of the brown squares
Comment 3 Robert Roessler 2006-11-16 12:46:58 PST
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 2006-11-16 12:56:30 PST
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 2006-11-16 12:58:39 PST
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 2006-11-16 13:06:04 PST
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 2006-11-16 13:18:58 PST
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 2006-11-16 13:35:37 PST
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) (Exited; email my personal email if necessary) 2006-11-16 17:03:38 PST
I think I'm not seeing this on Linux. Is anyone?
Comment 10 -fullmetaljacket- 2006-11-16 22:20:30 PST
linux's user: http://forums.mozillazine.org/viewtopic.php?p=2604854#2604854



Comment 11 u88484 2006-11-17 06:32:03 PST
Created attachment 245838 [details]
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 2006-11-17 08:01:50 PST
Created attachment 245843 [details]
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 2006-11-18 12:16:38 PST
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) (Exited; email my personal email if necessary) 2006-11-18 14:14:49 PST
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) (Exited; email my personal email if necessary) 2006-11-20 19:55:12 PST
Created attachment 246108 [details]
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) (Exited; email my personal email if necessary) 2006-11-20 20:47:13 PST
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 [:mwargers] (not working for Mozilla) 2006-11-21 01:13:34 PST
Created attachment 246132 [details]
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) (Exited; email my personal email if necessary) 2006-11-21 12:59:55 PST
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) (Exited; email my personal email if necessary) 2006-11-21 13:02:42 PST
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) (Exited; email my personal email if necessary) 2006-11-21 13:58:05 PST
Created attachment 246204 [details] [diff] [review]
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 [:mwargers] (not working for Mozilla) 2006-11-21 15:17:00 PST
(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) (Exited; email my personal email if necessary) 2006-11-21 15:23:53 PST
Alright, can anyone confirm that it helps Linux?
Comment 23 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-11-21 20:15:50 PST
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 [:mwargers] (not working for Mozilla) 2006-11-22 03:11:50 PST
(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) (Exited; email my personal email if necessary) 2007-09-10 16:08:45 PDT
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) (Exited; email my personal email if necessary) 2007-09-10 16:09:45 PDT
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 [:mwargers] (not working for Mozilla) 2007-09-10 16:14:04 PDT
Yeah, I think this bug can be resolved->worksforme. Kurt, do you agree?
Comment 28 u88484 2007-09-10 17:38:32 PDT
Yep, I have not seen this is a long time. Both test cases also do not show the problem. WFM

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