Closed Bug 268252 Opened 20 years ago Closed 6 months ago

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

Categories

(Core Graveyard :: Widget: Mac, defect)

Product:
Core Graveyard
Component:
Widget: Mac
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: ScottF4+bugzilla, Unassigned)

References

Details

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
For some reason Bugzilla did not pick up the build id.  It is 1.8a5 build 2004110506
still occuring in build 2004110806.  Did not occur in build 2004110107
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Blocks: 243726
It sounds like the right widget isn't getting invalidated here (presumably
because we'd need to cross a viewmanager boundary to do it?)
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.
The assumptions in question are stated in bug 243726 comment 51 when it talks
about child widgets...
Even though there is workaround of scrolling in the newly selected tab, this is
worthy of smoketest blocker.
Severity: major → blocker
Keywords: regression, smoketest
*** Bug 269490 has been marked as a duplicate of this bug. ***
This is in the wrong component....
Assignee: tabbed-browser → sfraser
Component: Tabbed Browser → GFX: Mac
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?
*** Bug 269793 has been marked as a duplicate of this bug. ***
(In reply to comment #11)
bz, no, that patch does not fix the problem.
Flags: blocking1.8a5?
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.
Component: GFX: Mac → Tabbed Browser
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).
Component: Tabbed Browser → GFX: Mac
Flags: blocking1.8a5? → blocking1.8a5+
bz, so should we take this for 1.8a5 or let it sit?
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...
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...
bz, could you be more specific about what the widget issue is?  What should we
be looking for in order to fix this?
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...
Flags: blocking1.8a5+ → blocking1.8a5-
(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.

(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

(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).

(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.

Is this still a "smoketest blocker"?
I haven't seen this bug for sometime. WFM I'll said.
True, the bug isn't obvious any more, but see comment 17 (and onwards) for the
reason that it has been left open.
I really don't think this is a Smoketest blocker anymore....but you are welcome
to disagree.
Keywords: smoketest
yes, this certainly is blocking development.
Severity: blocker → normal
Keywords: regression
I need a reproducible case to be able to debug this.
To josh. See also bug 278812, bug 281455.
Assignee: sfraser_bugs → joshmoz
Bug 277067 discuss that widget don't control visibility correctly.

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

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.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → NEW
Component: GFX: Mac → Widget: Mac
QA Contact: mac
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 :-)
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).
Assignee: joshmoz → nobody
Product: Core → Core Graveyard
Status: NEW → RESOLVED
Closed: 19 years ago → 6 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.