When loading a couple of websites in tabs, and switching to the new tabs will show a white page before the actual page is show. Looks as if the page only gets asked to render when focus is set on it's tab.

This looks like a "tab version" of bug 297343. This may also be the underlying cause of bug 313284. cl

Is this really a major issue?

Possibly a regression from bug 306245.

(In reply to comment #2) > Is this really a major issue? IMO, bug 313284 is pretty bad. I don't know how closely the two are related, but I suspect fixing this will probably address 313284 as well. cl

*** Bug 313903 has been marked as a duplicate of this bug. ***

can we get a date on which this started happening? it wasn't in 10a1.

This regressed after the 10/20 branch builds, those do not show this issue. So it might very well be a regression from bug 306245 like Simon said. Simon: yes this is a major issue. People just like me will wonder what the hell is going on as this is absolutly not normal behaviour, and very annoying ;)

This is a recent regression and should block 1.0. Flagging as such.

Let me get straight the problem here. You open a link, or bookmark in a background tab. You wait until it has finished loading. Then you click on that tab -- then you see a white flash (for as short time). Is that it? Or is there a longer period of white if you tab switch while the page is still loading?

(In reply to comment #9) > Let me get straight the problem here. > You open a link, or bookmark in a background tab. You wait until it has > finished loading. Then you click on that tab -- then you see a white flash (for > as short time). Is that it? Or is there a longer period of white if you tab > switch while the page is still loading? > As you wrote in the first line, when switched from page loaded tab to page loaded tab. (While the page is still loading it IS white so how would one know?) Once the page loads and has been switched, the next time the tab is selected there is no delay. Any other remaining unviewed tabs with loaded pages will have the delay and once viewed, no delay.

Yes, this was caused by the core portion of bug 306245.

(In reply to comment #12) > Created an attachment (id=200951) [edit] > Black page for testing > Important clarification and new info: bug occurs when loading multiple pages in tabs simultaneously from a folder: "open in tabs". Tried it from folder of urls in bookmark bar and bookmark menu using the black page and others. DOES NOT occur when the multiple tabs are loaded individually, also checked using the black page url. Hope that helps.

Ignore the words "the core part of" in comment 11.

(In reply to comment #13) > DOES NOT > occur when the multiple tabs are loaded individually, also checked using the > black page url. Hope that helps. That's not true. It happens if you load new tabs in the background.

(In reply to comment #15) > (In reply to comment #13) > > DOES NOT > > occur when the multiple tabs are loaded individually, also checked using the > > black page url. Hope that helps. > > That's not true. It happens if you load new tabs in the background. Absolutely. I can get this to occur no matter what as long as I'm loading new tabs in the background. It most certainly has nothing to do with tab groups. cl

The regression window certainly fingers the Camino part of bug 306245. When I'm working in Bugzilla, instead of a flash, it actually looks like the page is just drawing when I switch to the tab.

It doesn't just finger it, it *is* it. The tab isn't drawn while it's in the background because the view manager now thinks it's not visible, where in the pre-306245 world, it thought it was visible.

(In reply to comment #18) > It doesn't just finger it, it *is* it. The tab isn't drawn while it's in the > background because the view manager now thinks it's not visible, where in the > pre-306245 world, it thought it was visible. But this might be a good thing (other than the flash); it might reduce CPU load while loading pages in background tabs.

We're only drawing in background tabs on nsViewManager::SetWindowDimensions. It seems that Firefox does its drawing more frequently than that, because when I force IsViewVisible to return false in the same situation, the background tab draws anyway. What's an embedder to do?

So... it sounds like you just want to invalidate on tab switch, right?

The page already draws properly when we switch tabs. I thought about forcing the new tab to update before switching to its view, but Simon thought that would take too long. Firefox has the new page ready to display as soon as you change tabs; Camino used to too, and it'd be nice to get back to that without regressing bug 306245.

So why did bug 306245 affect the behavior here in Camino?

nsDocShell::GetVisibility was modified to ask the embedder whether or not the target was visible (via nsIBaseWindow::GetVisibility). At the same time, we modified our GetVisibility to only return true when the target tab was frontmost. This solved the focus issue of bug 306245 (with exceptions, see that bug) but caused this bug because GetVisibility is overloaded: it's not just used to determine whether or not focus can be taken, it's also used by nsViewManager::DispatchEvent to decide how to handle paint and resize events. Because visibility is false, we're going down the "delayed" resize path in SetWindowDimensions. That's probably actually what we should be doing anyway, but SetWindowDimensions is what used to let us draw in background tabs so that they were ready to go when the user switched to them, and now, we're not getting any of that. Instead, when you switch to a fresh tab that loaded a document in the background, it's a blank white slate upon which the page subsequently draws. So, the question is: if SetWindowDimensions is the wrong thing to rely on to handle the display of background tabs (as I suspect it is), what is the right thing? How does Firefox get away with having pages that loaded in brand-new background tabs display instantly upon switching to the tab, without any blank white slate displaying and causing a "blink" effect when the page is drawn?

roc, dbaron, see comment 24? I believe you're more familiar with that stuff than I am...

unless we can fix this in camino code, we need the core fix backed out.

just to clarify, if push comes to shove with RC2, you guys (pink/simon/mark etc.) would rather see both patches from Bug 306245 backed out instead of living with this regression right?

that's my vote, but i'll let simon and mark speak for themselves. the white flashing is a much bigger regression, IMHO.

(In reply to comment #24) > So, the question is: if SetWindowDimensions is the wrong thing to rely on to > handle the display of background tabs (as I suspect it is), what is the right > thing? How does Firefox get away with having pages that loaded in brand-new > background tabs display instantly upon switching to the tab, without any blank > white slate displaying and causing a "blink" effect when the page is drawn? It's not particularly instantaneous. If needed, we resize the content (a resize reflow) and then repaint it. It seems that the difference is that we don't flash something else first. So perhaps the question should be put another way: what causes the blank thing to be painted rather than having the Web page sized and painted fully the first time around?

in case we can't figure out a low risk fix for this in the next day or so, here's a patch that backs out 306245 on the branch.

Wait. Why are we backing out the core patch? Without the camino changes from bug 306245 the core patch doesn't cause this bug, does it? And the core patch is the right thing to do in general. That is, if we back anything out we should just back out the camino changes, imo...

(In reply to comment #31) > Wait. Why are we backing out the core patch? Without the camino changes from > bug 306245 the core patch doesn't cause this bug, does it? And the core patch > is the right thing to do in general. That is, if we back anything out we > should just back out the camino changes, imo... > Your right, if we back 306245 out to fix this, we should do just the Camino portion.

Backs out just the camino portion of 306245 so we can get back to a "better state" on the branch. It's going to get even harder to get approval for things on the branch so I'd rather try to get this in now and if someone comes up with a fix for 306245 that doesn't cause this problem they can petition for it later instead of being told it's too late to do anything in a couple days.

(In reply to comment #29) > It's not particularly instantaneous. If needed, we resize the content (a > resize reflow) and then repaint it. It seems that the difference is that we > don't flash something else first. So perhaps the question should be put > another way: what causes the blank thing to be painted rather than having the > Web page sized and painted fully the first time around? It's being painted upon fully the first time around, just upon a blank white "clean slate." Whatever the case may be, Firefox switches tabs quickly and the contents of the new tab paint in one fell swoop. In Camino, you can see layout doing its thing.

That doesn't answer the question (which probably requires poking around in a debugger), it just restates that it's happening.

Mike, tree closure is tonight for blocker bugs, if we want to fix this problem for camino, it's going to be best if we back out this camino part before midnight. Can you look at the back out patch? Thanks!

Comment on attachment 201577 [details] [diff] [review] back out the camino portion of Bug 306245 it appears just the camino backout is sufficient, but that means that the core code still doesn't work the way we expect that it should, and going back to our old way of doing things still works. when are we going to get the core fixed? r=pink

Ok, I checked in the camino change on the branch only! Leaving this bug open for further discussion about how to fix this regression by fixing the core issue. Or should that happen in 306245.

I think we should fix this regression on the trunk (where it still exists) by backing out the Camino portion of bug 306245, call this bug fixed, and come up with new plans to fix both testcases of bug 306245 *in bug 306245*

This bug really annoys our trunk-users. Is comment 39 a viable plan?

Josh fixed something in widget/cocoa that looked like this bug this week. Is this a duplicate / is it now fixed?

Regression in trunk Version 2006100522 (1.2+). It's back but a little different. First time through the tabs the blank/white page exists, next time through is seemless.

(In reply to comment #41) > Josh fixed something in widget/cocoa that looked like this bug this week. Is > this a duplicate / is it now fixed? No. This is a Camino bug, it still exists (open the testcase in comment 12 in a bg tab via cmd-click, then switch to that tab after it has finished loading) and the way to fix it is very well understood: apply attachment 201577 [details] [diff] [review] to the trunk. (Unfortunately the patch--or some other bit of Camino--will need a bit of loving, as it prevents the display of the browser window currently: 2006-10-08 17:36:07.376 Camino[17092] *** -[CHBrowserView getNativeWindow]: selector not recognized)

Just because I (think) I got this unbitrotted correctly for testing in bug 401383, I'm stashing this here so I can find it again.

This doesn't seem as bad as I remember, and it seems much harder to trigger than I recall, too (open attachment 200951 [details] twice, and switch from one copy to the other, background, one); I haven't hit it in real life at all in the past several months. I'm removing the 2.0 milestone right now, but flagging ? in case people are still seeing this in a much more pronounced manner on slower Macs (PPC folks, please check).

Comment on attachment 286515 [details] [diff] [review] possible unbitrotted trunk backout patch This may have been the backout patch unbitrotted, but it doesn't fix the bug any more.

We haven't heard any screaming, and I haven't done any investigation, so not for 2.0.