Launch Mozilla, browse to http://mediacast.sun.com/share/leon/JDSR3GAG_8190919_d4.pdf. When you are using proxy, acroread appears to start (as mozilla plugin) but nothing is displayed. When you access the page directly or save this pdf to local file and open if, the document successfully opens in mozilla's acroread plugin. This bug only happened on linux and solaris, not on windows.
The problem I found it here: http://lxr.mozilla.org/seamonkey/source/modules/plugin/base/src/nsPluginHostImpl.cpp#6617 6603 mInstance->Stop(); 6604 mInstance->Start(); .................................. 6617 ((nsPluginNativeWindow*)window)->CallSetWindow(inst); In ns4xPluginInstance::Stop, mozilla destoried mXtBin, but not window->ws_info. So in ns4xPluginInstance::SetWindow mXtBin is null, but window->ws_info is not null. This is not a correct situration. This bug maybe related to bug 94895 and Bug 119494.
Thanks, Leon. Giving to jst to track for 1.8b3. /be
Leon, can you please capture a HTTP log? Instructions here: http://www.mozilla.org/projects/netlib/http/http-debugging.html Thanks!
Before I get these logs, I apply the temp patch for bug 246560.
Darin, can you see anything obvious in these logs?
darin will look at as soon as he gets over the hump on updater and other stuff.
This bug has more critical impact to users, steps to reproduce: 1. Start Mozilla. 2. Open a new tab and go to the following link: http://java.sun.com/j2ee/1.4/docs/tutorial/doc/J2EETutorial.pdf [BUG:the file can't display in browser] 3. Open another tab and go to http://www.sina.com.cn [page load successfully] 4. Go back to the previous page and reload the page. [PDF file displays correctly] 5. Close this tab either by right clicking the tab and selecting 'close tab' or by clicking the X at the right upper corner. [BUG:Mozilla crash; if you did close www.sina.com.cn tab instead of PDF tab, go back to PDF tab, the PDF contents disappears.] But this bug didn't happen to all the PDF files. It only happens to a small part of PDF files. Unfortunately, we have not find which kind of PDF files cause this bug. We tried 193 PDF files, only 5 had this problem. Test files can be found in the following link: http://acroeng.adobe.com/file_elements.html
Thanks for the extra details on reproducing this bug. I plan to fix this for Firefox 1.1 beta.
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050704 Firefox/1.0+ (stipe) Windows XP SP2 + Acrobat Reader 7.02
(In reply to comment #11) > WFM > > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050704 > Firefox/1.0+ (stipe) > > Windows XP SP2 + Acrobat Reader 7.02 This bug only happened in linux/unix.
Darin, do you think that a fix here will be isolated and low-risk?
I have no idea. I haven't had time to investigate this bug yet. I could certainly use help.
Do we have a stacktrace for the crash? I don't think this is going to make 1.5 without someone coming up with a very safe patch in the next few days. If that happens, please request approval at the patch flag.
Leon: can you please explain why this patch fixes the bug?
(In reply to comment #17) > Leon: can you please explain why this patch fixes the bug? > http://lxr.mozilla.org/seamonkey/source/modules/plugin/base/src/nsPluginHostImpl.cpp#6662 After mInstance->Stop(), mXtBin has been destoried. The fact is we does not really want to destory mXtbin here. If mXtbin needs to be destoried, mInstance->Destory() should be called. So I just move the destory mXtbin part to mInstance->Destory().
I think Leon has a promising patch here. jst should sr. /be
I really don't understand this code at all. What is mXtBin? ns4xPluginInstance::Destroy says that destruction happens in ::Stop. Was the original author just wrong about that? Is there some better way to destroy mXtBin in Stop that does not cause this bug? I really don't know this code well enough to say with any certainty that "yeah, this is the proper fix."
this patch is only for the second half of the summary, right?
(In reply to comment #20) > I really don't understand this code at all. What is mXtBin? > ns4xPluginInstance::Destroy says that destruction happens in ::Stop. Was the > original author just wrong about that? Is there some better way to destroy > mXtBin in Stop that does not cause this bug? I really don't know this code Maybe we can do this. Just not use mInstance->Stop() here. In nsPluginStreamListenerPeer::ServeStreamAsFile we just need to clean up the streams, so we give it a method to clean up the streams and do not use mInstance->Stop(). > well enough to say with any certainty that "yeah, this is the proper fix." >
(In reply to comment #21) > this patch is only for the second half of the summary, right? > I don't quite understand you meaning.
(In reply to comment #23) > I don't quite understand you meaning. It doesn't fix "Mozilla cannot open PDF document via proxy", does it?
we should release note the save and open in standalone viewer workaround.
Created attachment 207056 [details] [diff] [review] Patch v2 This is a more reasonable patch. Since mXtBin is destroied, I create a new one here.
Comment on attachment 207056 [details] [diff] [review] Patch v2 >Index: nsPluginHostImpl.cpp >+#if defined (MOZ_WIDGET_GTK) || defined (MOZ_WIDGET_GTK2) >+ // Should call GetPluginPort() here. Why aren't we calling GetPluginPort() then? Aagin, I'm not very comfortable reviewing this code because I don't know what it is doing. Isn't there someone who knows these APIs better?
blizzard, caillon, maybe bryner? shaver, any thoughts? /be
(In reply to comment #27) > (From update of attachment 207056 [details] [diff] [review] ) > >Index: nsPluginHostImpl.cpp > > >+#if defined (MOZ_WIDGET_GTK) || defined (MOZ_WIDGET_GTK2) > >+ // Should call GetPluginPort() here. > > Why aren't we calling GetPluginPort() then? > GetPluginPort() is not an interface of nsIPluginInstanceOwner. It is just a function of nsPluginInstanceOwner. > Aagin, I'm not very comfortable reviewing this code because I > don't know what it is doing. Isn't there someone who knows > these APIs better? I agree with you. It is better to have someone familiar with this module to review this.
Comment on attachment 207056 [details] [diff] [review] Patch v2 sr=shaver
Checking in base/src/ns4xPluginInstance.cpp; /cvsroot/mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp,v <-- ns4xPluginInstance.cpp new revision: 1.132; previous revision: 1.131 done Checking in base/src/nsPluginHostImpl.cpp; /cvsroot/mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp,v <-- nsPluginHostImpl.cpp new revision: 1.550; previous revision: 1.549 done