32327 - Mac: displaying page (flash, quicktime) ---> no more chrome ;)

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P1)

Description

[Eli Goldberg]

<sorry for the brief bug report, have to run to chiropractor, will be happy to
decompose further on Monday if you'd like.>

If you display http://www.mandalay.com (2000031518 Mac OS commercial beta 1
branch build), and try any of the following:
 - open a new composer window (select "Composer" from Tasks menu)
 - context-click on the page
 - open a dialog (e.g. preferences)

...the dialog or window will be completely white, with no content drawn.

Displaying the page on the same day's Win32 commercial build yields an immediate
crash. (TB7047577XX)

Comment 1

[Eli Goldberg]

This occurs on other Shockwave pages (e.g. www.shockwave.com); raising to 'Major'.

Comment 2

[Eli Goldberg]

I'm also seeing this displaying in-line QuickTime content. <http://
www.battlefieldearth.net/>

Comment 3

[shrirang khanzode]

I see the crash on today's windows beta1 build and think it is related to bug 
31109 where javascript is being used to detect the plugin.

Comment 4

[shrirang khanzode]

I see the problem of blank chromes appearing if I try to edit a page with plugin 
in Composer, or try to open Prefs dialog. Used today's macintosh beta1 build.

Comment 5

[shrirang khanzode]

nominating for beta1.

Comment 6

[shrirang khanzode]

Oops..just realised that mac plugins are not on priority for beta1

Comment 7

[Eli Goldberg]

(To clarify, by "seeing this" with QuickTime & other Flash pages, I meant that I 

was seeing the Mac-specific behavior. I haven't tried on other platforms.)

Comment 8

[shrirang khanzode]

Of the other remaining platforms, only windows is important for beta1( plugins 
do not work on linux) and I do not see this problem on windows.

Comment 9

[leger]

Putting on PDT- radar for beta1.

Comment 10

[ekrock's old account (dead)]

Updating summary & marking flash & quicktime.

Comment 11

[shrirang khanzode]

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

Comment 12

[John Morrison]

Nominating for nsbeta2:
 1) if you happen to open prefs (on the mac) while visiting a page that 
    has flash, you cannot dismiss the modal dialog -- your only option is 
    to quit the browser and restart (as good as being a crash in some ways).
 2) chrome doesn't work on the mac with flash/quicktime multimedia -- that
    is pretty severe loss of function for mac users, no?

Comment 13

[leger]

Putting on [nsbeta2+][6/01] radar.  This work must be done by 06/01 or we may 
pull this for PR2.

Comment 14

[Henri Sivonen (:hsivonen)]

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

Comment 15

[leger]

Setting to [nsbeta2+][6/15]

Comment 16

[John Morrison]

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

Comment 17

[John Morrison]

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

Comment 18

[Henri Sivonen (:hsivonen)]

According to Leger's NG post, this bug is getting moved off the nsbeta+ radar.

If Netscape chooses to ship some plugins (eg. Flash?) with PR2, this might be serious. 
Window drawing can (will?) break if the user happens to open a page that embed a 
Flash file. The user might not even notice it is a Flash file an not an animated GIF. That's 
why the cause of the problem can be hard to find. If the user's home page contains a 
Flash file, Mozilla appears to be broken all the time. (I spent quite some time figuring this 
out.)

I think it would be worthwhile to try preventing people from experiencing this bug in a 
large scale.

Comment 19

[Phil Peterson]

PDT agrees this is a beta2 stopper. Removing [6/15] from teh status whiteboard

Comment 20

[Asa Dotzler [:asa]]

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

Comment 21

[ekrock's old account (dead)]

Reassigning to Steve, who's kindly volunteered to take this on. Thanks Steve!

Comment 22

[Steve Dagley]

I don't believe this bug is still valid as originally entered (i.e. I'm not 
seeing disappearing (no pun intended) chrome with the basic mandalay.com page.  
If I load the high bandwidth page however the machine eventually crashes hard.  
Keeping bug open until I determine why.

Comment 23

[leger]

sdagley, please get with shrir.  He says it is pretty bad.  So, he can help you 
see the same thing we say.  Moving from [nsbeta2+] to [nsbeta2-] per PDT 
Plug-In QA Review.

Comment 24

[Steve Dagley]

Glad to hear it's nsbeta2- as I'm having no luck with this one.  Top top it off 
my development Mac apparently commited suicide while running Mozilla Wednesday 
night and not even re-formatting and re-installing the OS will resurrect it so 
I'm out of the Mozilla dev business until IS replaces it.  I'm also of the 
opinion that the state of Mac plugins in Mozilla is FUBAR and you need someone 
such as Alex Musil or Patrick Beard to fix things.  Unfortunately Alex no longer 
works at Netscape and Beard is way overloaded but I'll talk to him and see if he 
can spare any cycles.

Comment 25

[Chris Petersen]

This is a very reproducible and annoying problem on the Mac right now. I have a
very simple test case(that contains a flash object) that causes this issue to
occur. Simple open the url and rendered the flash animation. Move mouse over
tool bar icons and notice empty tool tip content displayed. 

Comment 26

[Chris Petersen]

Here's the url:

http://slip/projects/marvin/simple/a_simple_animation.html

Comment 27

[shrirang khanzode]

Clearing statusboard(nsbeta3 nomination already there for a long time). This bug 
was release noted for beta2 and this-is- still not-being-looked-at..I guess. 
This bug is very very annoying for users to work with and should be fixed for 
beta3. cc'ing Erik. Pardon me if I spammed you. Thx!

Comment 28

[John Morrison]

While this somehow slipped below radar, and time is short, it is important that
this be fixed for PR3. Otherwise, we ship a Mac product that can become crippled
by multimedia flash pages (no small irony there).

Comment 29

[ekrock's old account (dead)]

Steve, do you think you'll be able to do this for nsbeta3? Marking [egk] (a tag 
to note my concern about a bug) and restoring deleted [nsbeta2-].

Comment 30

[shrirang khanzode]

restoring status whiteboard contents so as not to mess up queries.

Comment 31

[Steve Dagley]

Other than the fact that my G4 has been resurrected none of my concerns from 7/14 
have really been addressed - we've got major problems with the plugin 
architecture on the Mac.  Beard, bnesse and I have discussed some more major 
bandaids but I'm not sure any of them qualify as a 'fix'.  I'm cc:'ing bnesse, 
since he's taken the lead on plugin work since all the bugs basically stem from 
the same problem, to see if he has any hope this can be addressed in beta3

Comment 32

[Peter Lubczynski]

adding myself to CC

Comment 33

[Mike Pinkerton (not reading bugmail)]

it would be better to turn all plugins off than ship with this bug. This is
pathetic. Why don't we have a triage status for beta3? This bug has only been
open for 6 months.

Comment 34

[Mike Pinkerton (not reading bugmail)]

dagley won't be back until 9/19, someone else needs to own this bug.

Comment 35

[John Morrison]

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

Comment 36

[John Morrison]

Just to be clear (because this *really* needs a solution before we ship) this 
is not merely an annoyance. All subsequent windows in the product stop working 
after visiting a site that uses these plugins. You can't use any dialog, open a 
new browser window, compose a mail message, ... and if you happen to open a 
modal dialog you are completely doomed -- you can't close it, and must 
force-quit the app.

Comment 37

[Simon Fraser [no longer active]]

Adding nsbeta3+. I know I shouldn't, but this bug cannot drop off the radar.

Comment 38

[Peter Trudelle]

I think this is off the front-line manager radar, since Steve's manager is not
on Seamonkey.  It only gets attention when it is one of a few bugs that the PDT
is looking at.

Comment 39

[sean echevarria]

cc self

Comment 40

[ekrock's old account (dead)]

cc:ing Clayton, av. Clayton, Peter, this is in my opinion an nsbeta3+ P1 level 
bug (without it, either plug-ins can't be used on the Mac, or if they're used, 
the product's chrome blows up!) that seems to have been overlooked during 
nsbeta3. It's assigned to sdagley, who's on sabbatical. To whom can we reassign 
this?

What appears to have happened here is, IIRC (1) Steve kindly volunteered to take 
this on during our all-on-deck effort to help av during nsbeta2, (2) 
unfortunately he didn't have time to fix this for nsbeta2 and it became a 
nsbeta3 nominee, but then he went on sabbatical, and I guess neither he nor his 
manager nor anyone else noticed it, and it's been languishing on the "nsbeta3 
nominated but not reviewed list" since then. (A good example of why unreviewed 
nsbeta3 nominees are a very dangerous thing. ;-< )

Increasing priority to P1 and marking nsmac1 and rtm. 

Comment 41

[ekrock's old account (dead)]

johng: Critical Mac Navigator bug in which chrome is disappearing, currently 
assigned to engineer on sabbatical.
chrisn, waldemar: Any Mac insights to offer?
hyatt, waterson: Any idea why showing plug-ins on the Mac blows away chrome?

Comment 42

[ekrock's old account (dead)]

*Really* cc:ing Clayton and Andrei this time. Clayton, Andrei, would you please 
read my last couple of comments on this bug?

Comment 43

[ekrock's old account (dead)]

BTW I was wrong he's not on sabbatical, he's on vacation until 9/19.

Comment 44

[johng]

Can't wait until dagley gets back.  reassigning to pink even though he may be
the wrong guy (maybe I should have assigned to av), but at least pink can find
someone to take care of this.

Comment 45

[Mike Pinkerton (not reading bugmail)]

Gee, great.

My guess  is that it's a port problem, something in the plugin code is 
incorrectly blowing away our graphics state and we can't recover.

I traced it into it and we are handling events correctly (we process the update 
events and send a paint event into gecko), and gfx is even blitting what it 
thinks is the whole window (nsRenderingContextMac::CopyOffscreenBits), but what 
we end up blitting is just blank.

Also, when blitting, the destPort's visRgn and clipRgn don't seem right...they're 
non-rectangular even when the entire window is being redrawn (windowshade, then 
un-windowshade, no overlapping windows).

ideas?

Comment 46

[Brian Nesse (gone)]

This bug (along with others) was brought to the PDT team shortly before beta2. 
They were told that without potentially major changes to the codebase, it was 
unlikely that mac plugins would ever work acceptably. The response was 
essentially "Do what you can for beta2."

My previous experience with this bug was that if you disable the double buffering 
on the Macintosh this problem vanished. I would therefore suggest that this bug 
would most likely be dependent on fixing 49743 if not a duplicate of it.

Comment 47

[Mike Pinkerton (not reading bugmail)]

per his request, --> pchen

Comment 48

[Mike Pinkerton (not reading bugmail)]

let's mark that a dependency. we'll see how long it takes kevin to come after me 
with a hatchet.

Comment 49

[ekrock's old account (dead)]

What's double buffering? What purpose does it serve? Is it a "nice to have" or a
"must have"? Could we remove it on the Mac (or on all platforms for that matter)
for RTM? (If it's a nice to have but not a must have, we could restore it in a
future release.)

To state the obvious: having plug-ins working on the Mac is a requirement for
Mac browser RTM.

Comment 50

[ekrock's old account (dead)]

Removing [egk] tracking code as this is currently marked [nsbeta3+].

Comment 51

[Simon Fraser [no longer active]]

Double-buffering is when we do all drawing into an offscreen buffer, then blit 
that to the screen. it is essential for smooth-looking screen redraws. We should 
not ship with it off.

Comment 52

[Kevin McCluskey (gone)]

Please try the patch attached to bug 49743, and let me know if it helps.
You will have to do some work in the plugin code to set the new don't double 
buffer flag on the view.

Comment 53

[Paul Chen]

Doing the morning ritual of pulling a tree, once that's done, I'll integrate the
patch for 49743, set double buffering off, and see what happens

Comment 54

[Peter Lubczynski]

Attachment: simple testcase with a quicktime OBJECT

Comment 55

[Phil Peterson]

PDT agrees P1

Comment 56

[don]

Shouldn't this and bug #49743 be a "++" bug for beta 3?

Comment 57

[don]

Moving this from beta 3 to RTM.  Does anybody disagree?

Comment 58

[Mike Pinkerton (not reading bugmail)]

well, if we have a page that can _make the browser inoperable_ we better relnote 
it.

why are we bothering to ship plugins at all? why not turn them off for beta3?

Comment 59

[Henri Sivonen (:hsivonen)]

How can this not be a beta stopper for Netscape? This can be worse than no plug-in 
support. Setting to blocker: this blocks plug-in-related development and testing.

Comment 60

[Simon Fraser [no longer active]]

I also disagree with the RTM label for this bug. We have to show that PR3 on Mac 
will work with common plugins, otherwise there will be serious functional 
differences between Windows and Mac PR3 releases, and we will not gain the 
confidence of the Mac community that PR3 is a serious, usable release.

Comment 61

[ekrock's old account (dead)]

This bug is at absolute last-gasp bare-minimum an RTM stopper. I'd prefer to see 
it fixed for nsbeta3 if we can and agree that it's extremely risky to postpone 
fixing this to rtm because goodness knows what other bugs this one may be 
masking.

Comment 62

[don]

OK, I'm plussing this again for beta 3 since so many people DID disagree with
the minus, and so the PDT can consider what they want to do with it.  In the
meantime, Paul tells me that folks down in San Diego have a hack that might
temporarily solve this.  Also, Simon will attempt to debug this thing tonight
and find out what's really going wrong.

And I don't think this thing is a blocker.  Give me a break.  Somebody remove
that soon, OK?

Comment 63

[Michael La Guardia]

Marking nsbeta3++.  We need to see this fix as soon as possible or we risk
slipping pr3.

Comment 64

[Peter Lubczynski]

Michael,

Kevin's patch to Bug 49743 needs to be checked into the branch before anything 
can be checked in on this. But, bug 49743 isn't nsbeta3++'ed.

I've also got a little code to fix up plugins so at least some of them will 
work for PR3.

Comment 65

[don]

Peter, since you're checking in the code, I'm re-assigning the bug to you.  Let
me know if there's anything Paul needs to do.

Comment 66

[Mike Pinkerton (not reading bugmail)]

i don't care if any plugins work, i only care that after you visit a plugin page
that future windows are not blank. Do these patches fix that problem?

Comment 67

[Peter Lubczynski]

..accepting bug

I don't believe "future windows not painting" and "chrome disappearing" are no 
longer happening (without any patch). But, plugins don't work at all on the Mac.

The patch I am working along with the patch for bug 49743 will at least get some 
plugins to work on Mac but it's not perfect. I see two problems here:

1) On the Mac, we don't display plugins in child windows but instead let them 
paint to the screen. Our double buffering is causing the gray box that you see 
to be painted on top of the plugin. The patch to bug 49743 allows double 
buffering to be turned off in the view manager and therefore prevents the 
appearence of the gray box. It must be activated by the object frame.

2) The plugin location and clip aren't set properly. Kevin and I developed some 
Mac specific code that fixes up the location and clip region. However, it's not 
complete yet because it paints over scroll bars in certain cases and scrolling 
looks bad.

Question: Do you want something checked-in to the branch to make plugins 
somewhat work, or do you want to wait until everything is perfected? With the 
code I have, it's better than it was before, but not perfect.

What works?
I've gone through some of the testcases sent by Shrir (forwarded from vendors). 
It looks like Real works pretty well. Flash and Shockwave also mostly work with 
the exception of a few cases. Quicktime also works, but after scrolling, it 
looks pretty bad. 

Comment 68

[Simon Fraser [no longer active]]

I can verify that turning off double buffering (using using the #define in 
nsViewManager2) fixes the problem where the Flash plugin causes subsequent 
windows to come up blank.

I think, if we can be sure that plugins are always drawn to the screen, and never 
to the offscreen buffer, this 'blank windows' bug will be go away.

Comment 69

[Peter Trudelle]

Please update with non-doomage ETA as soon as possible. Tomorrow, this will
become a candidate for delaying until rtm unless a safe fix is imminent.

Comment 70

[Peter Lubczynski]

Removing ETA We're DOOMED from the status whiteboard.

A fix has been checked in to the tip and branch so Mac flash and quicktime 
should no longer destory the chrome. 

I'm hesitant in marking this bug as FIXED because even though the fix makes 
plugins somewhat work, it's not 100% done. Should I change the summary or mark 
this fixed and open a new bug for the remainder of the problems with these Mac 
plugins?

Comment 71

[Mike Pinkerton (not reading bugmail)]

if the "no more chrome" bug is fixed, close this one out and open a new one. all
the fun keywords are because of the severity of the disappearing chrome, and
better to leave them all behind and start afresh than lose that information by
mutating this bug.

Comment 72

[Peter Lubczynski]

marking FIXED per last comments....

Comment 73

[shrirang khanzode]

Looks great.Verified on mac commercial branch build 2000092911. Chrome appears 
fine while  movie is playing.I will log seperate bugs for other problems that I 
see here. Adding keyword :vtrunk

Comment 74

[Asa Dotzler [:asa]]

this problem is FIxed in 100208 Mac Mozilla trunk build on OS9.  Removing vtrunk
keyword and setting status to Verified