362549 - [Mac][Cairo] Tab content bleeds into loading tabs

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Wayne Woods]

If you have an already-loaded tab, start loading a second in the background, from a site that is slow to respond. Switch from the first to the second tab before it has loaded any content. The content from the first tab will appear in the second, until it starts to draw the correct content. I've noticed that the bug is still reproducible when the correct title has already loaded for the second tab, but it stops soon after, as the content starts to be drawn.

This bug began at the same time Cairo was switched on, i.e. it didn't exist in the 20061121 build, but does exist in the 20061122 build.

STR:
1. Load http://www.mozilla.org
2. Cmd-click on one of the links (such as the Camino one) to open it in another tab.
3. Assuming your connection is slow enough, quickly switch to the second tab. If you're having trouble doing that in time, find a site that is slow to respond, instead.
4. Note (hopefully) that the content from the mozilla.org tab appears in the second tab, until the correct content starts to load.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Just doing Cmd-T from an existing tab will cause this for me, no philor-class connection required ;)

Comment 3

[Phil Ringnalda (:philor)]

Bet you don't wind up clicking away at a page, wondering why the links or form controls have gone dead, only to discover when the real new tab starts to load that you were looking at the previous tab, fifteen or twenty times a day, though.

Comment 4

[[e-mail]]

I am not seeing this issue in the latest nightly anymore. Cmd-click opens a blank new tab right away before load the new page. Is it fixed?

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a5pre) Gecko/20070601 Minefield/3.0a5pre ID:2007060104 [cairo]

Comment 5

[Phil Ringnalda (:philor)]

Better, but not all-better.

STR:
1. Cmd-click http://example.com:443/ (which will conveniently time out after a while).
2. Focus the new tab, it should be white.
3. Focus any tab with content.
4. Focus the tab loading example.com, it should still be white, but now will show the content of the tab from step 3.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Oddly, I can reproduce this even after the "Problem loading page" has appeared for the bogus example.com tab -- clicking to that tab causes nothing to be painted.  Investigating more...

Comment 7

[Wayne Woods]

I wonder if the cause of this bug is also what makes a closed tab persist as a ghost in the tab bar, if the tab that the window was supposed to switch to was one that was currently at the early stage of loading (i.e. no content yet). I can't find a separate bug for that, though I would have thought it'd be reported.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

So the problem seems to be that we never send an Invalidate for the content area if no document was ever (successfully) loaded in it.  This is easy to see via Quartz Debugger's invalidation flashing; when switching from the "good" tab to the "bad" tab the content area never flashes, but when going the other way the content area is invalidated and repainted.  I'm trying to debug this; Cc'ing roc as he might have some ideas about what's different when no content is ever loaded into a browser.

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

So there's something else going on here.. we're actually calling Invalidate correctly, but something in the widget layout is such that the invalidate isn't actually happening, or it's invalidating a hidden widget.  From what I can tell, a "bad/stuck" tab has a hidden child widget that's somewhat odd (doesn't seem to have been created at the right time, and the one that was created when a "good" tab's widget was isn't in the hierarchy).

Also, initial paint delay seems to have some kind of factor into this... for example, set nglayout.initialpaint.delay to 5000, command-click on data:text/html,<a href="data:foo">foo</a> -- if you switch to the other tab, it won't invalidate until 5 seconds later, when you'll see the error page.

If I -disable- initial paint delay by setting mPaintingSuppressed to PR_FALSE in nsPresShell.cpp and don't start a timer, then -no- tab content is ever painted.

Comment 10

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Ok, this is way outside of the areas of gecko that I know now... gonna punt to nobody@, if anyone understands the initial document viewer/initial tab creation/etc. interaction, they should probably take a look.  I'd be happy to help and/or work with someone who understands those areas.

The data:text/html,<a href="https://example.com:443/">Example</a> test case is most useful; also helpful is hiding the locationbar, bookmarks toolbar, and statusbar, to minimize the number of unrelated repaints that happen.

Some more info (may or may not be relevant)... when command-clicking on the example.com URL, InitialReflow is never called until we get to loading the error page.  If I force aDoInitialReflow to PR_TRUE in DocumentViewerImpl::InitPresentationStuff, nothing is ever drawn (for any tab content, though browser chrome etc. is drawn fine).

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: some debugging output/coloring

This patch may be useful to others for debugging; along with a bunch of debug spew, it paints a mostly-unique colored stripe in each childview, along with painting the address of that view's gecko widget in the content area, making it easy to see where the different widgets in play are (and also to see that nothing gets repainted when switching tabs).

Comment 12

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

Attachment: fix

This is actually quite simple in the end. isRectObscuredBySubview should ignore hidden subviews...

Josh, who's your tame sr when it's not me? :-)

Comment 13

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

Comment on attachment 286133 [details] [diff] [review]
fix

Josh, please choose an sr for this one

Comment 14

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 286133 [details] [diff] [review]
fix

Yay!  Thanks for looking into this; the fix makes sense.  I never tracked it down to this point...

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 286133 [details] [diff] [review]
fix

a=endgame drivers for M9

Comment 16

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

checked in.

Comment 17

[philippe (part-time)]

I'm still seeing this issue with Camino (Version 2007102517 (2.0a1pre)) - using the steps in comment 5.
Minefield: Gecko/2007102516 Minefield/3.0a9pre works perfectly with the same steps