shrirang khanzode Reporter
	Description • 24 years ago

seen on 20010502 trunk on mac, yet to confirm on windows

Installed acrobat reader 5.0, copied the plugin over to 6.x trunk plugins folder
Went to the above page
Acrobat reader splashscreen comes up, nothing laods int he browser(except for a 
scrollbar and a stray icon on top left)

	shrirang khanzode Reporter
	Comment 1 • 24 years ago

keyword:acrobat

	Peter Lubczynski Assignee
	Comment 2 • 24 years ago

Shrirang isolated this to a regression to builds around 2001050104. Checking 
CVS log for nsPluginViewer.cpp shows Hyatt checking in his fix for bug 76495.

My guess at just looking at the code, seems like this is the problem:
NS_IMETHODIMP                                                                   
PluginViewerImpl::Validate()                                                    
{                                                                               
 if (mWindow)
   mWindow->Validate();
)

	Peter Lubczynski Assignee
	Comment 3 • 24 years ago

cc:ing Hyatt

Can you take a quick look. I think it's a regression from bug 76495?

	Peter Lubczynski Assignee
	Comment 4 • 24 years ago

This is much more serious than I had thought. Commenting out those lines does 
not solve the problem. This happens with all full page plugins on all platforms. 
 I still think it's from Hyatt's check-in.

Arun: Please don't give Adobe any builds (and perhaps other vendors too) untill 
this gets fixed!!

Looking at Bonsai, it doesn't look like anything else checked into plugins at 
that time could have caused this.
http://bonsai.mozilla.org/cvsquery.cgi?branch=HEAD&file=mozilla/modules/plugin/n
glsrc/&date=week

	David Hyatt
	Comment 5 • 24 years ago

Yeah, this sounds like it's mine.

	David Hyatt
	Comment 7 • 24 years ago

This patch basically undoes what I did... namely hiding the window and not 
showing it.  However, the full-page plugin still doesn't work.  The cursor 
changes and the background is right but the foreground doesn't paint.  Not sure 
if this is my bug now after making the patch.

peterl, have any ideas?  Try my patch out and see what it does for you.

	Peter Lubczynski Assignee
	Comment 8 • 24 years ago

Oh Hyatt, this is great! It works for me on Win32. Try another testcase like: 
http://slip.mcom.com/shrir/License.pdf and make sure you have Acrobat installed 
correctly.

Let me try Mac.

	Peter Lubczynski Assignee
	Comment 9 • 24 years ago

Patch does not work on Mac. Some stuff gets painted initially then 
everything disapears right affer you rezsize the window.

	Bernd
	Comment 10 • 24 years ago

>Arun: Please don't give Adobe any builds (and perhaps other vendors too) untill 
>this gets fixed!!

IMHO, this is equal to a 0.9 nomination. A browser that does not support acrobat
is plain useless for business use.

	Phil Peterson
	Comment 11 • 24 years ago

Bernd, this bug probably doesn't exist on the 0.9 branch, since the optimization
which caused this regression went in on the trunk after we branched.

	shrirang khanzode Reporter
	Comment 12 • 24 years ago

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

	Peter Lubczynski Assignee
	Comment 13 • 24 years ago

Hyatt, can you check-in what you have for now? It seems to work for me on 
Windows okay but this bug should be left open as it does not work on Mac.

	av (gone)
	Comment 14 • 24 years ago

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

	R.K.Aa.
	Comment 15 • 24 years ago

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

	hirata masakazu
	Comment 16 • 24 years ago

Will this fix correct the failure to launch Acrobat after saving file when there
is no plug-in installed?

	saari (gone)
	Comment 17 • 24 years ago

r=saari

	Ben Goodger (use ben at mozilla dot org for email)
	Comment 18 • 24 years ago

sr=ben@netscape.com

	David Hyatt
	Comment 19 • 24 years ago

Ok, my fix is in.  I'm reassigning to you, peterl, to investigate the Mac 
problem.  I'm happy to give you as many cycles of my time as you need to help 
figure out why the Mac doesn't respond to the fix.

One theory I have is that on Mac only maybe we're leaking the document viewer 
of the previous page, which causes the previous viewer widget not to be 
destroyed (and so it might paint on top of the widget that holds the plugin).

A possible patch to see if this is what's going on would be to call Hide() on 
the viewer passed in to SetPreviousViewer (if the previous viewer passed in is 
non-null).  If this fixes the problem, then it means we have a leak on the Mac 
only.

	Peter Lubczynski Assignee
	Comment 20 • 24 years ago

That's strange. Seem to be working much better on my Mac today than when I tried
the patch last week. I'll check this out with Monday morning's commercial bits.

	Peter Lubczynski Assignee
	Comment 21 • 24 years ago

Marking FIXED..please open if you don't think so.

	shrirang khanzode Reporter
	Comment 22 • 24 years ago

Verified this is fixed. Testcase url laods and also tried a few other 
plugins/tests. (0516)