234169 - Asgard plugin crash - FF10PR1 [@ 0x00000330 | 0x5653784e - PL_DHashTableOperate ]

Status: RESOLVED FIXED

(Core :: Security: CAPS, defect)

Description

[Roy Hoerauf]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

Firefox crashes when loading a specific page.  This page loads ok in Firebird
0.7.  The page is a subscriber access only page from www.investors.com.  After
loging in, select a stock and request a IDBchart.  A new window opens and starts
to load.  Then I get the WinXP error pop-up.  When clicking to see what the
error report contains, the following information is dispalyed; "AppName:
firefox.exe	 AppVer: 0.8.0.0	 ModName: unknown
ModVer: 0.0.0.0	 Offset: 5653784e".

When the Debug button is clicked, I get an Application Error that states that
"The instruction at "0x5653784e" referenced memory at "0x5653784e".  The memmory
could not be "read"."

The page is a graph of a stock (it does not matter which stock is requested). 
This always happens.  This has been a complete clean install of Firefox with a
new profile with no extensions loaded.

I have saved the information from the error message and have saved the page
itself as a html file that exhibits the same problem when load the file. 
However, in this case, the crash occures immediately.  I will attatch these
files to the bug report.


Reproducible: Always
Steps to Reproduce:
1.
2.
3.




about:buildconfig

Build platform
target
i686-pc-cygwin

Build tools
Compiler 	Version 	Compiler flags
$(CYGWIN_WRAPPER) cl 	12.00.8804 for 80x86 	-TC -nologo -W3 -nologo -Gy
-Fd$(PDBFILE)
$(CYGWIN_WRAPPER) cl 	12.00.8804 for 80x86 	-TP -nologo -W3 -nologo -Gy
-Fd$(PDBFILE) -I/usr/X11R6/include

Configure arguments
--disable-ldap --disable-mailnews
--enable-extensions=cookie,xml-rpc,xmlextras,p3p,pref,transformiix,universalchardet,typeaheadfind,webservices
--enable-crypto --disable-composer --disable-profilesharing --disable-installer
--disable-debug --enable-optimize --disable-tests --enable-static --disable-shared

Comment 1

[Roy Hoerauf]

Attachment: WinXP error information file

Information generated but WinXP when requesting to send error report.

Comment 2

[Roy Hoerauf]

Attachment: Save html page that crashes Firefox

This is a saved html page.  The page was saved when viewing the page using
Firebird 0.7

Comment 3

[José Jeria]

Also crashing with build 20040213, Windows XP.
though not when loading the page, neither when leaving it, it crashes when i
shut down the browser.

Comment 4

[Jason Barnabe (np)]

Confirming.

Comment 5

[Frederic Bezies]

Got no crash with a very young build, one I made from yesterday source which
were up to date at midnight mozilla.org time (Mozilla/5.0 (Windows; U; Windows
NT 5.1; en-US; rv:1.7b) Gecko/20040329 Firefox/0.8.0+ (MozJF))

Reporter : can you try with a young nightly build, please ? You can find it here :

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Your bug could have been fixed since 0.8 release.

Thanks.

Comment 6

[Roy Hoerauf]

Tested using the 20040329 nightly build with a clean install and the saved HTML
page.  Did not experence the crash.  (I can not test using the live page as it
is a paid subscription only page and I no longer subscribe to it.)

Changing the resolution to FIXED.  If this problem occures in the next release
of Firefox, I will reopen it.

thanks

Roy

Comment 7

[Roy Hoerauf]

I have re-subscribed to www.investors.com where this problem is happening. 
Using the nightly Firefox build dated 11 Apr 2004. I can always re-produce this
problem.

I am re-opening this problem.

I am also attaching a new capture of the page where this crash is happening. 
The page was saved by using the File - Save Page As command (complete web page)
on the Menu bar.

Comment 8

[Roy Hoerauf]

Attachment: Update HTML page that crashes Firefox

Comment 9

[Roy Hoerauf]

This is still a problem on Firefox 0.9rc1  (Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.8.0+)

Comment 10

[Roy Hoerauf]

This is still a problem on Firefox 0.9.1.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1

Comment 11

[Roy Hoerauf]

A plug-in is needed to attempt to loading the page.  It can be found at
"http://www.investors.com/service/ns_firstinstall.asp".  After installing the
plug-in, attempting to open the html file that is attached to this bug will
immediately crash Firefox.

Comment 12

[Roy Hoerauf]

This bug is keeping me from upgrading to Firefox from Firebird 0.7.  Is there
any body actually looking at this?  Do I need to provide more information or
something?  Please let me know.

Roy

Comment 13

[Adam Hauner]

Roy: Could you provide Talkback incident ID of this crash? Maybe it should help.

Comment 14

[Roy Hoerauf]

Attachment: Talkback report for this bug

Talkback report for Bug 234169.

Comment 15

[Roy Hoerauf]

Happy to oblige.  I presume that I get the Talkback incident ID in a email back
to me after I submit the incident, if not, please let me know how to get it.  (I
did include me return e-mail address on the incident report.)  I will include it
when I get the email.  In any case I am attaching the saved copy of the report.
 If there is something else I can do to help you all out, please let me know.

Roy

Comment 16

[Adam Hauner]

Roy, to get the Talkback ID go to your Firefox directory and go to components/,
there start talkback.exe, it'll give you a list with the IDs.

Comment 17

[Roy Hoerauf]

The Talkback incident ID for a crash when at the web site is TB237464K.  I also
generated a second one using the html file attached to the Bug report
(dgoGraphs_01.htm) just in case there is any difference bewteen crashing using
the html file and the actual web site (which is a subscriber only site).  The
Talkback incident ID for a crash when using the html file is TB243670X. I hope
this helps.

Roy 

Comment 18

[Adam Hauner]

Roy: Due to a recent Talkback database upgrade aren't older incidents available.
Could I ask you again for TalkBack incident ID? I do apologize for complication.

Comment 19

[Roy Hoerauf]

Talkback ID TB337630Y.  (Attempting to load the previously attached web page -
dgoGraphs_01.htm.)

Comment 20

[Adam Hauner]

TB337630Y:
0x5653784e
PL_DHashTableOperate 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/xpcom/ds/pldhash.c,
line 490]
nsScriptSecurityManager::LookupPolicy 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 990]
nsScriptSecurityManager::CheckPropertyAccessImpl 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 603]
nsScriptSecurityManager::CheckPropertyAccess 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/caps/src/nsScriptSecurityManager.cpp,
line 460]
nsDOMClassInfo::doCheckPropertyAccess 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/dom/src/base/nsDOMClassInfo.cpp,
line 3074]
nsWindowSH::AddProperty 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/dom/src/base/nsDOMClassInfo.cpp,
line 3265]
XPC_WN_Helper_AddProperty 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 796]
js_DefineNativeProperty 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c,
line 2310]
js_DefineProperty 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c,
line 2223]
js_DefineFunction 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/js/src/jsfun.c,
line 1987]
JS_InitClass 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c,
line 1913]
js_InitDateClass 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/js/src/jsdate.c,
line 1986]
JS_ResolveStandardClass 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c,
line 1389]
nsWindowSH::NewResolve 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/dom/src/base/nsDOMClassInfo.cpp,
line 4120]
XPC_WN_Helper_NewResolve 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 929]
js_LookupProperty 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c,
line 2423]
js_GetProperty 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c,
line 2611]
JS_GetProperty 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c,
line 2489]
npaxctrl.dll + 0x7632 (0x02e57632)
0x01b2fe44
XPC_WN_NoCall_JSOps

Christopher, stack looks same as in your bug 217967. Reporter is also able to
reproduce.

Jay, there are many Mozilla and Firefox Windows crashes on www.investor.com, all
are similar, except probably unrelated 307055 and 312792, in some comments
ActiveX is mentioned:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=url&match=contains&searchfor=www.investors.com

-> Browser/Security: CAPS (as Mozilla 1.7 also crashes)

Comment 21

[chris hofmann]

jay, can you check out the ranking for this crash?

Comment 22

[Jay Patel [:jay]]

The one stack signature that we have identified for this crash (0x5653784e) is
currently the 60th overall crash in 0.9.1 (all platform) and ranked 30th for
0.9.2 (Windows only). 

Seeing that almost all of the crashes are at investors.com, and people have been
crashing with the testcase here, I'm marking this a topcrash+.

Comment 23

[Daniel Veditz [:dveditz]]

re-nominating for 1.0, this is a top crash.

Comment 24

[chris hofmann]

any updates on a fix?

Comment 25

[Daniel Veditz [:dveditz]]

This page requires the Asgard ActiveX-wrapper plugin to repro the crash. You can
get an eval copy from the Asgard site, but you have to then edit the plugin MIME
type before the page will load, then boom.

The plugin is referencing the js Date class which causes its construction.
dpolicy in nsScriptSecurityManager::LookupPolicy appears to be garbage.

Comment 26

[Daniel Veditz [:dveditz]]

Rather than save this example off I've been accessing it through the URL
jar:https://bugzilla.mozilla.org/attachment.cgi?id=145935&action=view!/dgoGraphs_01.htm

LookupPolicy() is trying to find a DomainEntry for
"cgi?id=145935&action=view!/dgoGraphs_01.htm" -- something's seriously not right
here. This is not the source of this crash, but the dot-counting loop needs
fixing. Better to use the standard URI routines for picking pieces apart -- or
do we have to worry about the principal origin not being a URI? If it can't find
a domain entry it falls back on a scheme, but in this case thinks it's "jar:"
instead of https.

Comment 27

[Roy Hoerauf]

Attachment: Asgard ActiveX-wrapper plugin

This is the Asgard ActiveX-wrapper plugin that is needed.  Place the
npaxctrl.dll file in the Firefox plugin directory.

Comment 28

[Jason Barnabe (np)]

(In reply to comment #27)
> Created an attachment (id=160488)
> Asgard ActiveX-wrapper plugin
> 
> This is the Asgard ActiveX-wrapper plugin that is needed.  Place the
> npaxctrl.dll file in the Firefox plugin directory.

Are you sure you need this to crash? Because when I tried it at first I crashed,
and I definitely didn't have that plugin.

I'm not crashing anymore on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.3) Gecko/20040925 Firefox/0.10 (without the plugin)

Comment 29

[Daniel Veditz [:dveditz]]

If you crashed WITHOUT the plugin then that must be a different bug. The stack
in this bug (comment 20) clearly shows npaxctlr.dll is part of the scenario.

Comment 30

[Roy Hoerauf]

The crash that I opened, and is described in this bug report, requires this
plugin.  I don't know anything about your system so I won't speculate about the
crash you experenced.

When I do a clean install of Firefox, with a new profile, and go the the
investor.com web site and attempt to open the page that has the crash, I will be
prompted to install this plugin.  The web page has a script that checks for this
plugin if you are running a Mozilla based web browser.  Without doing anything
else execpt putting the dll file in the plugin directory, the web page will now
load, and of course, crash.  (The actual web page is a subscriber only page so
unless you pay your money for this, you will not be able to access the live web
page.)

Comment 31

[Son Le]

Hopefully this can help someone with more knowledge of the system.

I fired up the debugger and had a go at tracing the code to see if I could
figure out what could be causing this crash. Traced as far as
InstantiateEmbededPlugin() and just as the plugin was about to be created, a
npaxctrl.dll!NSCanUnload() event triggered a change in security policy -
SetSecurityPolicy(0x0012bbd4).

In amidst this, the page was being rendered with a security policy of
0x02794f50, but after the security policy was changed, the next security policy
check call caused firefox to crash.

I don't know what caused the npaxctrl.dll!NSCanUnload() to occur or if the
change in policy was correct or not.

Anyway, here's the call stack:

 	firefox.exe!nsPrincipal::SetSecurityPolicy(void * aSecurityPolicy=0x0012bbd4)
 Line 206	C++
 	npaxctrl.dll!NSCanUnload()  + 0x1a2e bytes	
 	firefox.exe!nsPluginNativeWindowWin::CallSetWindow(nsCOMPtr<nsIPluginInstance>
& aPluginInstance={...})  Line 390	C++
 	firefox.exe!nsPluginHostImpl::InstantiateEmbededPlugin(const char *
aMimeType=0x0313cd70, nsIURI * aURL=0x02fb5aa0, nsIPluginInstanceOwner *
aOwner=0x030e5500)  Line 3437	C++
 	firefox.exe!nsObjectFrame::InstantiatePlugin(nsIPresContext *
aPresContext=0x025f7330, nsHTMLReflowMetrics & aMetrics={...}, const
nsHTMLReflowState & aReflowState={...}, nsIPluginHost * aPluginHost=0x01d4978c,
const char * aMimeType=0x0313cd70, nsIURI * aURI=0x02fb5aa0)  Line 1479 + 0x1e
bytes	C++
 	firefox.exe!nsObjectFrame::Reflow(nsIPresContext * aPresContext=0x025f7330,
nsHTMLReflowMetrics & aMetrics={...}, const nsHTMLReflowState &
aReflowState={...}, unsigned int & aStatus=0)  Line 1321 + 0x2d bytes	C++
 	firefox.exe!nsLineLayout::ReflowFrame(nsIFrame * aFrame=0x03145b04, unsigned
int & aReflowStatus=0, nsHTMLReflowMetrics * aMetrics=0x00000000, int &
aPushedFrame=0)  Line 992 + 0x2b bytes	C++
 	firefox.exe!nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & aState={...},
nsLineLayout & aLineLayout={...}, nsLineList_iterator aLine={...}, nsIFrame *
aFrame=0x03145b04, unsigned char * aLineReflowStatus=0x0012c6df)  Line 3578 +
0x16 bytes	C++
 	firefox.exe!nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState &
aState={...}, nsLineLayout & aLineLayout={...}, nsLineList_iterator aLine={...},
int * aKeepReflowGoing=0x0012ce1c, unsigned char * aLineReflowStatus=0x0012cbaf,
int aUpdateMaximumWidth=0, int aDamageDirtyArea=1)  Line 3445 + 0x20 bytes	C++
 	firefox.exe!nsBlockFrame::DoReflowInlineFramesAuto(nsBlockReflowState &
aState={...}, nsLineList_iterator aLine={...}, int *
aKeepReflowGoing=0x0012ce1c, unsigned char * aLineReflowStatus=0x0012cbaf, int
aUpdateMaximumWidth=0, int aDamageDirtyArea=1)  Line 3346 + 0x2e bytes	C++
 	firefox.exe!nsBlockFrame::ReflowInlineFrames(nsBlockReflowState &
aState={...}, nsLineList_iterator aLine={...}, int *
aKeepReflowGoing=0x0012ce1c, int aDamageDirtyArea=1, int aUpdateMaximumWidth=0)
 Line 3290 + 0x24 bytes	C++
 	firefox.exe!nsBlockFrame::ReflowLine(nsBlockReflowState & aState={...},
nsLineList_iterator aLine={...}, int * aKeepReflowGoing=0x0012ce1c, int
aDamageDirtyArea=1)  Line 2455 + 0x21 bytes	C++
 	firefox.exe!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState={...})
 Line 2097 + 0x1f bytes	C++
 	firefox.exe!nsBlockFrame::Reflow(nsIPresContext * aPresContext=0x025f7330,
nsHTMLReflowMetrics & aMetrics={...}, const nsHTMLReflowState &
aReflowState={...}, unsigned int & aStatus=0)  Line 815 + 0xf bytes	C++
 	firefox.exe!nsBlockReflowContext::ReflowBlock(const nsRect & aSpace={...}, int
aApplyTopMargin=0, nsCollapsingMargin & aPrevBottomMargin={...}, int
aIsAdjacentWithTop=1, nsMargin & aComputedOffsets={...}, nsHTMLReflowState &
aFrameRS={...}, unsigned int & aFrameReflowStatus=0)  Line 546 + 0x2a bytes	C++
 	firefox.exe!nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & aState={...},
nsLineList_iterator aLine={...}, int * aKeepReflowGoing=0x0012d9d4)  Line 3068 +
0x35 bytes	C++
 	firefox.exe!nsBlockFrame::ReflowLine(nsBlockReflowState & aState={...},
nsLineList_iterator aLine={...}, int * aKeepReflowGoing=0x0012d9d4, int
aDamageDirtyArea=1)  Line 2334 + 0x1b bytes	C++
 	firefox.exe!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState={...})
 Line 2097 + 0x1f bytes	C++
 	firefox.exe!nsBlockFrame::Reflow(nsIPresContext * aPresContext=0x025f7330,
nsHTMLReflowMetrics & aMetrics={...}, const nsHTMLReflowState &
aReflowState={...}, unsigned int & aStatus=0)  Line 815 + 0xf bytes	C++
 	firefox.exe!nsBlockReflowContext::ReflowBlock(const nsRect & aSpace={...}, int
aApplyTopMargin=1, nsCollapsingMargin & aPrevBottomMargin={...}, int
aIsAdjacentWithTop=1, nsMargin & aComputedOffsets={...}, nsHTMLReflowState &
aFrameRS={...}, unsigned int & aFrameReflowStatus=0)  Line 546 + 0x2a bytes	C++
 	firefox.exe!nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & aState={...},
nsLineList_iterator aLine={...}, int * aKeepReflowGoing=0x0012e58c)  Line 3068 +
0x35 bytes	C++
 	firefox.exe!nsBlockFrame::ReflowLine(nsBlockReflowState & aState={...},
nsLineList_iterator aLine={...}, int * aKeepReflowGoing=0x0012e58c, int
aDamageDirtyArea=1)  Line 2334 + 0x1b bytes	C++
 	firefox.exe!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState={...})
 Line 2097 + 0x1f bytes	C++
 	firefox.exe!nsBlockFrame::Reflow(nsIPresContext * aPresContext=0x025f7330,
nsHTMLReflowMetrics & aMetrics={...}, const nsHTMLReflowState &
aReflowState={...}, unsigned int & aStatus=0)  Line 815 + 0xf bytes	C++
 	firefox.exe!nsContainerFrame::ReflowChild(nsIFrame * aKidFrame=0x030890d0,
nsIPresContext * aPresContext=0x025f7330, nsHTMLReflowMetrics &
aDesiredSize={...}, const nsHTMLReflowState & aReflowState={...}, int aX=0, int
aY=0, unsigned int aFlags=0, unsigned int & aStatus=0)  Line 967 + 0x1f bytes	C++
 	firefox.exe!CanvasFrame::Reflow(nsIPresContext * aPresContext=0x025f7330,
nsHTMLReflowMetrics & aDesiredSize={...}, const nsHTMLReflowState &
aReflowState={...}, unsigned int & aStatus=0)  Line 554	C++
 	firefox.exe!nsBoxToBlockAdaptor::Reflow(nsBoxLayoutState & aState={...},
nsIPresContext * aPresContext=0x025f7330, nsHTMLReflowMetrics &
aDesiredSize={...}, const nsHTMLReflowState & aReflowState={...}, unsigned int &
aStatus=0, int aX=0, int aY=0, int aWidth=14985, int aHeight=10995, int
aMoveFrame=1)  Line 880	C++
 	firefox.exe!nsBoxToBlockAdaptor::DoLayout(nsBoxLayoutState & aState={...}) 
Line 626 + 0x2e bytes	C++
 	firefox.exe!nsBox::Layout(nsBoxLayoutState & aState={...})  Line 1016	C++
 	firefox.exe!nsScrollBoxFrame::DoLayout(nsBoxLayoutState & aState={...}) 
Line 337	C++
 	firefox.exe!nsBox::Layout(nsBoxLayoutState & aState={...})  Line 1016	C++
 	firefox.exe!nsContainerBox::LayoutChildAt(nsBoxLayoutState & aState={...},
nsIBox * aBox=0x03076754, const nsRect & aRect={...})  Line 650 + 0x10 bytes	C++
 	firefox.exe!nsGfxScrollFrameInner::LayoutBox(nsBoxLayoutState & aState={...},
nsIBox * aBox=0x03076754, const nsRect & aRect={...})  Line 1262 + 0x11 bytes	C++
 	firefox.exe!nsGfxScrollFrameInner::Layout(nsBoxLayoutState & aState={...}) 
Line 1418	C++
 	firefox.exe!nsGfxScrollFrame::DoLayout(nsBoxLayoutState & aState={...})  Line
1270 + 0xf bytes	C++
 	firefox.exe!nsBox::Layout(nsBoxLayoutState & aState={...})  Line 1016	C++
 	firefox.exe!nsBoxFrame::Reflow(nsIPresContext * aPresContext=0x025f7330,
nsHTMLReflowMetrics & aDesiredSize={...}, const nsHTMLReflowState &
aReflowState={...}, unsigned int & aStatus=0)  Line 868	C++
 	firefox.exe!nsGfxScrollFrame::Reflow(nsIPresContext * aPresContext=0x025f7330,
nsHTMLReflowMetrics & aDesiredSize={...}, const nsHTMLReflowState &
aReflowState={...}, unsigned int & aStatus=0)  Line 870 + 0x19 bytes	C++
 	firefox.exe!nsContainerFrame::ReflowChild(nsIFrame * aKidFrame=0x0307660c,
nsIPresContext * aPresContext=0x025f7330, nsHTMLReflowMetrics &
aDesiredSize={...}, const nsHTMLReflowState & aReflowState={...}, int aX=0, int
aY=0, unsigned int aFlags=0, unsigned int & aStatus=0)  Line 967 + 0x1f bytes	C++
 	firefox.exe!ViewportFrame::Reflow(nsIPresContext * aPresContext=0x025f7330,
nsHTMLReflowMetrics & aDesiredSize={...}, const nsHTMLReflowState &
aReflowState={...}, unsigned int & aStatus=0)  Line 248 + 0x2b bytes	C++
 	firefox.exe!IncrementalReflow::Dispatch(nsIPresContext *
aPresContext=0x025f7330, nsHTMLReflowMetrics & aDesiredSize={...}, const nsSize
& aMaxSize={...}, nsIRenderingContext & aRendContext={...})  Line 901	C++
 	firefox.exe!PresShell::ProcessReflowCommands(int aInterruptible=1)  Line 6387	C++
 	firefox.exe!ReflowEvent::HandleEvent()  Line 6212	C++
 	firefox.exe!HandlePLEvent(ReflowEvent * aEvent=0x03139380)  Line 6226	C++
 	xpcom.dll!PL_HandleEvent(PLEvent * self=0x03139380)  Line 673 + 0xa bytes	C
 	xpcom.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x01cd6598)  Line 608
+ 0x9 bytes	C
 	xpcom.dll!_md_EventReceiverProc(HWND__ * hwnd=0x001e05d6, unsigned int
uMsg=49399, unsigned int wParam=0, long lParam=30238104)  Line 1414 + 0x9 bytes	C
 	user32.dll!GetDC()  + 0x72 bytes	
 	user32.dll!GetDC()  + 0x154 bytes	
 	user32.dll!GetWindowLongW()  + 0x127 bytes	
 	user32.dll!DispatchMessageW()  + 0xf bytes	
 	firefox.exe!nsAppShell::Run()  Line 135	C++
 	firefox.exe!nsAppShellService::Run()  Line 495	C++
 	firefox.exe!xre_main(int argc=1, char * * argv=0x01778bc8, const nsXREAppData
* aAppData=0x010de060)  Line 1907 + 0x23 bytes	C++
 	firefox.exe!main(int argc=1, char * * argv=0x01778bc8)  Line 58 + 0x12 bytes	C++
 	firefox.exe!mainCRTStartup()  Line 398 + 0x11 bytes	C
 	kernel32.dll!RegisterWaitForInputIdle()  + 0x49 bytes	

Comment 32

[Jay Patel [:jay]]

Adding FF10PR1 and 0x00000330 to summary for tracking.  These crashes continue
to show up in the latest Firefox 1.0 PR1 release under both "0x5653784e" and
"0x00000330" stack signatures.

Almost all of the incidents mention investors.com (which I'm guessing requires
the plugin in question here).  I also see dailygraphs.com and some mention of
shutterfly.com in the comments/urls.

Comment 33

[Roy Hoerauf]

dailygraphs.com is really part of investors.com and should be treated together.
 I do not know any thing about shutterfly.com.

Comment 34

[Daniel Veditz [:dveditz]]

Shutterfly.com is a digital-photo printing site like ofoto. They provide their
own software for uploading photos that possibly uses this or a similar
plugin--or maybe not.

Comment 35

[Brian Ryner (not reading)]

(In reply to comment #31)
> I don't know what caused the npaxctrl.dll!NSCanUnload() to occur or if the
> change in policy was correct or not.
> 
> Anyway, here's the call stack:
> 
>  	firefox.exe!nsPrincipal::SetSecurityPolicy(void * aSecurityPolicy=0x0012bbd4)
>  Line 206	C++
>  	npaxctrl.dll!NSCanUnload()  + 0x1a2e bytes	
>  	firefox.exe!nsPluginNativeWindowWin::CallSetWindow(nsCOMPtr<nsIPluginInstance>
> & aPluginInstance={...})  Line 390	C++
>  	firefox.exe!nsPluginHostImpl::InstantiateEmbededPlugin(const char *
> aMimeType=0x0313cd70, nsIURI * aURL=0x02fb5aa0, nsIPluginInstanceOwner *
> aOwner=0x030e5500)  Line 3437	C++

One thing is fairly clear; the pointer being passed to
nsPrincipal::SetSecurityPolicy is not a DomainPolicy object.  Whether it's some
other (valid) object, or a bogus pointer, I have no idea.  I have my doubts that
the plugin is even intending to call this function.

caillon's merging of the principal objects was one of the big changes in this
area between Firefox 0.7 and 0.8.  It could be that the plugin was depending on
one of those unfrozen API's.

I don't really know a lot about what's happening when CallSetWindow is called...
I assume it is getting mapped onto some ActiveX interface method.  cc'ing Adam,
maybe he can help.

Comment 36

[Brian Ryner (not reading)]

(In reply to comment #35)
> caillon's merging of the principal objects was one of the big changes in this
> area between Firefox 0.7 and 0.8.  It could be that the plugin was depending on
> one of those unfrozen API's.

Unfortunately, changing the nsIPrincipal iid (which should have been done when
the change landed) doesn't help.  It's probably getting the nsIPrincipal via a
path that doesn't QI.

I think our two options here are:

- Say that this is the plugin's fault for using an unfrozen API, and do nothing
on our end.
- Hack up a compatibility interface for nsIPrincipal (the current interface
could inherit from it).


> 
> I don't really know a lot about what's happening when CallSetWindow is called...
> I assume it is getting mapped onto some ActiveX interface method.  cc'ing Adam,
> maybe he can help.

Comment 37

[Brian Ryner (not reading)]

Attachment: horrible hack-fix

This patch makes the vtable layout of nsIPrincipals compatible with the old
version that this plugin expects.  This would be a bad precedent I'm sure, I'm
just putting it here in case we decide this is high enough visiblity to warrant
a bandaid like this.  This does fix the crash for me.

Comment 38

[Roy Hoerauf]

I just downloaded and installed Netscape 7.2 and am getting the same crash.  

Comment 39

[Brian Ryner (not reading)]

(In reply to comment #38)
> I just downloaded and installed Netscape 7.2 and am getting the same crash.  

Right, the affected interface changed awhile ago.  The plugin does not work in
Mozilla 1.6a or newer, Firefox 0.8 or newer, or Netscape 7.2.

Comment 40

[Bernard Alleysson]

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

Comment 41

[chris hofmann]

do we have anything that would allow blacklisting that plugin?

Comment 42

[Daniel Veditz [:dveditz]]

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

Comment 43

[Daniel Veditz [:dveditz]]

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

Comment 44

[Daniel Veditz [:dveditz]]

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

Comment 45

[Daniel Veditz [:dveditz]]

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

Comment 46

[Daniel Veditz [:dveditz]]

Firefox supports browser.download.pluginOverrideTypes but it didn't stop the
crash when I added application/x-pw-oleobject to it. There's a button that
brings up a list of plugins that can be disabled, but the asgard plugin types
don't show up on it.

The Suite appears not to have anything like either feature. If we shipped a
pre-filled default (assuming I did something wrong and it does actually work)
 1) users would not be able to use this plugin if they ever did fix it
 2) it wouldn't fix any existing user who happened to have disabled some
    other plugin and therefore had a user-pref overriding any default
    we shipped (rare case, I'm sure).

Comment 47

[Darin Fisher]

> Unfortunately, changing the nsIPrincipal iid (which should have been done when
> the change landed) doesn't help.  It's probably getting the nsIPrincipal via a
> path that doesn't QI.

can we figure out what that code path is?  maybe we can change a UUID further up
the interface chain?

Comment 48

[Daniel Veditz [:dveditz]]

They've got the string @mozilla.org/scriptsecuritymanager in their .dll, there
are lots of methods off that to get a nsIPrincipal. They've also got
@mozilla.org/js/src/ContextStack -- what kind of scary shit are they doing?

Comment 49

[Daniel Veditz [:dveditz]]

According to http://www.asgardsw.com/welcome.htm they made their plugin work for
quite a range of versions. Maybe they've got version-specific hacks in their
code and could add one for newer Mozillas.

Comment 50

[Johnny Stenback (:jst)]

Attachment: Disable any plugin that supports "application/x-pw-oleobject "

This adds trivial and straight forward support for disabling any plugin that
supports any of a pref-controlled list of mimetypes, and defaults the list to
blocking plugins that support "application/x-pw-oleobject".

Comment 51

[Johnny Stenback (:jst)]

Oh, and this makes it so that Firefox doesn't see the plugin at all. If you go
to a page that uses this plugin, then you'll be presented with the normal
missing plugin UI etc.

Comment 52

[Darin Fisher]

> Oh, and this makes it so that Firefox doesn't see the plugin at all. If you go
> to a page that uses this plugin, then you'll be presented with the normal
> missing plugin UI etc.

I'm not too keen on shipping our product with this whitelist.  It only means
that future versions of this plugin will be forced to change their mime type. 
Instead, why don't we change the UUID of any interface that has getters or
methods that return instances of nsIPrincipal?  Does that mean
nsIScriptSecurityManager?  That would still cause the plugin to be disabled in
Firefox 1.0, but it would give the vendor the opportunity to use QueryInterface
to detect the changed interfaces.

Put in another way: It seems to me that if nsIBar has a nsIFoo getter, then any
change to nsIFoo is in effect a change to the interface contract of nsIBar.

Ben points out that some users may appreciate the whitelist (since you could use
it to easily disable a plugin), but I'm not so sure that we should ship a
default whitelist unless the plugin is hopelessly busted.

Comment 53

[Darin Fisher]

oops.. when i said 'whitelist' i really meant 'blacklist' :-)

brendan mentioned that a future version of the installer for this plugin could
clear the mime type from the blacklist.  that's not a great solution because it
means that users must always run the installer for this plugin after installing
a new version of firefox.  since this plugin is using unfrozen interfaces, it's
likely that we will face this very same problem again in the future.  but, if
future versions of this plugin ship with an install step that undoes the
blacklist, then what would we do? :-(

Comment 54

[Bernard Alleysson]

This bug should probably be mentioned into the release notes

Comment 55

[Darin Fisher]

reopening, as i did not mean to mark this bug fixed

Comment 56

[Daniel Veditz [:dveditz]]

I revved all the uuid's in caps, as well as nsIJSContextStack (referenced inside
the plugin). Still crashes, but in a new spot (null pointer de-ref):

npaxctrl.dll!04fc64c7() 	
npaxctrl.dll!04fd3c2b() 	
npaxctrl.dll!04fc62be() 	
npaxctrl.dll!04fc82f9() 	
npaxctrl.dll!04fc5f8d() 	

gkplugin.dll!nsPluginNativeWindow::CallSetWindow(nsCOMPtr<nsIPluginInstance> &
aPluginInstance={...})  Line 97	C++
 
gkplugin.dll!nsPluginNativeWindowWin::CallSetWindow(nsCOMPtr<nsIPluginInstance>
& aPluginInstance={...})  Line 397	C++

gkplugin.dll!nsPluginHostImpl::InstantiateEmbededPlugin(const char *
aMimeType=0x0012c2b4, nsIURI * aURL=0x00000000, nsIPluginInstanceOwner *
aOwner=0x0012c200)  Line 3425	C++

xpcom.dll!nsCSubstring::MutatePrep(unsigned int capacity=, char * * oldData=,
unsigned int * oldFlags=)  Line 72	C++

Comment 57

[Daniel Veditz [:dveditz]]

Attachment: asgard "clock" sample

Comment 58

[Daniel Veditz [:dveditz]]

Attachment: asgard minesweep example

Comment 59

[Daniel Veditz [:dveditz]]

As mentioned, revving all the uuids in caps merely moved the crash.

An mentioned before bryner's hack definitely stops the crash. I thought I had
been unsuccessful when I tried it before, but I just retested it on some of
asgard's sample files and they seem to work as well as they do in Moz 1.4. 

I'd say let's land bryner's ugly hack, it stops most of the pain.

When I try the investor.com example
jar:https://bugzilla.mozilla.org/attachment.cgi?id=145935&action=view!/dgoGraphs_01.htm
I don't get any content though, maybe because I'm not a subscriber or because
the page is loaded from bugzilla instead of the investor site. I do get a bunch
of asserts:

CSS Error
(jar:https://bugzilla.mozilla.org/attachment.cgi?id=145935&action=view!/dgoGraphs_01.htm
:6.23): Unknown pseudo-class or pseudo-element 'visted'.  Selector expected.
Ruleset ignored due to bad selector.
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
c:/dev/aviary/mozilla/dom/src/base/nsDOMClassInfo.cpp, line 6762
For application/x-pw-oleobject found plugin
C:\dev\aviary\mozilla\obj-dbg\dist\bin\plugins\npaxctrl.dll
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
c:/dev/aviary/mozilla/dom/src/base/nsDOMClassInfo.cpp, line 6762
For application/x-pw-oleobject found plugin
C:\dev\aviary\mozilla\obj-dbg\dist\bin\plugins\npaxctrl.dll
###!!! ASSERTION: need to implement cancel when downloading: '!mIsPending', file
c:/dev/aviary/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp, line 310
###!!! ASSERTION: need to implement cancel when downloading: '!mIsPending', file
c:/dev/aviary/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp, line 310
###!!! ASSERTION: need to implement cancel when downloading: '!mIsPending', file
c:/dev/aviary/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp, line 310
###!!! ASSERTION: need to implement cancel when downloading: '!mIsPending', file
c:/dev/aviary/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp, line 310
###!!! ASSERTION: need to implement cancel when downloading: '!mIsPending', file
c:/dev/aviary/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp, line 310
###!!! ASSERTION: need to implement cancel when downloading: '!mIsPending', file
c:/dev/aviary/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp, line 310
###!!! ASSERTION: need to implement cancel when downloading: '!mIsPending', file
c:/dev/aviary/mozilla/netwerk/protocol/jar/src/nsJARChannel.cpp, line 310
###!!! ASSERTION: unable to remove temp file: 'Error', file
c:/dev/aviary/mozilla/netwerk/base/src/nsDownloader.cpp, line 82
###!!! ASSERTION: unable to remove temp file: 'Error', file
c:/dev/aviary/mozilla/netwerk/base/src/nsDownloader.cpp, line 82
###!!! ASSERTION: unable to remove temp file: 'Error', file
c:/dev/aviary/mozilla/netwerk/base/src/nsDownloader.cpp, line 82

In my \tmp I get three copies of a zip archive containing chart GIFs. When
retesting I get the jar assertions but not the nsDownloader ones, and I don't
see any new files in \tmp.

So bryner's hack is *almost* enough to get investors.com back on the air.

Comment 60

[Don Calderwood]

I replyed to an email yesterday from Daniel Veditz about this "bug" but my 
point seems to have been lost so I will try to clarify. I work for the company 
that developed the plugin in question. I will post my email to Daniel below 
but let me mention a couple of things.

I looked into our usage of Mozilla interfaces as it stands in NS 7.2 and you 
will not get it to work without some serious pain. There are several 
interfaces that have had methods added in the middle of the vtable, there are 
methods that have had parameters added (again in the middle of the parameter 
list) and there is at list one interface we use extensively that has been 
removed. I have already been in contact with Investors Business Daily and told 
them we are no longer supporting NS or Mozilla.

BTW, in my email I lamented the fact that over the years nobody from Mozilla 
would ever respond to me. Well, I never heard back from Daniel either.

>>>original email to Daniel Veditz
First let me express my disappointment to you about the Mozilla group. We have 
had this product on the market for 3 or 4 years and whenever you guys would 
change an interface and cause us to blow up,  I would send an email to the 
person that made the change. Your email  is the first time that we have 
received any response from someone at Mozilla. If we could have worked 
together this might have had a better ending.
 
Even the discussion about this bug is interesting from a third party 
developer's point of view. The last I looked everyone was trying to figure out 
how to "blacklist" our plugin.
 
As you have surmised, we are using interfaces. While I wasn't the original 
developer, I can only assume that we believed that your implementation of 
XPCOM was similar in practice to Microsoft's implementation of COM. In this 
regard, we expected that when an interface is developed and given a UUID, it 
cannot be modified. If you want to add or change methods you have to make a 
new interface with a new UUID. Unfortunately, this is not how Mozilla works. 
You assume that everyone that uses your interfaces are being compiled with 
your sources as part of your normal build. You are certainly allowed to make 
this decision but the question becomes, why didn't you just use classes 
instead of going to all the trouble to make interfaces? Everytime you change 
an interface you have the potential need to make source level changes to 
handle it anyway.
 
I just finished examining what had changed in our use of your interfaces 
relative to NS 7.2 and the corresponding Mozilla. I was amazed at the number 
of changes you have made. To list a few, several methods had parameter 
changes, interfaces with new or removed methods in the middle of the vtable, 
interfaces that have been removed, defines that have been changed. I estimated 
that it would take about a month to get our product working with the new 
version.
 
Also, our goal was to have a single plugin that handled all NS versions and we 
succeeded for awhile. I have come to the conclusion that the only way to 
continue support would be to have a different version of the plugin for each 
supported NS and Mozilla release. This would be a giant pain.
 
So, we have basically decided that it isn't feasible to support your browser 
for the expected return. We might rethink this if Mozilla were to ever capture 
a large share of the browser market.
 
As you noticed Investors Business Daily is the biggest user. We have already 
notified them and I expect they will put a condition version check in to 
control the loading of our plugin. As our other clients contact us we will be 
informing them of our decision and recommending that they modify their HTML 
pages. 

Comment 61

[Christian :Biesinger (don't email me, ping me on IRC)]

er, it certainly _is_ mozilla policy to change the UUID of interfaces that get
changed.

Comment 62

[Brendan Eich [:brendan]]

Don: I'm sorry you didn't get replies to any of your prior emails.  If there are
any active owners around who ignored you, and you're inclined to try to improve
the situation, please let me know and I'll talk to them.  This is the first I've
heard from you about it, and [e-mail] is the known court of appeal
here, so sauce for the goose....

I'm also sorry you assumed something not true of either MS COM or XP COM -- that
any interface in a large system is by definition frozen.  The documentation at
http://www.mozilla.org/projects/embedding/, in particular
http://www.mozilla.org/projects/embedding/HowToFreeze.html, talks at length
about our process for making interfaces FROZEN.  We went to a fair amount of
trouble calling out interfaces that we promised not to change, on the road to
Mozilla 1.0, and since then.

We didn't freeze enough interfaces for everyone to do interesting things on the
platform, and I'm sorry for that too, but it was a calculated trade-off.  We had
to re-build killer apps first, platform second, for Mozilla 1.0 and especially
for Firefox and Thunderbird.

We're not as flush with cash as MS, so we could not pull off the "platform *and*
applications" dessert-topping/floor-polish, two-hard-things-at-once trick before
now.  But we are going to finish the platform for Mozilla 2.0, so I hope you'll
come back and give us a chance to make good.  We will certainly make sure to
change IIDs for all interfaces, frozen or not, when those interfaces change
materially -- in fact shaver has a patch to automate this via xpidl.

/be

Comment 63

[Brendan Eich [:brendan]]

> So, we have basically decided that it isn't feasible to support your browser
> for the expected return. We might rethink this if Mozilla were to ever capture
> a large share of the browser market.

Parting shot: Firefox (perhaps you haven't heard of it?) is gaining market share
rapidly.  If it's not in your interest to support it, so be it.  But after
making appropriate reforms on both sides [*], I continue to hope that we might
work together better in the future, for mutual advantage.

/be

[* We promise to rev IIDs for all interfaces that change, and to freeze more
interfaces.  You (Don and all embedders and plugin authors) promise to read the
embedding docs and pay attention to @status doc-comments, or lack of FROZEN
status or any status, in IDL; and to complain to [e-mail] and the
newsgroups if you get no answer from a particular committer about a change that
breaks you.]

Comment 64

[Daniel Veditz [:dveditz]]

biesi: It may be our *policy* to rev UUID's, but in practice you know that we've
been way too lax enforcing it in the past. It's getting better though.

Comment 65

[chris hofmann]

think we are going to try and test bryner's hack and put it on the branch if it
checks out.

Comment 66

[Darin Fisher]

> think we are going to try and test bryner's hack and put it on the branch if it
> checks out.

this is equivalent to 'punting' on the problem.  that may be appropriate given
how close we are to the release date, but if we ever want to change nsIPrincipal
in the future, we will have to revisit this problem.

i still wish we could figure out how asgard is getting ahold of nsIPrincipal and
cut them off before they get it.  oh well :-(

Comment 67

[Daniel Veditz [:dveditz]]

Attachment: less horrible restoration patch

Really only one of the old APIs is obsolete, replaced by a method with an
additional argument. With a little rearranging, and ignoring the fact that the
names changed, all the new stuff is now at the end.

Comment 68

[Daniel Veditz [:dveditz]]

Comment on attachment 163082 [details] [diff] [review]
less horrible restoration patch

>+    void setCommonName(in string);

This needs an argument name, sorry.

Comment 69

[Brian Ryner (not reading)]

Attachment: alternate fix

This patch factors out nsIPrincipalObsolete, as we discussed in the aviary
meeting today.

A couple of things I found out:
- The plugin is getting the nsIPrincipal via nsIScriptObjectPrincipal. 
Changing the iid of that interface doesn't make the crash go away though, and I
didn't track that down further.
- Once it has the nsIPrincipal, it wants to pass it to
nsIScriptSecurityManager::CanExecuteScripts(), which means the pointer is at
the wrong offset if the method expects the nsIPrincipal pointer and is passed a
nsIPrincipalObsolete.  So, I made nsIScriptSecurityManagerObsolete as well,
which deals with nsIPrincipalObsolete objects.

I'm not entirely convinced this is the best approach, but it seems a little
cleaner than the previous patch.

Comment 70

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 163082 [details] [diff] [review]
less horrible restoration patch

Hm, ok.  This is risky since if someone used this unfrozen API before it
changed (over a year ago I think), it is also likely that someone has used it
since it changed, especially since there was a Preview Release made with it. 
People probably are getting their plugins ready for 1.0.

Because of that, I'm more in favor of adding the backwards compatible API that
bryner posted.	That said, I'll review this anyway.

The only comment I have other than the earlier comment about how I think this
is bad this late in the game is that we definitely need some NS_NOTREACHED
assertions in the stub implementations.

Comment 71

[Johnny Stenback (:jst)]

Comment on attachment 163114 [details] [diff] [review]
alternate fix

sr=jst

Comment 72

[Asa Dotzler [:asa]]

Comment on attachment 163114 [details] [diff] [review]
alternate fix

a=asa for branches checkins.

Comment 73

[Daniel Veditz [:dveditz]]

Comment on attachment 163114 [details] [diff] [review]
alternate fix

r=dveditz

Comment 74

[Daniel Veditz [:dveditz]]

Checked in fix for bryner trying to make today's builds, although I may have
missed it now. Sorry, fell asleep waiting for my build to finish so I could test.

Comment 75

[Steven Michaud [:smichaud] (Retired)]

The patch mentioned in comment #69 has gotten into Firefox 1.0RC1,
correct?  (I see the files nsIPrincipalObsolete.idl and
nsIScriptSecurityManagerObsolete.idl in its source tarball's caps/idl
directory).

In any case, the design change that led to the addition of these files
breaks Mozilla.org's MRJ Plugin Carbon
(http://www.mozilla.org/oji/MRJPluginCarbon.html).  Below I'll suggest
a change to your patch that would (I think) unbreak the MRJ Plugin
Carbon and still meet your requirements.

Maybe I should open a separate bug about this.  But I thought it'd be
best for me to post a heads-up here first.

The MRJ Plugin Carbon's CSecureEnv::sendMessageToJava() method (in its
CSecureEnv.cpp file) looks up the browser's "scriptsecuritymanager"
service and calls the GetSubjectPrincipal() method on its
nsIScriptSecurityManager interface.  This returns an nsIPrincipal
object.  Then in GetLiveConnectProxy(JNIEnv *, nsIPrincipal *) it
calls the nsIPrincipal object's GetOrigin() method to obtain the
object's "codebase".  This has worked for eons, and continued to work
after a major change in the nsIPrincipal interface between Mozilla 1.5
and Mozilla 1.6.  But with the new patch, the MRJ Plugin Carbon now
crashes at the call to GetOrigin().

The problem is that, when the MRJ Plugin Carbon uses GetService() to
look up the "scriptsecuritymanager" service by name and IID, it uses
the "old" IID.  So now (in Firefox 1.0RC1) it gets the "Obsolete"
service, which returns an nsIPrincipalObsolete object ... which
doesn't have a GetOrigin() method.

Mozilla 1.5's nsIPrincipal interface didn't have an "origin" attribute
(or a GetOrigin() method) either.  But nsPrincipal had then (as it
does now) a GetOrigin() method, and somehow calling GetOrigin on an
nsIPrincipal object "just worked".  When, with Mozilla 1.6,
nsIPrincipal acquired an "origin" attribute, calling GetOrigin()
continued to work ... just (presumably) in a new way.

From comments in the new nsIPrincipalObsolete.idl and
nsIScriptSecurityManagerObsolete.idl files, they're meant to address
backwards compatibility with pre-Mozilla 1.6 browsers.  That's a fine
idea.  But the way you've gone about making the change, you've broken
not only apps that (pre-Mozilla-1.6) used "unofficial" elements of the
nsIPrincipal interface (which you may not care about), but also ones
that (from the release of Mozilla 1.6 until now) used elements that
were officially part of the interface (which you should care about).

I suggest that, where possible, you make available in
nsIPrincipalObsolete.idl all the features that were available in
nsIPrincipal.idl from Mozilla 1.6 days until the present.  Apps that
are only interested in the pre-1.6 interface won't know about them and
won't care.  Apps that are interested in the interface as it stood
from the release of Mozilla 1.6 until now will no longer be broken.

(By the way, I'm not officially involved with the MRJ Plugin Carbon,
or even connected with Mozilla.org.  I'm the developer of something
called the Java Embedding Plugin (http://javaplugin.sourceforge.net),
which uses a fixed-up version of the MRJ Plugin Carbon to work with
Mozilla-family browsers.  Most of my fixes have been for LiveConnect
bugs.  I became aware of the GetOrigin() problem while investigating a
bug report from somebody using the OS X distro of Firefox 1.0RC1.  The
GetOrigin() problem has an easy workaround (I look up the
"scriptsecuritymanager" service first by the "new" IID, and only if I
don't find it do I look it up by the "old" IID).  So I'm not really
concerned about my own product.  But I thought you guys should know
about this.)

Comment 76

[Darin Fisher]

this really underscores the need to provide a frozen set of 'caps' interfaces.

Comment 77

[Frank]

(In reply to comment #74)
> Checked in fix for bryner trying to make today's builds, although I may have
> missed it now. Sorry, fell asleep waiting for my build to finish so I could test.
I'm coming in at the tail end and swimming in waters way over my head.  Could I
ask the simple question - does the thing work?  As of today I am getting crashes
on Investor.com using Win2000 and XP.  The bug "messenger" isn't working either.

Just started using Mozilla and am feeling my way around.

Thanks

Comment 78

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #77)

As far as I know, the only Mozilla-family browser that currently has
the fix discussed here (the one that broke the MRJ Plugin Carbon but
also (hopefully) fixed problems with the Asgard plugin) is Firefox
1.0RC1.  The Windows US English version installer can be downloaded
at:

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.0rc1/Firefox%20Setup%20(1.0rc1,%20en-US).exe

That's what you should be testing with (if you aren't already).

Comment 79

[Daniel Veditz [:dveditz]]

fix checked into the 1.7 branch for 1.7.5

Comment 80

[Brian Ryner (not reading)]

I'm not sure what we should do about this now going forward.  dveditz, others,
thoughts?

Comment 81

[Darin Fisher]

Is there someone at Asgard with whom we can discuss this?  It seems like it'd be
ideal if we could work with someone there to arrive at a better solution.

Comment 82

[David Humphreys]

(In reply to comment #81)
> Is there someone at Asgard with whom we can discuss this?  It seems like it'd be
> ideal if we could work with someone there to arrive at a better solution.

Don at Asgard Software - see Comment #60...

Comment 83

[timeless]

that bounces, it's possible he's no longer at asgardsw, anyone want to spend
cell  phone time calling tech support?

Comment 84

[David Humphreys]

(In reply to comment #83)
> that bounces, it's possible he's no longer at asgardsw, anyone want to spend
> cell  phone time calling tech support?

Try [e-mail]

Comment 85

[Brian Ryner (not reading)]

Comment on attachment 163082 [details] [diff] [review]
less horrible restoration patch

unsetting this request since we decided to go with a different fix.

Comment 86

[Wayne Mery (:wsmwk)]

Darin in comment #81
> Is there someone at Asgard with whom we can discuss this?  

[e-mail] advises "we took the PluginWizard product off the market about 4 years ago."