147902 - [Flash] Site has elements that show through all tabs

Status: VERIFIED FIXED

(Camino Graveyard :: Page Layout, defect)

Description

[Chris Petersen]

If a tab with this site, http://netmar.com/ is in the background, elements
(namely the scrolling text thing) show through the other tabs.

Comment 1

[Chris Petersen]

This is problem a general plug-in issue since I can reproduce with QT movies.

1) Go to http://www.apple.com/hardware/ads/imac_window.html
2) Create a new tab and switch back to the imac page (first tab).
3) Click on movie to start it.
4) As movie plays, switch back to second tab.
5) Movie is overlayed on the page.

Tested on Chimera 0.2.5, QT Plugin 5.0.2.

Comment 2

[Chris Petersen]

Reproduces in 0.2.8.

Comment 3

[saari (gone)]

Ugh, sounds pehaps like child views are not hiding correctly
->beard

Comment 4

[saari (gone)]

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

Comment 5

[Greg K.]

Confirmed using Chimera/20020619.

Comment 6

[Winnie Lam]

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

Comment 7

[saari (gone)]

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

Comment 8

[saari (gone)]

beard is on sabatical, brian, you win :-)

Comment 9

[Brian Nesse (gone)]

Attachment: Proposed patch

Patch that fixes a multitude of plug-in sins, including draw-thru and crashing
in the notify timer callback.

Comment 10

[Brian Nesse (gone)]

cc'ing sfraser for review and checking in (assuming he likes the patch.)

There is one visual issue with this patch in that QuickTime movies still draw a
frame through the tab when the switch occurs (but do not continue to draw
subsequent frames.) I will continue to look into this, but this patch is a major
improvement over current functionality and should land with or without the
QuickTime fix.

Comment 11

[Greg K.]

Is this related to bug 155085?

Comment 12

[Brian Nesse (gone)]

It may be a similar issue but, at this point, a completely different codebase.

Comment 13

[Mike Pinkerton (not reading bugmail)]

if mVisible isn't correct, we should remove it altogether rather than commenting
it out in one place, right?

and you can condense that code into 1 line, rather than 6:
  bState = ([mView window] != nil);

the plugin code in the patch is meaningless to me. i'm afraid my review won't do
much good there.

Comment 14

[Brian Nesse (gone)]

Well... I didn't remove mVisible because it can get set by the Show() method and
is tested against in various places. The reason I only comment it out is because
it just didn't appear to be valid in the tabbed view scenario. Do you want all
references to mVisible to become calls to IsVisible? I was thinking that, in the
long run, it would be nice to try and figure out why the tabbed state was not
accurately reflected by mVisible.

Comment 15

[Brian Nesse (gone)]

After thinking about this on the train home, it occurs to me that a better way
to approach this might be:

if (!mVisible) {
  bState = mVisible;
} else {
  // mVisible does not accurately reflect the state of a hidden tabbed view
  // so verify that the view has a window as well.
  bState = ([mView window] != nil);
}
return NS_OK;

This leaves the original Show() functionality intact (flawed or not), but
insures that IsVisible() will do the right thing.

Comment 16

[Brian Nesse (gone)]

Attachment: Revised patch

Revised nsChildView as per comments and changed nsObjectFrame to use the
"Carbonized" version of InitializeEventRecord (build the event record rather
than call OSEventAvail). I'm not even sure why this compiled... I didn't think
OSEventAvail existed in OS X...

Comment 17

[Brian Nesse (gone)]

Attachment: One more time

After re-visiting it again, it seems that I'm stupid and the TARGET_CARBON code
was being used. I have removed that portion of the patch.

To help clarify nsObjectFrame changes for pink...
the mWidgetVisible changes do 2 things... First, they allow us to clip out when
we aren't visible (that fixes this bug.) In addition, they allow us to not pass
mouse events to shockwave through tabs (fixes bug 120875).

The "if (pluginPort)" checks keep us from crashing if the call to
FixupPluginWindow returns NULL (which it can/does during object creation when
the widget does not yet exist). This fixes bug 154023 and friends.

Comment 18

[Simon Fraser [no longer active]]

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

Comment 19

[Mike Pinkerton (not reading bugmail)]

looks good. landing on chimera branch.

Comment 20

[Chris Petersen]

Using the 2002-07-08-13 build, I was still able to see the problem occur with QT
movies that displayed their movie controllers. When I navigated the my second
tabbed window, I saw a still image painted on the window. Refreshing the window
(by resizing window) resolved this issue. I can't reproduced any problems with
flash embebbed pages like the original url provided. I think a new bug for the
reamaining QT issue should be created and this one should be fixed.

Comment 21

[Chris Petersen]

Opened new bug for remaining QT problem
http://bugzilla.mozilla.org/show_bug.cgi?id=156583