Closed
Bug 147902
Opened 22 years ago
Closed 22 years ago
[Flash] Site has elements that show through all tabs
Categories
(Camino Graveyard :: Page Layout, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: chrispetersen, Assigned: bnesse)
References
()
Details
Attachments
(1 file, 2 obsolete files)
7.13 KB,
patch
|
Details | Diff | Splinter Review |
If a tab with this site, http://netmar.com/ is in the background, elements (namely the scrolling text thing) show through the other tabs.
Reporter | ||
Comment 1•22 years ago
|
||
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.
Reporter | ||
Comment 2•22 years ago
|
||
Reproduces in 0.2.8.
Comment 3•22 years ago
|
||
Ugh, sounds pehaps like child views are not hiding correctly ->beard
Assignee: saari → beard
Comment 4•22 years ago
|
||
*** Bug 152677 has been marked as a duplicate of this bug. ***
Comment 6•22 years ago
|
||
*** Bug 153544 has been marked as a duplicate of this bug. ***
Comment 7•22 years ago
|
||
*** Bug 154150 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 9•22 years ago
|
||
Patch that fixes a multitude of plug-in sins, including draw-thru and crashing in the notify timer callback.
Assignee | ||
Comment 10•22 years ago
|
||
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•22 years ago
|
||
Is this related to bug 155085?
Assignee | ||
Comment 12•22 years ago
|
||
It may be a similar issue but, at this point, a completely different codebase.
Comment 13•22 years ago
|
||
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.
Assignee | ||
Comment 14•22 years ago
|
||
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.
Assignee | ||
Comment 15•22 years ago
|
||
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.
Assignee | ||
Comment 16•22 years ago
|
||
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...
Attachment #89857 -
Attachment is obsolete: true
Assignee | ||
Comment 17•22 years ago
|
||
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.
Attachment #90032 -
Attachment is obsolete: true
Comment 18•22 years ago
|
||
*** Bug 155945 has been marked as a duplicate of this bug. ***
Comment 19•22 years ago
|
||
looks good. landing on chimera branch.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 20•22 years ago
|
||
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.
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 21•22 years ago
|
||
Opened new bug for remaining QT problem http://bugzilla.mozilla.org/show_bug.cgi?id=156583
You need to log in
before you can comment on or make changes to this bug.
Description
•