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
Created attachment 245650 [details]
screenshot of the brown squares
This seems to first appear in the 2006111405 nightly.
Maybe Bug 130078?
This page shows the problem too.
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?
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.
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
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.
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.
The problem is also very easy to see here:
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]
I think I'm not seeing this on Linux. Is anyone?
linux's user: http://forums.mozillazine.org/viewtopic.php?p=2604854#2604854
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.
Created attachment 245843 [details]
Brown box over toolbars (Windows)
Disregard me previous comment about not seeing the toolbars covered on Windows. See screenshot.
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.
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.
Created attachment 246108 [details]
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.
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.
Created attachment 246132 [details]
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.
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.
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.
Created attachment 246204 [details] [diff] [review]
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.
(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.
Alright, can anyone confirm that it helps Linux?
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...
(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?
This was a regression from 130078, and that was backed out ages ago, so this is no longer a bug, right Martijn?
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.
Yeah, I think this bug can be resolved->worksforme. Kurt, do you agree?
Yep, I have not seen this is a long time. Both test cases also do not show the problem. WFM