268252 - Clicking on new tab doesn't change screen content until window is scrolled

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Widget: Mac, defect)

Description

[Scott Field]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: 

If several tabs are open clicking on a new tab switches the url and title but
not the screen content. Scrolling down results in screen refreshing to new site.
 Mousing over the screen results in images from the new page bleeding through
the old page

Reproducible: Sometimes
Steps to Reproduce:
1. Open several sites in different tabs
2. Switch tabs by either clicking in a new tab or using control page up/down
3.

Actual Results:  
New tab is highlighted
Title changes to selected site
Url changes to selected site
Screen continues to show old site


Expected Results:  
Screen should show content of new site

Screen updates when window is scrolled down.  If you mouse over page, graphic
elements from new page show through

Comment 1

[Scott Field]

For some reason Bugzilla did not pick up the build id.  It is 1.8a5 build 2004110506

Comment 2

[Scott Field]

still occuring in build 2004110806.  Did not occur in build 2004110107

Comment 3

[Wayne Woods]

I'm seeing this too, in both Seamonkey and Firefox trunk nightly builds. I'm not
sure exactly in which build it began, but it didn't occur in the Firefox nightly
build of 20041103.

Comment 4

[Wayne Woods]

I've narrowed it down to between 20041104-11 20041105-07 on the Firefox trunk
and between 20041104-06 and 20041105-06 on the Mozilla Seamonkey trunk.

Comment 5

[Boris Zbarsky [:bzbarsky]]

It sounds like the right widget isn't getting invalidated here (presumably
because we'd need to cross a viewmanager boundary to do it?)

Comment 6

[jhp (no longer active)]

On bz's suggestion, I tested the patch at
https://bugzilla.mozilla.org/show_bug.cgi?id=268090#c8, and it seems to fix the
problem.  bz seems to think that some assumptions made in the viewmanager are
being violated.

Comment 7

[Boris Zbarsky [:bzbarsky]]

The assumptions in question are stated in bug 243726 comment 51 when it talks
about child widgets...

Comment 8

[Tracy Walker [:tracy]]

Even though there is workaround of scrolling in the newly selected tab, this is
worthy of smoketest blocker.

Comment 9

[HARUNAGA Hirotoshi]

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

Comment 10

[Boris Zbarsky [:bzbarsky]]

This is in the wrong component....

Comment 11

[Boris Zbarsky [:bzbarsky]]

Javier, could you also try the patch at
https://bugzilla.mozilla.org/attachment.cgi?id=165859&action=view ?  Does that
fix the problem in this bug as well?

Comment 12

[HARUNAGA Hirotoshi]

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

Comment 13

[jhp (no longer active)]

(In reply to comment #11)
bz, no, that patch does not fix the problem.

Comment 14

[jhp (no longer active)]

bz, your combo patch at https://bugzilla.mozilla.org/show_bug.cgi?id=268090#c30
seems to fix this issue.  In limited testing, I haven't noticed any other
problems with that patch applied.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Yeah... That patch is basically a workaround for this bug and that one. 
Something is still wrong somewhere (either in widget impls or the widget api or
both).

Comment 16

[Asa Dotzler [:asa]]

bz, so should we take this for 1.8a5 or let it sit?

Comment 17

[Boris Zbarsky [:bzbarsky]]

Asa, the symptoms are fixed by the patch in bug 268090 (which has approval).

I'm going to leave this bug open after I check that in, I think, because I think
there is a widget-level problem here...

Comment 18

[Boris Zbarsky [:bzbarsky]]

I checked in the fix for bug 268090.  Leaving this open, because I think there's
a widget issue here that that patch just works around...

Comment 19

[jhp (no longer active)]

bz, could you be more specific about what the widget issue is?  What should we
be looking for in order to fix this?

Comment 20

[Boris Zbarsky [:bzbarsky]]

The problem, as far as I can tell from the patches that did and did not fix this
bug, is that there's a widget about that has nsIWidget kids that either don't
have views or have views in a different viewmanager (in the latter case, I don't
know how it works even with the bug 268090 patch).

Invalidates are, for some reason, being applied to the parent widget but not the
child ones...

That is, when I switch tabs, the widget of the tab I switched to is not
invalidated, for some reason...

Comment 21

[Katsuhiro MIHARA]

(In reply to comment #20)
> Invalidates are, for some reason, being applied to the parent widget but not the
> child ones...

Are there some widgets that is set up "invisible" in the widget tree?
I think, If there are such widgets, invalidates stop at such widgets.

But I don't find such widgets.

Comment 22

[Katsuhiro MIHARA]

(In reply to comment #21)
> Are there some widgets that is set up "invisible" in the widget tree?

What method sets nsWindow's childlen visible?
Or, in Mac, don't nsWindow have any child?

In Mac, nsWindow::Show(PRBool bState) doesn't set childlen visible.
http://lxr.mozilla.org/mozilla/source/widget/src/mac/nsWindow.cpp#559

Comment 23

[jhp (no longer active)]

(In reply to comment #22)
> In Mac, nsWindow::Show(PRBool bState) doesn't set childlen visible.

That's because Mac widget code has both an nsWindow.cpp and an nsMacWindow.cpp,
which does all the work.  nsMacWindow::Show() calls Inherited::Show() (Inherited
being a typedef of nsChildWindow).

Comment 24

[Katsuhiro MIHARA]

(In reply to comment #23)
> That's because Mac widget code has both an nsWindow.cpp and an nsMacWindow.cpp,
> which does all the work.  nsMacWindow::Show() calls Inherited::Show() (Inherited
> being a typedef of nsChildWindow).

I wonder about this.
What method setup children's mVisible = PR_TRUE ?

mozilla/widget/src/mac/nsChildWindow.{h,cpp}
don't declare nor define nsChildWindow::Show().
So, when nsMacWindow::Show() calls Inherited::Show(),
it calls only nsWindow::Show().
The widget setup only his own mVisible, I think.

Comment 25

[David G King]

Is this still a "smoketest blocker"?

Comment 26

[Sébastien Desvignes]

I haven't seen this bug for sometime. WFM I'll said.

Comment 27

[Wayne Woods]

True, the bug isn't obvious any more, but see comment 17 (and onwards) for the
reason that it has been left open.

Comment 28

[David G King]

I really don't think this is a Smoketest blocker anymore....but you are welcome
to disagree.

Comment 29

[Tracy Walker [:tracy]]

yes, this certainly is blocking development.

Comment 30

[Simon Fraser [no longer active]]

I need a reproducible case to be able to debug this.

Comment 31

[Simon Fraser [no longer active]]

To josh. See also bug 278812, bug 281455.

Comment 32

[Katsuhiro MIHARA]

Bug 277067 discuss that widget don't control visibility correctly.

When Bug 277067 is fixed, this bug maybe fixed, I think.

Comment 33

[Josh Aas]

For future readers, see comment #18. I am closing this bug now because it is
unlikely that anybody is going to work on a theoretical bug with no known
symptoms in a component we're trying to phase out. Reopen again if/when
something interesting happens.

Comment 34

[Boris Zbarsky [:bzbarsky]]

Er... The component is wrong; it should be widget.  And the bug is not exactly
theoretical.  We're using slower code in viewmanager to work around this; I
would like to see this bug fixed so I can go back to using the faster code.

Comment 35

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

Josh is working on phasing out widget/mac. And I'm working on phasing out child
widgets altogether. If either one of us succeeds, this will go away :-)

Comment 36

[Boris Zbarsky [:bzbarsky]]

At that point, let's resolve it.  And that'll serve as a reminder to simplify
viewmanager code (which I admit would have already happened if you (but not
Josh) succeed).