133567 - skeeter-s.com - M1RC3; Crash because Adobe SVG plugin used an unfrozen interface [@ nsLoadGroup::GetName] [@ nsHttpChannel::GetName] which changed its prototype

Status: VERIFIED INVALID

(External Software Affecting Firefox :: Other, defect)

Description

[Steve]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.9+) Gecko/20020323
BuildID:    2002 03 23 20

On a Windows SVG enabled build  #2002 04 23 I'm getting a general crash
involving the neck.dll that completly crashes Mozilla.
This is only on embeded SVG, openning svg files either local or from the net
work fine.
http://www.skeeter-s.com/svg/cute-lyon.htm crashes

http://www.skeeter-s.com/svg/svgimages/lion.svg doesn't

I've also got an Mozilla 0.9.9 without SVG enabled except for the plugin and it
works fine in both cases.



Reproducible: Always
Steps to Reproduce:
1.Go to any site with embeded SVG and have the correct files in the plugin
folder:* NPSVG3.dll * NPSVG3.zip
2. Try to view an embeded SVG
3. It crashes everytime.


Expected Results:  In earlier Mozilla's and in Mozilla 0.9.9 release SVGs that
are embeded can be viewed using the Adobe SVG Viewer plugin with no problem.

I'm usíng a

Mozilla 0.9.9+
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.9+) Gecko/20020323

SVG-Mathml zip, hence not a talkback.



-- 
steve
http://www.skeeter-s.com/svg
SVG examples for Mozilla unplugged

Comment 1

[Steve]

Spelled that wrong. it is the

necko.dll 

that reports a violation and crashes Mozilla

Comment 2

[Matthias Versen [:Matti]]

-> Networking

Comment 3

[Adam Hauner]

Confirming crash with 2002032503 and 2002032603/Win2K (in necko!NSGetModule?).

Stephen, should I ask you for TB4520438Q or TB4520480X?

Comment 4

[Adam Hauner]

BTW also crashing on Adobe's pages (using SVG Viewer 3.0 plugin for Netscape): 
http://www.adobe.com/svg/demos/main.html

Comment 5

[[e-mail] (gone - use [e-mail] instead)]

nsLoadGroup::GetName
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsLoadGroup.cpp, line 173]
NPSVG3.dll + 0x42a1 (0x530042a1)
NPSVG3.dll + 0x3d3b (0x53003d3b)
NPSVG3.dll + 0x51f8 (0x530051f8)
nsPluginStreamListenerPeer::SetUpStreamListener
[d:\builds\seamonkey\mozilla\modules\plugin\base\src\nsPluginHostImpl.cpp, line
2447]
nsPluginStreamListenerPeer::OnStartRequest
[d:\builds\seamonkey\mozilla\modules\plugin\base\src\nsPluginHostImpl.cpp, line
2075]
nsHttpChannel::ProcessNormal
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 587]
nsHttpChannel::ProcessResponse
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 547]
nsHttpChannel::OnStartRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 2561]
nsOnStartRequestEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 162]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 524]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1072]
USER32.DLL + 0xe215 (0x77e1e215)
USER32.DLL + 0xe4bb (0x77e1e4bb)
USER32.DLL + 0x27207 (0x77e37207)
NPSVG3.dll + 0x11163 (0x53011163)
NPSVG3.dll + 0x4750 (0x53004750)
USER32.DLL + 0x2e98 (0x77e12e98)
USER32.DLL + 0x30e0 (0x77e130e0)
USER32.DLL + 0x5824 (0x77e15824)
nsAppShellService::Run
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 309]
main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1366]
main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1701]
WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1719]
WinMainCRTStartup()
KERNEL32.DLL + 0x17d08 (0x77e97d08) 

Comment 6

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

crashes on linux, too

Comment 7

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

useful stack trace:
#0  0x40a8a0e0 in nsACString::Truncate (this=0xbfffea18, aNewLength=0) at
../../../../dist/include/string/nsAString.h:505
#1  0x40a08767 in nsLoadGroup::GetName (this=0x859e208, result=@0xbfffea18) at
/part2/mozilla/netwerk/base/src/nsLoadGroup.cpp:172
#2  0x421cc70f in SVGPluginInstance::tryNN6xScriptEngine () from
/usr/lib/adobesvg/adobesvg-3.0/libNPSVG3.so
#3  0x421cbefd in SVGPluginInstance::initEmbedTag () from
/usr/lib/adobesvg/adobesvg-3.0/libNPSVG3.so
#4  0x421cde1a in SVGPluginStreamListener::OnStartBinding () from
/usr/lib/adobesvg/adobesvg-3.0/libNPSVG3.so
#5  0x417173ff in nsPluginStreamListenerPeer::SetUpStreamListener
(this=0x86ac648, request=0x86ac710, aURL=0x86d7488)
    at /part2/mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp:2479
#6  0x41715b5c in nsPluginStreamListenerPeer::OnStartRequest (this=0x86ac648,
request=0x86ac710, aContext=0x0)
    at /part2/mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp:2110
#7  0x40a6456d in nsHttpChannel::ProcessNormal (this=0x86ac710) at
/part2/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp:593
#8  0x40a63e61 in nsHttpChannel::ProcessResponse (this=0x86ac710) at
/part2/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp:495
#9  0x40a6cee8 in nsHttpChannel::OnStartRequest (this=0x86ac710,
request=0x868e1fc, ctxt=0x0)
    at /part2/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp:2735
#10 0x40a9cc69 in nsOnStartRequestEvent::HandleEvent (this=0x42009f80) at
/part2/mozilla/netwerk/base/src/nsRequestObserverProxy.cpp:161
#11 0x40a0f573 in nsARequestObserverEvent::HandlePLEvent (plev=0x42009f80) at
/part2/mozilla/netwerk/base/src/nsRequestObserverProxy.cpp:115
#12 0x4021cbec in PL_HandleEvent (self=0x42009f80) at
/part2/mozilla/xpcom/threads/plevent.c:596
#13 0x4021c9e9 in PL_ProcessPendingEvents (self=0x80cae68) at
/part2/mozilla/xpcom/threads/plevent.c:526
#14 0x4021edef in nsEventQueueImpl::ProcessPendingEvents (this=0x80cae40) at
/part2/mozilla/xpcom/threads/nsEventQueue.cpp:388
#15 0x413af8b4 in event_processor_callback (data=0x80cae40, source=6,
condition=GDK_INPUT_READ)
    at /part2/mozilla/widget/src/gtk/nsAppShell.cpp:184
#16 0x413af446 in our_gdk_io_invoke (source=0x8260f00, condition=G_IO_IN,
data=0x8323ef8) at /part2/mozilla/widget/src/gtk/nsAppShell.cpp:77
#17 0x404dabd4 in g_io_add_watch () from /usr/lib/libglib-1.2.so.0
#18 0x404dc390 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#19 0x404dc96f in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#20 0x404dcb2b in g_main_run () from /usr/lib/libglib-1.2.so.0
#21 0x403ec6e3 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#22 0x413aff35 in nsAppShell::Run (this=0x8108f58) at
/part2/mozilla/widget/src/gtk/nsAppShell.cpp:364
#23 0x41351574 in nsAppShellService::Run (this=0x8100350) at
/part2/mozilla/xpfe/appshell/src/nsAppShellService.cpp:308
#24 0x0805c585 in main1 (argc=1, argv=0xbffff3f4, nativeApp=0x0) at
/part2/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1383
#25 0x0805d253 in main (argc=1, argv=0xbffff3f4) at
/part2/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1732
#26 0x406305b0 in __libc_start_main () from /lib/libc.so.6
(gdb) print *this
$1 = {_vptr.nsACString = 0x0}

Comment 8

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

ok... I have an idea what happened...
The last checkin to that file was done by darin and did, besides other things,
do this: (it was for bug 128508 "freeze nsIChannel nsIRequest". Hm, this is the
 second regression from that checkin that I stumble over...)
--- netwerk/base/src/nsLoadGroup.cpp	2002/01/16 00:16:51	1.55
+++ netwerk/base/src/nsLoadGroup.cpp	2002/03/20 22:49:57	1.56
@@ -164,12 +164,12 @@
 // nsIRequest methods:
 
 NS_IMETHODIMP
-nsLoadGroup::GetName(PRUnichar* *result)
+nsLoadGroup::GetName(nsACString &result)
 {
     // XXX is this the right "name" for a load group?
 
     if (!mDefaultLoadRequest) {
-        *result = nsnull;
+        result.Truncate();
         return NS_OK;
     }
     
Now, I suppose *result is a PRUnichar* in the Adobe plugin, and set to zero. The
string code, though, doesn't seem to like that. Or maybe it is interpreted as
the vtable. I'm not sure how to interpret this output of the debugger:
$1 = {_vptr.nsACString = 0x0}

Anyway. This is the reason for the crash. The fix is not clear. I don't think we
can change the type of the parameter back to PRUnichar**...

CC'ing darin who caused this regression.

Comment 9

[Darin Fisher]

looks like this is an evangelism bug... Adobe should not have been using an
unfrozen mozilla API.

-> evangelism

Comment 10

[Steve]

Hi
At the moment as I write this in a 'non' functional SVG Mozilla i.e. it crashes
if I try to view an embeded SVG file in a html doc, I've got Mozilla 0.9.9 open
(using the same profile. 
It doesn't crash, also if the SVG isn't embeded then the Abode Plugin works fine
in both browsers.
http://www.w3.org/Graphics/SVG/Test/20011026/shapes-rect-BE-01-cmpnav.svg
Can be view in both.
While this page:
http://www.w3.org/Graphics/SVG/Test/20011026/shapes-rect-BE-01-ps.html
can only be viewed in the Mozilla 0.9.9. This page has the SVG embeded and
crashes: Mozilla 0.9.9+
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.9+) Gecko/20020323

Hope that helps

Comment 11

[Darin Fisher]

looks like i didn't reassign this bug properly...

Comment 12

[Adam Hauner]

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

Comment 13

[Steve]

Hi

Sorry, but the sounds like a copout, two weeks ago it was working fine, in the
release Mozilla o.9.9 it is working fine, in NS 6x it is working fine. Hence,
Adobe hasn't changed anything to something that now doesn't work Mozilla, and if
that is the attitude that this is Adobe's fault (yes I have also read this at
the bug report) thing it looks like we can kiss SVG as a plugin in Mozilla. Plus
in all future NS, I can't believe it. What is next, tell Apple that QuickTime is
wrong(works fine now, but what if Mozilla breaks again)

Hello, is anyone out there? The #3 viewer from Adobe has been out now for
months, it hasn't changed.

Comment 14

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

This is Adobe's fault. An internal Mozilla API has changed now. We never
guaranteed that this API would remain as-is - it was an unfrozen API. This means
that it could change at any time, which has happened now.

Now that the API is frozen, we guarantee to never change it, so that future
plugins will work with all future releases of Netscape and Mozilla.

Comment 15

[Chak Nanga]

Hi Arun : Is Adobe familiar with this api change? If not, could you please make
this issue known to them so that they can now start using the frozen API..Thanks

Comment 16

[Steve]

Tell me please that this is an April Fools Joke. Mozilla and Netscape can forget
about SVG that is sweeping the net until Adobe corrects their error and they
should bring out a new # four plugin. Scrape their #5 Acrobat Reader (it is now
installing the SVG viewer). Scrape their new Paint Shop #7, Change their GoLive
program, do I really need to go on?

Thanks a lot, are you trying to drive off long time users? What is next.
Sorry, but if you are incharge of doing this to Mozilla, then who do you really
work for?

This is an April Fools joke, right?

Comment 17

[Matthias Versen [:Matti]]

[e-mail]:
Be quiet if you don't know why this bug is evangelism.
You can also start a discussion why mozilla 0.9.1 Themes doesn't work in
Mozilla0.9.9
Go to the newsgroups if you want discuss stupid stuff like this but don't SPAM
people here.
There are a lot stupid comments in bugzilla but the last one is one of the best
I have ever seen. 



 

Comment 18

[timeless]

.

Comment 19

[Steve]

Sorry, but I will not stay quiet on this someone wrote some code into Mozilla,
that changed the way embeded and I keep stressing embeded because if one loads a
SVG file, then the plugin works fine in Mozilla. There has been a change in the
necko.dll and the 14 other necko.xpt files. I pointed this out, because all
Mozilla browsers are affected by this and not just svg-mathml browsers.

All I've been getting is comments like the above and that Adobe is at fault.

I've done very little with Plugin SVG, because until #3 it really didn't work
very well in Mozilla and I'm not interested in using IE.

But then Adobe came out with #3 and wham the right click context, where most of
the controls for it are, worked. Then this came along and suddenly Adobe is at
fault. Fine they couldn't read your minds and it seems that no one thought to
inform them. They (Adobe) are not going to run out and write a new #4 plugin
just for Mozilla or AOL, they have just finished shipping major upgrades of
their products with W3C SVG as one of the new features. This means that for all
Gecko users we are left sitting on the side line. If SVG was totally broken as
you all seem to think perhaps this would look different, but it isn't it is only
not working in embeded files. 

Do I understand the code, no I don't. I do use and test Mozilla, and that since
Mozilla 5 and that was when we non programmers were adding our own pop3s into
prefs.js.

Comment 20

[Peter Lubczynski]

[e-mail]:
This is not an April fools joke. There are a few bugs in Bugzilla about the SVG
plugin not working with Mozilla because of this issue: Adobe's use of non-frozen
interfaces. They are using these interfaces before they were "ready" and now
that they are frozen Adobe can use them without the fear of breaking backwards
compatibility. However, nothing can be done for released plugins except ensure
that future ones DON'T USE NON-FROZEN interfaces. They need to make the fix on
their end. This will CONTINUE to be a problem while Adobe chooses to use any
non-frozen interfaces in their plugin.

Plugins that work in 4.x such as Quicktime and Acrobat will not have the same
problems because they ONLY use the NPAPI, which is pretty stable.

Comment 21

[Steve]

Okay, this I can understand. Since I'm not interested in using IE and am on a
windows machine (this effects Linux also) and not a MAC then Plugin SVG with its
very interesting SMIL animation is gone from Mozilla for, well the last I heard
over a the developers forum, about at a year or until SMIL 2 becomes a
recomendation.

Guess you can changed this bug to FIXED (?)!

Comment 22

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

no this can not be changed to fixed, as you may or may not have noticed this bug
is in Tech Evangelism.

This means that this bug is now more or less for contacting Adobe and telling
them to change their plugin to use the new frozen API.

Comment 23

[jlarsen]

Serious comment, can we in some clean way, (specially once adobe has a fixed
plugin) have mozilla automatically recognize the bad plugin, not use it, and
send you to the plugin finder to download the new good one? Cause many people
won't upgrade and will have this crash, and this could cause serious egg on
mozilla face even if its not mozilla's fault.

Comment 24

[Jay Patel [:jay]]

Adding topcrash keyword since there have quite a few of these crashes with
recent MozillaTrunk builds.  Also adding testcase since it looks like we have a
site that easily crashes with the SVG enabled build.  

Are we planning on adding SVG to the commercial builds anytime soon?  If so,
this should be nominated for nsbeta1...if not, then I guess this won't be an
issue for 1.0 or the next Netscape release.

Comment 25

[Jay Patel [:jay]]

Actually, I take the second paragraph of my last comment back.  I was able to
reproduced this with yesterday's build.  It's not just the SVG enabled builds,
but also the Adobe's plugin.  Here is my incident:

 Incident ID 4751403   
Stack Signature  nsLoadGroup::GetName 014f5309
Trigger Time 2002-04-02 15:24:44
Email Address [e-mail]
URL visited www.skeeter-s.com/svg/cute-lyon.htm
Build ID 2002040110
Product ID MozillaTrunk
Platform
Operating System Win32
Module
Trigger Reason Access violation
User Comments manually installed svg3 plugin by putting dll and zip files in
plugins dir....crashed going to above url. Bug 133567
Stack Trace
nsLoadGroup::GetName
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsLoadGroup.cpp, line 173]
NPSVG3.dll + 0x42a1 (0x530042a1)
NPSVG3.dll + 0x3d3b (0x53003d3b)
NPSVG3.dll + 0x51f8 (0x530051f8)
nsPluginStreamListenerPeer::SetUpStreamListener
[d:\builds\seamonkey\mozilla\modules\plugin\base\src\nsPluginHostImpl.cpp, line
2481]
nsPluginStreamListenerPeer::OnStartRequest
[d:\builds\seamonkey\mozilla\modules\plugin\base\src\nsPluginHostImpl.cpp, line
2113]
nsHttpChannel::OnStartRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 2747]
nsOnStartRequestEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp, line 162]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 597]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 530]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1078] 

Marking topcrash+ and nominating.

Comment 26

[Zach Lipton [:zach]]

jpatel, thanks for your help on this bug. This is a tech evangelism bug 
because Adobe which makes the svg plugin code has based code on an 
API which has changed. mozilla.org has never stated that this api is 
frozen and because it has changed, it has "bitrotted" and causes a crash. 
Tech evangelism is the product for such things where we contact website 
developers or plugin developers to ask them to fix their products/sites. 
That is the process currently underway with this bug. There is no way that 
this can be nsbeta1+ because Adobe has to fix the problem. Unless 
Netscape has an aggreement with Adobe that allows Netscape to force 
Adobe to fix bugs in their software by a certain secret date, this cannot be 
nsbeta1+. If you have any further questions about evangelism, feel free to 
email me or any of the other Tech Evangelism component owners or qa 
contacts.

Comment 27

[Peter Lubczynski]

For another discussion on SVG compatibility with Moz, see:
http://bugzilla.mozilla.org/show_bug.cgi?id=115528

Comment 28

[Alex Vincent [:WeirdAl]]

As of Nov. 9, 2001, at the Developer Day conference in Mountain View, Brendan 
Eich himself stated SVG in the standard Mozilla 1.0 itself was extremely 
unlikely.  As much as I would love to see SVG in Moz, there's no indication of 
change on that front that I am aware of.  Although this is a crash bug and 
therefore critical, I think it will be quite clear that SVG is not a guaranteed 
technology in Mozilla 1.0.

These things happen.  Especially when you're approaching a 1.0 release and 
writing code based on pre-1.0 software.

However, it sure would be nice if the cc list included an Adobe 
representative... (I found out about this one via svg-developers.)  I have not 
been following SVG development in Mozilla as closely as I should, so if there is 
an Adobe engineer watching this bug, my apologies in advance.

My two bits.  Someone else can chip in six more to make a byte; I'll keep quiet 
and watch this bug.

Comment 29

[timeless]

ok. I'm fixing the summary. This bug has *nothing* to do with mozilla's SVG 
implementation. It's limited to Adobe's plugin. We ****d them. Again, and Again 
and Again. we're good at that, that's what we do.  The fact is, that adobe is 
vaguely aware that we could do something like this, and we are vaguely clear in 
indicating that we reserve the right to and will/have exercised the right to do 
exactly what we did.

That said. I'm going to add a release note (once i can find a place to put it) 
indicating that Adobe's current SVG plugin should not be used with mozilla 
because it will crash due to an API change.  If someone would like to make a 
suggestion for the release note feel free to comment here (after all, everyone 
else is commenting).

Comment 30

[Peter Sorotokin]

Adobe SVG Viewer DOES NOT support Mozilla or Netscape 6.x and installer
does not install it for these browsers. Adobe SVG Viewer v3 does include
EXPERIMENTAL support for Mozilla 0.9.1 for Windows and Linux, which was
provided PURELY on the TECHNOLOGY PREVIEW basis and required MANUAL
installation (i.e manual copy of DLL on Windows). It was clearly
communicated on several occasions that it does make use of unfrozen
interfaces and that without using these interfaces we could not support
scriptability which is a key feature of the plug-in (And at the time
when SVG plug-in was being developed, only about 15 interfaces
were frozen in the whole Mozilla code, as far as I remember).

I also suggested several times that Mozilla team should change IIDs every
time an interface changes (frozen or unfrozen), so at least a safe way
is provided for using unfrozen interfaces. I do view current practice of
IID maintainence in Mozilla codebase as sloppy.

Mozilla plug-in architecture was advertized way too soon. Of course, now
it is scarapped completely. We have bended backwards to support Mozilla
at least to some degree, and now we are flamed by the very same people
who flamed us for not supporting new, "clearly defined" Mozilla plug-in
architecture. Current "vision" for Mozilla plug-ins (that can be found at 
http://www.mozilla.org/projects/plugins/plugin-api.html) does not cover
our needs (and this problem was communicated to Mozilla/Netscape folks).

Acrobat plug-in should not be affected by these problems, because being
non-scriptable it exists purely (and happily) in NN4.x architecture.

Peter Sorotokin
Adobe Systems Inc.

Comment 31

[Darin Fisher]

peter: point well taken w.r.t. updating the IIDs of unfrozen interfaces as
they're modified.  i'll update the IID's of the interfaces i recently touched
before marking them as frozen.  with any luck, doing so will prevent this crash.

bug 124465 tracks this work.

Comment 32

[Mike Shaver (:shaver emeritus)]

I am, very geniunely, sorry that we've screwed you here.  You are absolutely
right that we advocated the XPCOM plugin API before it was ready, though I'm
glad we scrapped it: it was never going to be the plugin API it needed to be,
and we needed to get away from trying to paint over that fact.  And I don't have
a good set of answers to your questions, though I very much wish I did.  You
might be able to do something IDispatch-alike with the xptcall code, maybe.

But I don't think that we should have, or should in the future, rev IIDs for
changes to unfrozen interfaces.  Many of our interfaces have gone through dozens
of significant changes, and we really don't want the intellectual and
computational overhead of continuing to support all of those interim revisions.
 We _did_ need to do a better job of cautioning people against using non-frozen
interfaces if they aren't willing to invest the (perhaps considerable) effort
required to keep up with those unfrozen interfaces.  We do a pretty good job
now, I think, but we burned a lot of people before we got our act together.

(Once an interface is frozen, of course, we must preserve the IIDs and names
forever.)

Comment 33

[Peter Sorotokin]

> But I don't think that we should have, or should in the future, rev IIDs for
> changes to unfrozen interfaces.  Many of our interfaces have gone through 
dozens
> of significant changes, and we really don't want the intellectual and
> computational overhead of continuing to support all of those interim 
revisions.

I am not advocating supporting unfrozen interfaces forever. What I am
suggesting is simply changing interface IID (in IDL file). This way
people who must use unfrozen interface for any reason simply can do
a QueryInterface and get NULL pointer back if unfrozen interface was
changed. It would be nice also to never return unfrozen interfaces from
frozen interface methods (only IUnknown*). Actually, had you followed
these two suggestions, there would be absolutely no problem with unfrozen
interfaces. The only difference would be that one could rely on being
able to use frozen interface pretty much always, but once would always
have to plan on not being able to get unfrozen interface. But changing
IID after every signature change (it is always in the same IDL file, so
there is very little effort involved!) is the key, the second rule is
just foolproofing.

Peter
 

Comment 34

[Paul Bergsagel]

I understand the comments about frozen and unfrozen interfaces with Adobe's SVG
plugin. I wonder if this bug applies to Mac OS X? I have version 3 of Adobe's
SVG plugin installed and am able to properly view all the test cases posted in
this bug by Steve (even the ones he claims cause a crash) and other SVG tests at
Adobe's site. I have yet to crash when accessing an embedded SVG file, or any
other type of SVG using Mozilla. I am using a B/W G3-350 256MB OS X 10.1.3 using
Mozilla build ID: 2002040411.

Comment 35

[Peter Sorotokin]

Paul,

On Mac OS X we have not exposed Mozilla plug-in entry point, so
Adobe SVG Viewer is not scriptable and behaves basically as
non-scriptable NN4.x plug-in, which, I think, are fairly well
supported in Mozilla. I'd bet if you somehow "erase" NSGetFactory
DLL entry point on Windows it'll work just as nicely (but no
scripting). It will not work on Linux because it only supports
NN6.x plug-in architecture on Linux.

Comment 36

[R.K.Aa.]

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

Comment 37

[Matthias Versen [:Matti]]

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

Comment 38

[R.K.Aa.]

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

Comment 39

[Jan Carpenter]

Topcrash on M1RC1
Adding M1RC1 to summary for tracking
Also marking topcrash+ 

Stack Trace: 

	 nsLoadGroup::GetName
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsLoadGroup.cpp  line 173]
	 NPSVG3.DLL + 0x42a1 (0x530042a1)
	 NPSVG3.DLL + 0x3d3b (0x53003d3b)
	 NPSVG3.DLL + 0x51f8 (0x530051f8)
	 nsPluginStreamListenerPeer::SetUpStreamListener
[d:\builds\seamonkey\mozilla\modules\plugin\base\src\nsPluginHostImpl.cpp  line
2481]
	 nsPluginStreamListenerPeer::OnStartRequest
[d:\builds\seamonkey\mozilla\modules\plugin\base\src\nsPluginHostImpl.cpp  line
2113]
	 nsHttpChannel::ProcessNormal
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp  line 594]
	 nsHttpChannel::ProcessResponse
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp  line 549]
	 nsHttpChannel::OnStartRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp  line 2763]
	 nsOnStartRequestEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsRequestObserverProxy.cpp  line 162]
	 PL_HandleEvent
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 597]
	 _md_EventReceiverProc
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  line 1078]
	 0x778b0c24
 
 	Source File :
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/base/src/nsLoadGroup.cpp
line : 173


COMMENTS/URLs:
     (5488792)	URL: http://pilat.free.fr/english/routines/form1.htm
     (5488792)	Comments: Trying to open the page.
     (5480627)	URL: http://www.adobe.com/svg/dynamic/transformations2.html 
     (5480627)	Comments: Opening a page that has embedded SVG image that uses the Adobe SVG
Viewer's internal scripting engine.
     (5479742)	URL: http://jan.ucc.nau.edu/~edv/SVGNow/19
     (5389320)	URL: http://www.minc.ne.jp/~konda/new/svg/svg_test01.htm
     (5389320)	Comments: I Used Adobe Scalable Vector Graphics plugin 3.0 build 37
     (5387839)	Comments: Opened a DHTML-Editor written by myself with poor JavaScript
expected to work only in Internet Explorer - Mozilla crashed.
     (5385194)	URL: http://beez.sourceforge.net/

Comment 40

[timeless]

ok release noted

Comment 41

[R.K.Aa.]

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

Comment 42

[R.K.Aa.]

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

Comment 43

[greer]

Summary -> M1RC3 for throughness.

Comment 44

[greer]

Some stacks crash one frame later at nsHttpChannel::GetName. Adding that to the
summary for Talkback tracking.

Comment 45

[Gabriel Radic]

Not working is OK, crashing is NOT OK.

Comment 46

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

Gabriel, there's nothing moz can do about the crashing

the only thing it could maybe do is to refuse to load it...

Comment 47

[Shiva Thirumazhusai]

Since this crash depends on external company. I am marking it as topcrash-.

Comment 48

[Steve]

Hey there all

Richard Bennet came up with a super workaround for this problem and it works.

<iframe src="" width="px" height="px" frameborder="0" MARGINWIDTH="0" 
MARGINHEIGHT="0" >
<embed src="" width="px" height="px" /> 
</iframe>
That's it no crashes.
Here is his test page: http://richardinfo.com/svg/iframetest.html
I've already added the changes to pages at my site and this
http://www.skeeter-s.com/svg/cute-lyon.htm
now works in Mozilla 1 and a newer trunk #20020603

Lets get the word out about this work around until Ádobe does a new plugin.

Comment 49

[Tobias Reif]

This has been disussed extensively, and is no solution whatsoever.
Please check the thread
http://groups.yahoo.com/group/svg-developers/message/17554
...
http://groups.yahoo.com/group/svg-developers/message/17574
http://groups.yahoo.com/group/svg-developers/message/17572
http://groups.yahoo.com/group/svg-developers/message/17567
There are crashes with standalone SVGs:
http://bugzilla.mozilla.org/show_bug.cgi?id=141762
SVGs that are embedded with iframe/object/embed:
http://groups.yahoo.com/group/svg-developers/message/17567
if not every time, then for some people.

Comment 50

[Steve]

Hi All

Just went to this link that was mentioned by Tobi, that is a dup bug of this one.
http://bugzilla.mozilla.org/show_bug.cgi?id=141762

It reported that the below link was causing crashes. I couldn't get
Mozilla 1.0.0+
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.0+) Gecko/20020603
to crash. Went through the whole slide-show (total svg, no html).  

http://www.w3.org/2002/Talks/1904-Daejeon-IH/CSSslide.svgz

Well enough from me for tonight, I'm off to the Mozilla 1 party here in Vienna
Austria. :-) :D

Comment 51

[Matthias Versen [:Matti]]

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

Comment 52

[R.K.Aa.]

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

Comment 53

[Matthias Versen [:Matti]]

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

Comment 54

[Kaeptn Weltall]

although some comments sound like crashing method in plugins interface's been
found, maybe the following effect is of interest.
If you load an html-page that embeds svg, it will not crash if you have loaded
the svg directly at any time before in the same browser window.
Even if the svg document has changed and there must definitly happend a reload.
Using another window for the html-embedded you will crash again.
maybe this cuts down the number of methods in question.
greetings

     robert

Comment 55

[Olivier Cahagne]

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

Comment 56

[David Jackson]

Using Internet Explorer to view embedded SVG pages works fine.  I look forward
to the day when this is not the solution to this bug.  Mozilla/Netscape/AOL is
handicapping themselves by not supporting SVG.  Regardless of who is at fault,
Mozilla is going to pay for allowing this situation to continue.  I have no axe
to grind, but emotional attachments to Mozilla aside, I have to go with what works.

Comment 57

[Steve]

Attachment: Modified NPSVG§.dll for Adobe SVG Viewer

Hello All

A while back, I was sent a modified NPSVG3.dll and was asked to test it in
NS7X.
I didn't and don't have NS installed so I put in a Mozilla 1.2 (Win ZIP).
The dll was then placed in the plugin folder and tested.
Results were good, all SVG files that did not rely on some sort of javascript
for IE and the Adobe plugin worked fine and there were no crashes.
An example is the plugin test page at Adobe:
http://www.adobe.com/svg/viewer/install/svgtest.html

Recently I mentioned in a thread at the SVG newsgroup that I had this
modified dll and I have sence sent it to several people.

Today I had some time and decided to install the two recent releases:
Mozilla 1.3.1 and 1.4B The NPSVG3.dll was put into both browsers and both
browsers were tested at the Adobe url listed above. Both browsers called the
plugin (it is installed on my Win XP machine because it is needed for Jasac's
WebDraw program, plus I have an Acrobat Reader 5x which does a backdoor install
of the plugin anyway.
Only this modified NPSVG3.dll was placed into the plugin folder and not the
NPSVG3.zip

I thought that I'd submit this modified file to you. Perhaps it might be of an
interest.

I haven't and won't put this dll up on my site for download, because it
probably violates the reverse engineering laws or something like that.
Because of this, please don't ask how I came upon this modified dll.

Comment 58

[Myk Melez [:myk] [@mykmelez]]

I have removed the content of attachment 123129 [details].  Steve, mozilla.org is obliged
to obey the same laws as anyone else, so don't attach illegal files.

Comment 59

[Steve]

I can understand that.
Sorry if that made a problem for anyone.

Thought behind that posting was that perhaps a coder for NS/Mozilla might be
interested.

Comment 60

[Bradley Baetz (:bbaetz)]

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

Comment 61

[Bob Clary [:bc] (inactive)]

tech evang june 2003 reorg

Comment 62

[Jean-Pierre Matsumoto]

Mozilla 1.4 RC 2 Release Notes plugin section has only a remark about Adobe SVG
viewer for *Windows*. Maybe someone can generalize this remark for all OS.

Comment 63

[Peter Sorotokin]

Note that it probably works on Mac (where Adobe SVG Viewer does
not expose NSGetFactory and using NN4x plug-in architecture) -
but not any other OS.

Comment 64

[Brion Vibber]

Re: comment #62, comment #63: I can confirm that the Adobe SVG viewer plugin (tried 3.0 build 
76) does _not_ instantly crash Mozilla 1.4 on MacOS X when showing an SVG <object> in a page. 
Last I looked Linux did crash, and it would be nice to have that reflected in the release notes if it's 
still true.

Comment 65

[Olivier Cahagne]

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

Comment 66

[Peter Sorotokin]

This bug and all related bugs were fixed in Adobe SVG Viewer v6
Preview Release (Windows only at the moment, but keep looking
http://www.adobe.com/svg/viewer/install/beta.html). We no longer
try to support Mozilla browser scripting.

Comment 67

[Jean-Pierre Matsumoto]

Good news !  Adobe has released a new beta version of their SVG plugin :

http://www.adobe.com/svg/viewer/install/

Version 3.01 beta no more crashs my Mozilla on Red Hat 9.

Comment 68

[Graeme Humphries]

It may not crash any more, but it's not the most useful thing. On my Gentoo
system, under Mozilla Firebird, it loads the plugin fine, but all embedded SVG
images just show up as blank squares.

Comment 69

[hans]

Works great for me in Mozilla Firebird 0.6.1 and Mozilla 1.5. It doesn't work
quite as well as the previous Adobe SVG plugin did, before this fiasco.
Specifically, mouseover is broken and a few other things. But what it does do it
does without problems.

Comment 70

[Graeme Humphries]

Oh, I should've mentioned, that's Mozilla Firebird 0.7 under 2.6 kernel in
Gentoo Linux.

Comment 71

[Olivier Cahagne]

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

Comment 72

[Olivier Cahagne]

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

Comment 73

[rajeev]

More good news. It seems that Adobe has also released a beta version for
Windows, supposedly of version 6.0. (What happened to 4 and 5?) It is availible
here:
http://www.adobe.com/svg/viewer/install/beta.html
Make sure you delete the old SVG viewer files from your plugins dir and install
the new ones. It seems to work the same as the Linux beta was described (some
mouseover problems).

Comment 74

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Great! WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b)
Gecko/20040412 Firefox/0.8.0+ and SVG Viewer 6.0 Beta.

Comment 75

[Kam-Hung Soh]

Mozilla 1.6 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

I can now view embedded SVG content from the Adobe site using the Adobe
SVGViewer 6.0 Preview 1 as a plugin (GOOD).  However, content with Javascript
does not work (form buttons in the demonstrations don't work, etc.)

Comment 76

[vajira]

When are we going to get a plugin that supports the Frozen API. Will this be 
available at all?

Comment 77

[Graeme Humphries]

Note that Adobe's latest plugins (3.01 on Linux, some beta version on Windows)
both work adequately with the latest 1.0PRE of Firefox. I'd assume this means
Adobe has updated their code to comply more strictly with the frozen interface.
YMMV, of course.

Comment 78

[timeless]

[e-mail]: please don't make assumptions. does their new plugin
support scripting at all?

Comment 79

[Graeme Humphries]

(In reply to comment #78)

I don't know, what's a test page using scripting that I can try it against?
Certainly the page referenced in this bug works fine with the current plugins,
but it doesn't seem to do any scripting.

Comment 80

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Following page contains some examples which use scripting AFAIR (Currently I
havn't installed the svg plugin):

http://www.adobe.com/svg/demos/main.html

Comment 81

[Graeme Humphries]

Heh, the graph and the draw demos both crashed and burned, so I assume that
means that scripting is still broken.

Comment 82

[bernd pier]

i`ve read your comment. i have firefox installed on xp. installing svg viewer
and copying NPSVG3.dll from Adobe Plugin folder to Firefox Pkugin Folder and it
work`s fine.

Comment 83

[bernd pier]

ups, sorry i`m wrong. it only works one time. s**t.

Comment 84

[Adam Guthrie]

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

Comment 85

[Helder "Lthere" Magalhães]

IMHO this could be marked invalid or fixed, as the root cause is in a software product (ASV) which was publicly discontinued [1].

[1] http://www.adobe.com/svg/eol.html

Comment 86

[Andreas Neumann]

yes, I also think that this is not an issue any more. This bug should be closed.

Comment 87

[Matthias Versen [:Matti]]

marking fixed

Comment 88

[Henrik Skupin [:whimboo][⌚️UTC+2]]

More invalid. As comment 85 states the cause was the Adobe SVG viewer.