Closed Bug 390290 Opened 17 years ago Closed 17 years ago

Adobe Reader 8.1 plugin performs illegal operation with rebranded user-agent string

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 328778

People

(Reporter: araemo, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Powercamel/2.0.0.6 (All your Firefox/2.0.0.6 are belong to Firesomething)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Powercamel/2.0.0.6 (All your Firefox/2.0.0.6 are belong to Firesomething)

Since upgrading to Adobe Reader 8.1, any attempt to load a PDF inside a firefox browser window results in a window stating that the plug-in has performed an illegal operation.

Reproducible: Always

Steps to Reproduce:
1. Install Adobe Reader 8.1
2. Attempt to view a PDF inside the browser window.
3. Error message
Actual Results:  
Error message is displayed, PDF file is not rendered.

Expected Results:  
Use the plugin to view the PDF file in the browser window.

This has happened on 3 differently configured Windows XP machines I have tested on.  I have attempted completely uninstalling both firefox and Adobe Reader, cleaning out their registry entries, and installing both from scratch, w/ a fresh firefox profile.  I get the same results.

I know of no way to tell if this is a problem with Firefox, or adobe reader, so I am reporting it both to Mozilla and Adobe.
Exact error message is:
"The plug-in performed an illegal operation.  You are strongly advised to restart Firefox."

It has a 'do not show again in this session' checkbox, and an OK button.  If I just click ok, it shows one more time, and then after clicking OK a second time, the page is blank.

View source shows the PDF file data.
Through much further testing, I have found, I believe, the real cause of this error.  However, it confuses me, because it didn't start giving me a problem until I updated to Adobe Reader 8.1.

I have used firesomething for several years, I think it's humorous and it's something people always comment on when they use my computer.

However, since Adobe Reader 8.1(8.0 worked fine), and, as I found out today, Java JRE 1.6.0, the 'rebrand user-agent string' option has been causing my issues.  I always enabled the comment containing the real firefox version, to allow web stats to be more accurate.  Any time I had the "All your #name#/#version# are belong to Firesomething" comment enabled, I had issues with adobe reader 8.1 and Java 1.6.0_u1 and _u2.

Using a shorter comment allows both plugins to work properly.  

So, Is this a bug in:
1: firefox, passing the info to the plugins wrong
2: the plugins, not being able to handle a too-long user-agent
or
3: the extension, that it is breaking specs by altering the user-agent to be too long?

As an aside: Disabling the extension does NOT remove the changes to the user-agent field.  So starting in safe-mode doesn't effect this bug any.  I would imagine this is a firefox bug, but I suppose the extension could be at fault here too?
So, retuned steps to reproduce:
1: Install Mozilla Firefox (2.0.0.x, release versions)
2: Install Adobe Reader 8.1
3: Install firesomething
4: Configure firesomething to rebrand user agent string, and set the comment to "All your #name#/#version# are belong to Firesomething"
5: IMPORTANT: restart firefox ( the plugins seem to read the user-agent string only on firefox startup?  Changes in user-agent in firesomething are reflected immediately in the help->about window, but the plugin behavior is unchanged until a restart.)
6: view a PDF w/ firefox
7: Adobe reader performs an illegal operation
8: Restart firefox 
9: clear the 'user-agent string comment' in firesomething options (But rebranding the user-agent string alone is ok)
10: restart firefox
11: View a PDF w/ firefox
12: No error, PDF displays fine.
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Bug 83376 is for similar problem of Sun Java plugin. When newer version of Java, crash doesn't seem to occur.

Please add explanation about "User Agent string change" in bug summary, for ease of search / understanding of problem.
Summary: Adobe Reader 8.1 plugin performs illegal operation → Adobe Reader 8.1 plugin performs illegal operation with rebranded user-agent string
For those people who want to test without Firesomething installed, you can also override the User-Agent under about:config with the pref general.useragent.override.
Stacktrace:
0:000> kp
ChildEBP RetAddr  
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f4c4 07255f4b MSVCR80_7280000!strlen+0x30
*** WARNING: Unable to verify checksum for F:\MOZILLA\TREE-C~1\MOZILLA\OBJSUITE\DIST\BIN\components\gkplugin.dll
0012f4f4 04ff87b6 nppdf32!NP_ApolloEntry+0x4a68
0012f568 04ff97fe gkplugin!ns4xPluginInstance::InitializePlugin(class nsIPluginInstancePeer * peer = 0x0b7a6930)+0x1b8 [f:\mozilla\tree-cvsmo\mozilla\modules\plugin\base\src\ns4xplugininstance.cpp @ 1083]
0012f570 050044d6 gkplugin!ns4xPluginInstance::Initialize(class nsIPluginInstancePeer * peer = 0x7c920732)+0x13 [f:\mozilla\tree-cvsmo\mozilla\modules\plugin\base\src\ns4xplugininstance.cpp @ 854]
0012f8a8 04fffed2 gkplugin!nsPluginHostImpl::TrySetUpPluginInstance(char * aMimeType = 0x0420c280 "application/pdf", class nsIURI * aURL = 0x0453b210, class nsIPluginInstanceOwner * aOwner = 0x0b899ef0)+0x472 [f:\mozilla\tree-cvsmo\mozilla\modules\plugin\base\src\nspluginhostimpl.cpp @ 4035]
0012f8f0 05008292 gkplugin!nsPluginHostImpl::SetUpPluginInstance(char * aMimeType = 0x0420c280 "application/pdf", class nsIURI * aURL = 0x0453b210, class nsIPluginInstanceOwner * aOwner = 0x0b899ef0)+0x21 [f:\mozilla\tree-cvsmo\mozilla\modules\plugin\base\src\nspluginhostimpl.cpp @ 3855]
*** WARNING: Unable to verify checksum for F:\MOZILLA\TREE-C~1\MOZILLA\OBJSUITE\DIST\BIN\components\gklayout.dll
0012f994 01964b0a gkplugin!nsPluginHostImpl::InstantiateFullPagePlugin(char * aMimeType = 0x0420c280 "application/pdf", class nsIURI * aURI = 0x0453b210, class nsIStreamListener ** aStreamListener = 0x0012f9c4, class nsIPluginInstanceOwner * aOwner = 0x0b899ef0)+0x105 [f:\mozilla\tree-cvsmo\mozilla\modules\plugin\base\src\nspluginhostimpl.cpp @ 3654]
0012f9c8 01966a3a gklayout!nsObjectFrame::InstantiatePlugin(class nsIPluginHost * aPluginHost = 0x040838d4, char * aMimeType = 0x0420c280 "application/pdf", class nsIURI * aURI = 0x0453b210)+0x64 [f:\mozilla\tree-cvsmo\mozilla\layout\generic\nsobjectframe.cpp @ 764]
0012f9f8 01a4e524 gklayout!nsObjectFrame::Instantiate(char * aMimeType = 0x0420c280 "application/pdf", class nsIURI * aURI = 0x0453b210)+0x84 [f:\mozilla\tree-cvsmo\mozilla\layout\generic\nsobjectframe.cpp @ 1418]
*** WARNING: Unable to verify checksum for F:\MOZILLA\TREE-C~1\MOZILLA\OBJSUITE\DIST\BIN\components\docshell.dll
0012fa18 020592ab gklayout!nsPluginStreamListener::OnStartRequest(class nsIRequest * request = 0x042ee4a4, class nsISupports * ctxt = 0x00000000)+0x84 [f:\mozilla\tree-cvsmo\mozilla\content\html\document\src\nsplugindocument.cpp @ 121]
*** WARNING: Unable to verify checksum for F:\MOZILLA\TREE-C~1\MOZILLA\OBJSUITE\DIST\BIN\components\necko.dll
0012fb74 01014aba docshell!nsDocumentOpenInfo::OnStartRequest(class nsIRequest * request = 0x042ee4a4, class nsISupports * aCtxt = 0x00000000)+0x360 [f:\mozilla\tree-cvsmo\mozilla\uriloader\base\nsuriloader.cpp @ 345]
0012fba0 01016e03 necko!nsHttpChannel::CallOnStartRequest(void)+0x16d [f:\mozilla\tree-cvsmo\mozilla\netwerk\protocol\http\src\nshttpchannel.cpp @ 732]
0012fc10 01017bda necko!nsHttpChannel::ProcessNormal(void)+0x178 [f:\mozilla\tree-cvsmo\mozilla\netwerk\protocol\http\src\nshttpchannel.cpp @ 908]
0012fc20 01017c7c necko!nsHttpChannel::ProcessResponse(void)+0x22a [f:\mozilla\tree-cvsmo\mozilla\netwerk\protocol\http\src\nshttpchannel.cpp @ 832]
0012fc30 00fce7f7 necko!nsHttpChannel::OnStartRequest(class nsIRequest * request = 0x04133efc, class nsISupports * ctxt = 0x0b823360)+0x9a [f:\mozilla\tree-cvsmo\mozilla\netwerk\protocol\http\src\nshttpchannel.cpp @ 4241]
0012fc4c 00fcea36 necko!nsInputStreamPump::OnStateStart(void)+0x39 [f:\mozilla\tree-cvsmo\mozilla\netwerk\base\src\nsinputstreampump.cpp @ 443]
*** WARNING: Unable to verify checksum for F:\MOZILLA\TREE-C~1\MOZILLA\OBJSUITE\DIST\BIN\xpcom_core.dll
0012fc5c 0029b996 necko!nsInputStreamPump::OnInputStreamReady(class nsIAsyncInputStream * stream = 0x0b823360)+0x3e [f:\mozilla\tree-cvsmo\mozilla\netwerk\base\src\nsinputstreampump.cpp @ 405]
0012fc6c 002a8c9b xpcom_core!nsInputStreamReadyEvent::Run(void)+0x1c [f:\mozilla\tree-cvsmo\mozilla\xpcom\io\nsstreamutils.cpp @ 112]
0012fc8c 0027b1b2 xpcom_core!nsThread::ProcessNextEvent(int mayWait = 1, int * result = 0x0012fca8)+0xc3 [f:\mozilla\tree-cvsmo\mozilla\xpcom\threads\nsthread.cpp @ 491]
*** WARNING: Unable to verify checksum for F:\MOZILLA\TREE-C~1\MOZILLA\OBJSUITE\DIST\BIN\components\gkwidget.dll
0012fca0 014dadd1 xpcom_core!NS_ProcessNextEvent_P(class nsIThread * thread = 0x00000001, int mayWait = 1)+0x27 [f:\mozilla\tree-cvsmo\mozilla\objsuite\xpcom\build\nsthreadutils.cpp @ 227]

The limit seems to be at 127 chars for the U-A, at 128 chars it crashes.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The problem is this here with a 128 chars U-A:
0[bb4d00]: NPN_UserAgent: npp=58f9e5c
0[bb4d00]: nsPluginHostImpl::UserAgent return=(null)

Seems like we pass a null U-A to the plugin if the U-A is too long. Looks like that limit was introduced in Bug 58095 to prevent a leak.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.