Closed Bug 578281 Opened 14 years ago Closed 14 years ago

Firefox 4.0b1 Crash [@ nsGenericElement::DestroyContent() ] & [@ FindNamedItems ] & [@ nsFrame::~nsFrame() ] & [@ UnionExpr::evaluate(txIEvalContext*, txAExprResult**) ] & [@ nsNodeWeakReference::QueryReferent(nsID const&, void**) ]

Categories

(Firefox :: Extension Compatibility, defect)

Product:
Firefox
Component:
Extension Compatibility
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: cbook, Assigned: MatsPalmgren_bugz)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [crashkill])

Crash Data

Attachments

(1 file)

Seo-dofollow.xlsx
118.82 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details 
er, this look like internet download manager

100% (286/286) vs.  50% (8971/17949) idmmzcc.dll
100% (285/286) vs.  50% (9040/17949) idmmkb.dll
100% (32/32) vs.  50% (8971/17949) idmmzcc.dll
100% (32/32) vs.  50% (9040/17949) idmmkb.dll

and maybe dupes of bug 564008, bug 563984 , bug 527339 and/or the parts of 4.0b1 problems in those bugs
Depends on: 578443
Hi

Thank you for notifying about the problem

I’m afraid that we could not repeat this crash today on our computers. It would be useful to have (a) crash dump with a stack trace, and/or (b) web page address(es) where the problem occurs, and/or (c) instructions what to do to repeat the crash. Any contacts with users who experience this crash should be useful as well. All crashing dumps to analyze stack in visual studio can be useful as well. If you have any non-disclosure terms, we can sign an NDA.

Regards,

Charles Jones
Software engineer

Tonec Inc.
641 Lexington Avenue, 15th fl. 
New York, NY, 10022
the link in comment zero has a list of the reports with stack traces. most appear to look like:

Frame  	Module  	Signature [Expand]  	Source
0 	xul.dll 	nsGenericElement::DestroyContent 	content/base/src/nsGenericElement.cpp:3779
1 	xul.dll 	nsGenericElement::DestroyContent 	content/base/src/nsGenericElement.cpp:3779
2 	xul.dll 	nsGenericElement::DestroyContent 	content/base/src/nsGenericElement.cpp:3779
3 	xul.dll 	nsGenericElement::DestroyContent 	content/base/src/nsGenericElement.cpp:3779
4 	xul.dll 	nsGenericElement::DestroyContent 	content/base/src/nsGenericElement.cpp:3779
5 	xul.dll 	nsGenericElement::DestroyContent 	content/base/src/nsGenericElement.cpp:3779
6 	xul.dll 	nsGenericElement::DestroyContent 	content/base/src/nsGenericElement.cpp:3779
7 	xul.dll 	nsGenericElement::DestroyContent 	content/base/src/nsGenericElement.cpp:3779
8 	xul.dll 	nsDocument::Destroy 	content/base/src/nsDocument.cpp:6752
9 	xul.dll 	DocumentViewerImpl::Destroy 	layout/base/nsDocumentViewer.cpp:1593
10 	xul.dll 	DocumentViewerImpl::Show 	layout/base/nsDocumentViewer.cpp:1920
11 	xul.dll 	nsPresContext::EnsureVisible 	layout/base/nsPresContext.cpp:1629
12 	xul.dll 	PresShell::UnsuppressAndInvalidate 	layout/base/nsPresShell.cpp:4536
13 	xul.dll 	PresShell::sPaintSuppressionCallback 	layout/base/nsPresShell.cpp:2716
14 	xul.dll 	nsHttpChannel::MaybeInvalidateCacheEntryForSubsequentGet 	netwerk/protocol/http/nsHttpChannel.cpp:5157
15 	xul.dll 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:519
16 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:547
17 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:142
18 	xul.dll 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:216
19 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:199
20 	xul.dll 	nsStandardURL::BuildNormalizedSpec 	netwerk/base/src/nsStandardURL.cpp:663
21 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:173
22 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:175
23 	xul.dll 	xul.dll@0xa19373 	
24 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:192
25 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3624
26 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:120
27 	firefox.exe 	__tmainCRTStartup 	obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591
28 	kernel32.dll 	kernel32.dll@0x13676 	
29 	ntdll.dll 	ntdll.dll@0x39d41 	
30 	ntdll.dll 	ntdll.dll@0x39d14


the crash appears to have been around with previous releases, but is appearing in much higher volume with 4.0 beta 1


checking --- nsGenericElement::DestroyContent 20100712-crashdata.csv
found in: 4.0b1 3.6.6 3.7a5 3.7a6pre 4.0b2pre 3.0.19 3.6b5 3.6.7 3.6 3.5.10
release total-crashes
              nsGenericElement::DestroyContent crashes
                         pct.
all     285620  334     0.00116939
4.0b1   18756   307     0.0163681
3.6.6   162229  10      6.16413e-05
3.7a5   721     6       0.00832178
3.7a6pre        379     3       0.00791557
4.0b2pre        1164    2       0.00171821
3.0.19  8636    2       0.000231589
3.6b5   579     1       0.00172712
3.6.7   14043   1       7.12099e-05
3.6     6384    1       0.000156642
3.5.10  19611   1       5.09918e-05

The most frequent sites assoicated with the crash appears to be

  18 http://vnexpress.net/GL/Home/
   4 http://www.vnexpress.net/GL/Home/
   2 http://www.youtube.com/results?search_query=Dilwali+Kothi&aq=f
   2 http://www.vnpet.com/user_profile.php?game=1&user=thieugia9x
   2 http://www.tinhte.vn/forums/163-THAY-DOI-NANG-CAP-FIRMWARE
   2 http://www.sony-asia.com/search/Search.action
   2 http://www.orkut.com.br/Home
   2 http://www.orkut.co.in/Home
   2 http://www.leomessi.com/eng/index.html
   2 http://www.filefactory.com/file/a19394g/n/russian_1
   2 http://vnexpress.net/GL/Vi-tinh/
   2 http://hcm.24h.com.vn/
   2 http://dantri.com.vn/
adding more signatures for the internet download manager to get them connected via crash-stats
Summary: Firefox 4.0b1 Crash [@ nsGenericElement::DestroyContent() ] → Firefox 4.0b1 Crash [@ nsGenericElement::DestroyContent() ] & [@ FindNamedItems ] & [@ nsFrame::~nsFrame() ] & [@ UnionExpr::evaluate(txIEvalContext*, txAExprResult**) ] & [@ nsNodeWeakReference::QueryReferent(nsID const&, void**) ]
Hi,

It seems to be a problem with nsISelection interface. Note that the description of the interface clearly states that it’s FROZEN!
 
In former versions of Firefox the following code worked without a problem:
 
nsCOMPtr<nsISelection> selection;
rv = mWindow->GetSelection(getter_AddRefs(selection));
.................................................
 
PRUnichar* szText;
rv = selection->ToString(&szText);
if (NS_SUCCEEDED(rv))
{
    .....................
    using szText
    nsMemory::Free(szText);
}

But now selection->ToString(&szText) returns 0, that means  NS_SUCCEEDED(rv) true, BUT szText is not filled with data.

We have resolved the problem by adding the following changes:
 
PRUnichar* szText = NULL;
rv = selection->ToString(&szText);
if (NS_SUCCEEDED(rv) && szText)
{
    .....................
    using szText
    nsMemory::Free(szText);
}

please check nsISelection implementation and fix it if possible.
 
Regards


Charles Jones
Software engineer

Tonec Inc.
641 Lexington Avenue, 15th fl. 
New York, NY, 10022
my guess is that this is from:
http://hg.mozilla.org/mozilla-central/rev/0c440c656ada - bug 39098

charles: the interface didn't specifically promise that the result wouldn't be a null pointer. xpcom allows NS_OK + null out.

Some interfaces document whether this is expected, but this interface didn't.

I think that your fix is correct and that there's nothing we'd want to do.
Assignee: nobody → charles
Component: General → Extension Compatibility
Product: Core → Firefox
QA Contact: general → extension.compatibility
(In reply to comment #9)

For me it seems like a real bug that needs to be fixed. The selection of a text on a web page really exists, but nsISelection::ToString() returns nothing. It should be fixed independently of our extension. Besides if it’s fixed, old versions of extension will stop crashing 4.01b and 3.7.*. You can verify and debug the crash like I described here:

https://bugzilla.mozilla.org/show_bug.cgi?id=564008
I'm really tired to write to Firefox forums that

1. IDM CC 6.9.9 has a workaround and Firefox 3.7 and 4.0 DO NOT crash anymore with this version of extension
2. The reason of crash is FIREFOX BUG inside nsISeletion::ToString() implementation! Please FIX your bug instead of blacklisting!

Best regards,

Charles Jones
Software engineer

Tonec Inc.
641 Lexington Avenue, 15th fl. 
New York, NY, 10022
Assigning to Mats Palmgren who fixed bug 39098.

I agree with coment 10, it seems strange if there are things actually selected, but we return null.

At the very least, we could change ToString to return a pointer to an empty string, rather than returning null.

While the interface isn't promising anything one way or another, it also seems like crashing users isn't helping anyone, especially if there is an easy fix.
Assignee: charles → matspal
blocking2.0: --- → ?
I apologize I had a strange version of Gecko SDK 2.0. I re-downloaded it and
found that nsISelection and its CID (or IID) had changed indeed.

The things seem to be worse. There is no protection when former FROZEN
interfaces are returned as pointers in parameters of functions.

In our case when we compile with old Gecko SDK, the following code:

nsCOMPtr<nsISelection> selection;
rv = mWindow->GetSelection(getter_AddRefs(selection));

it returns rv NS_OK, and selection is not NULL. It seems to be OK and we use it
if (NS_SUCCEEDED(rv) && selection)
   ..................
And some methods do even work correctly, but ToString() introduced a problem

I may add another checking like
nsCOMPtr<nsISelection> selection2 = do_QueryInterface(selection, &rv);
if (NS_SUCCEEDED(rv) && selection2)
   ....................

But it's not a built in protection

The problem is that pointers to former FROZEN interfaces are returned the same
way in many cases. We can do additional checking, but other extension
developers may not do it.

Maybe in case of such global changes, you should not support old versions like
it's described here
https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_1.9.3
"It is possible for a binary component to be compatible with Mozilla 1.9.2 and
Mozilla 2.0 by using the extra macro NS_IMPL_MOZILLA192_NSGETMODULE. See
nsSampleModule.cpp for more details."

If somebody compiles his extension with SDK 1.9 he will have old interface
descriptions, and such crashes are possible with new versions of Firefox.

If somebody compiles his extension with SDK 2.0, he may have same kind of
crashes with Firefox 3.6 and below. The compiler won't show any errors, and the
extension may work correctly on first look, and it seemed that only component
registration should be changed for the extension to work with Firefox 4.0b2pre.
But the problems like I described above may come up later.

Having analyzed that I think that it's hardly possible to change nsISelection
implementation so that our old extension won't crash. On the other hand, old
extensions are not registered in Firefox 4.0b2pre and will not be loaded. Also
they won't be loaded in the final release of Firefox 4. Thus this topic should
be closed.

Do you plan to change FROZEN interfaces in the future? Or there will be no
changes in FROZEN interface except those made in SDK 2.0pre?
You probably want to bring this question to the newsgroups in order to get attention from the right people.
nsISelection was reverted by jlebar today to deal w/ this.

this is why when jsdI interfaces are changed I forced the dependent interfaces to change iid's too.

I'm going to propose something like http://viper.haque.net/~timeless/blog/176/ which should help.
(In reply to comment #15)
> nsISelection was reverted by jlebar today to deal w/ this.
> this is why when jsdI interfaces are changed I forced the dependent interfaces
> to change iid's too.
> I'm going to propose something like http://viper.haque.net/~timeless/blog/176/
> which should help.

We have read the link above. It seems to be a bad idea. We write application on C++ and IIDs of interfaces should be in the binary code. If you change all IIDs forth and back it may cause a confusion or mess.

Why you cannot do it like in Microsoft COM? They have a good rule, once interface description is published, they do not change it anymore. If they need new methods, they make a new interface which is a successor of old one.

interface ISomeInterface2 : ISomeInterface
{
}
if new methods are required, then 
interface ISomeInterface3 : ISomeInterface2
{
}
And so on. And QueryInterface of ISomeInterface3 knows IIDs of all old interfaces.

Our old add-on for Internet Explorer 4 has been developed for Windows 95 and it still works flawlessly on IE8 and Windows7.
ms publishes less often than we do. we publish every day. they publish perhaps quarterly. we don't want to have to pay for the overhead of our interim mistakes.

they're also much more organized than we are.

brendan (and biesi) noted that we should really only need one revision change, on the release side, but that doesn't lock out extensions from crashing with trunk versions.

i think as an interim thing, or perhaps as a necessary first step, i'll try to write a script around xpt_dump which at least catches cases where iid's haven't been bumped properly, to do that it will basically need a table of iid's and their xpt output, so it should be fairly trivial to write. i'll try to do it this week.
I don't remember a case when Mozilla developers changed methods of an interface but forgot to change its IID. The problem was not in the change of IID of the interface. Although you had changed IID of the interface the problem still existed because you had changed the methods. We did not expect that a FROZEN interface would change methods and IID. If you want to change an interface do it but, don't change FROZEN interfaces. It will lead to compatibility problems with many applications. We have added a protection to the latest version of our extension and it will protect Firefox from crashes. But if somebody changes IID of a frozen interface, the extension may stop functioning and we get lots of complains from our users. In case of such compatibility problems, somebody stops using IDM, somebody stops using Firefox. We have more than 10 million unique visitors on our site every month, and 30% of them use Firefox. Many people use our application and never visit its home site. We together should minimize the loss of our users. 

Do I understand right that you want to change IIDs of all interfaces with every new release? It would be a bad step for binary application developers. How binary applications developers will debug own extensions while you have a beta release if they don't know future IIDs? At the day when a final release of Firefox comes out, all binary extensions will stop working. I just cannot imagine the reaction of our users. I would appeal never change IIDs of the interfaces which methods are not changed, independently whether these are frozen interfaces or not. IID change doesn't have action upon the crash we experienced. But if you change IIDs it will cause more problems.
IID change *does* affect the crash.

There was a getter from an interface which returned an interface which did change.
The interface which did change wasn't bumped, but it wouldn't matter because you don't qi to an interface you're given. So your code didn't know it was bumped.

If we had properly changed the interface with the getter, your code wouldn't have been able to get the interface which gave you the changed object and there wouldn't have been a crash.

People building addons will have time to do testing because the bump would happen when we branch.

And as for testing, you can always build against nightlies like everyone else.

Note that the result would be only changing iid's of interfaces which change or which returned interfaces which changed.
Crashes happen when you change or add methods for an interface.

Consider the following sample:

In Javascript we have this code
    my_component.TestMethod(window.content);

On C++ we do the following:
    NS_IMETHODIMP CMyComponent::TestMethod(nsIDOMWindow *mWindow)
    {
        if (! mWindow)
            return NS_ERROR_NOT_IMPLEMENTED;
 
        nsCOMPtr<nsISelection> selection;
        nsresult rv = mWindow->GetSelection(getter_AddRefs(selection));
        if (NS_SUCCEEDED(rv) && selection)
        {
            PRUnichar* szText = NULL;
            rv = selection->ToString(&szText);
            if (NS_SUCCEEDED(rv) && szText)
            {
                .......................
                nsMemory::Free(szText);
            }
        }
    }

This is not a code from our extension, it's just a sample. We do all necessary checking on interface compliance. We check that we get the interface which we expected to get.

Now imagine you have changed IID and methods of nsISelection. I suppose since nsISelection is retrieved from nsIDOMWindow, you suggest changing IID of nsIDOMWindow (getter) as well.

But HOW changing of IIDs in a sample above can protect Firefox from crashes? There is no checking and the code will run independently of new IIDs. You can change IIDs but it will not save Firefox from crashes.

Now imagine that there are developers which use additional checking and do not use a changed interface of nsISelection:

    NS_IMETHODIMP CMyComponent::TestMethod(nsIDOMWindow *mWindow)
    {
        if (! mWindow)
            return NS_ERROR_NOT_IMPLEMENTED;
 
        nsresult rv;
        nsCOMPtr<nsIDOMWindow> domWinI = do_QueryInterface(mWindow, &rv);
        if (NS_FAILED(rv) || (! domWinI))
            return NS_ERROR_NOT_IMPLEMENTED;
 
        nsCOMPtr<nsIDOMDocument> aDocument;
        rv = mWindow->GetDocument(getter_AddRefs(aDocument));
        if (NS_FAILED(rv) || (! aDocument))
            return NS_ERROR_NOT_IMPLEMENTED;
 
        nsCOMPtr<nsIDOMDocument> domDocI = do_QueryInterface(aDocument, &rv);
        if (NS_FAILED(rv) || (! domDocI))
            return NS_ERROR_NOT_IMPLEMENTED;
 
        using aDocument
        ............................................
    }

The interfaces used above have not changed, but its IIDs have changed. Since the neat developers do additional checking here, the extension will not work because it stops at do_QueryInterface on the first check. They have to make a new binary dll extension, while developers who did not do checking properly have to just increase the compatibility range in rdf file. In a week or in a month neat developers will have to make a new dll for a new version of Firefox etc. After that they may think: "What for we do the checking here? Since methods are not changing anyway, let's remove the checking and the extension will work for all future versions of Firefox". If you change methods of nsIDOMDocument later, it will cause new Firefox crashes with both these extensions.

Thus I appeal not to change IIDs of interfaces unless their methods have changed. It will not reduce compatibility problems. And it's better not to touch frozen interfaces at all.
you don't need to make a new extension, you just need to have extra interfaces

nsIDOMWindow_gecko1
nsIDOMWindow_gecko2
nsIDOMWindow_gecko3

based on the various vtables. you can provide code which wraps the various objects into the version you like.

the undefs/defines here are one way to do things, but the proper way is to do a search and replace in the various generated .h files.


#undef __gen_nsIDOMWindow_h__

#undef nsIDOMWindow
#undef NS_IDOMWINDOW_IID_STR
#undef NS_IDOMWINDOW_IID
#undef NS_DECL_NSIDOMWINDOW
#undef NS_FORWARD_NSIDOMWINDOW
#undef NS_FORWARD_SAFE_NSIDOMWINDOW

#define nsIDOMWindow nsIDOMWindow_gecko1
#include "gecko1/nsIDOMWindow.h"
#undef nsIDOMWindow
#undef NS_IDOMWINDOW_IID_STR
#undef NS_IDOMWINDOW_IID
#undef NS_DECL_NSIDOMWINDOW
#undef NS_FORWARD_NSIDOMWINDOW
#undef NS_FORWARD_SAFE_NSIDOMWINDOW

/* repeat for "gecko2/nsIDOMWindow.h", etc. */

class DOMWindow_gecko1 : nsIDOMWindow {
  DOMWindow_gecko1(nsIDOMWindow_gecko1);
  NS_DECL_ISUPPORTS
  NS_FORWARD_NSIDOMWINDOW_GECKO1(real);
  nsCOMPtr<nsIDOMWindow_gecko1> real;
}

NS_IMPL_ISUPPORTS1(DOMWindow_gecko1, nsIDOMWindow)

already_AddRefed<nsIDOMWindow> wrap_DOMWindow_gecko1(nsIDOMWindow_gecko1* aWin) {
  nsCOMPtr<nsIDOMWindow> win = new DOMWindow_gecko1(aWin);
  nsIDOMWindow *result = nsnull;
  win.Swap(result);
  return win;
}

/* note that it's probably best for your classes to be split such that you have a public header which declares your wrap_ functions which is included by your individual class impl files and by your convert file, while the class decl is private to the class impl file. */

already_AddRefed<nsIDOMWindow> ConvertWindow(nsISupports *aWin) {
  {
    nsCOMPtr<nsIDOMWindow> win(do_QueryInterface(aWin));
    if (win) {
      nsIDOMWindow *result = nsnull;
      win.Swap(result);
      return win;
    }
  }
  {
    nsCOMPtr<nsIDOMWindow_gecko1> win(do_QueryInterface(aWin));
    if (win)
      return wrap_DOMWindow_gecko1(win);
  }
  /* ... */
  return nsnull;
}

Your component declares an interface which takes an nsIDOMWindow, but it doesn't say "I like nsIDOMWindow", it says "I like {...}" xpconnect will bounce the code when it tries to call TestMethod with window.content because your iid isn't a match for the iid of window.content.
But still you have not answered my question. HOW changing of IIDs of interfaces in a sample above (first sample, comment 20) can protect Firefox from crashes?
i did. the code won't be called because your interface for 

myIComponent.TestMethod(nsIDOMWindow) should specify a different iid than the one we have, and thus xpconnect shouldn't connect them.
xpconnect does not always know IIDs related to function parameters. In addition in our dll the parameter of function is a pointer and it can take any type we want. 

I have just changed IID in nsIDOMWindow.idl, compiled nsIDOMWindow.h with new IID, made the following MyComponent.idl:

#include "nsISupports.idl"
interface nsIDOMWindow;
[scriptable, uuid(....blablabla.....)]
interface iMyComponent : nsISupports
{
 void TestMethod(in nsIDOMWindow wnd);
};

I compiled new xpt file, and re-built my test dll with new IID for nsIDOMWindow. Then I registered this extension in Firefox with the new nsIDOMWindow IID. To sum up, did an imitation of changing IID in SDK.

And during testing this method was called! Of cause the following check bounced with an error:

        nsCOMPtr<nsIDOMWindow> domWinI = do_QueryInterface(mWindow, &rv);

It returned rv 0x80004002 - "no such interface".

But if I comment the following check:
        //if (NS_FAILED(rv) || (! domWinI))
        //    return NS_ERROR_NOT_IMPLEMENTED;

Then the remaining code of the extension will run without a problem

Thus changing of IIDs does not resolve the crash problem when you change methods. Maybe I don't understand something here?
you need to #include "nsIDOMWindow.idl"
I understand that if I add #include "nsIDOMWindow.idl" to MyComponent.idl then the extension will work as you describe

Actually we had this include, but if I add a forward declaration instead: 

interface nsIDOMWindow;

Then the extension will work as well, but changing of IIDs does not protect Firefox from crashes at this case.

timeless, what the ultimate goal do we have? Do you want to guard Firefox from crashes because of our extension only? We have already added all additional checks where we get interfaces. The checks are like in my comment 13. Our extension will not crash Firefox the same way anymore. The problem was that we just could not contemplate that any frozen interface would change. At this time our extension takes it into account.

Or do you want to avoid crashes with other extensions? In this case I showed you a sample of code that would crash Firefox independently of changing of IIDs. There is no guarantee that if you change IIDs and some developers who implement an extension will not do it the same way as in my sample so that the extension works with all versions of Firefox. And the things can get worse.
the goal is to avoid all such crashes. so if necessary we can probably make the loader refuse to load xpt files with unresolved entries.
I gave you one of examples. Other ways are possible as well. It's difficult to foresee everything. It's also possible to make mistakes in wrappers for interfaces which you suggested when there are many changed interfaces and several changes of IIDs. The best way to protect Firefox from crashes is not to touch frozen interfaces. There are always many workarounds. For example, why did not you add the new method to unfrozen nsISelection2 instead of frozen nsISelection? Or you could add the additional method as the last one in nsISelection. In this case vtable of old nsISelection would match the beginning of vtable of new nsISelection.
i can't control 1000 developers. I don't. I can't.

I can control the build system. I can control what extensions are loaded and which xpt files are loaded.

problems which are solvable could be solved. problems which we've failed to solve involving people for 10 years clearly aren't going to be solved.

Normally we do try to prevent people from adding members in the middle of vtables. But we're not perfect, and we won't be.

Automatic IID bumping more or less *can* be perfect.
(In reply to comment #15)
> nsISelection was reverted by jlebar today to deal w/ this.

So the problem was fixed elsewhere and this bug can be resolved.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
(In reply to comment #29)
> i can't control 1000 developers. I don't. I can't.
> I can control the build system. I can control what extensions are loaded and
> which xpt files are loaded.
> Automatic IID bumping more or less *can* be perfect.

It can solve from one set of problems but many other problems will come up. It is not known what problems are worse. When developers (like us) don't not update their extensions on time for new versions of Firefox, you will get a bunch of user complains. Your policy looks like the following: In order to protect new versions of Firefox from crashes because of extensions, we need to disable extensions, or don't allow them to work with new versions of Firefox by changing IIDs. You should know that most users don't know how to find and update extensions which stopped working suddenly. Some of them may switch to another browser. You can read the user comments here:

https://bugzilla.mozilla.org/show_bug.cgi?id=382356

It's an old topic but users write here their comments for the recent IDM CC bug with nsISelection. Note that we have resolved the original problem a long time ago, but it was a long flame when users could not update the extension, and had problems for a long time after the problem had been resolved.
Guys, this bug is not the right place to discuss the binary compatibility strategy for mozilla. First off, bugzilla bugs is where we discuss individual problems, policy decisions tend to be made in the newsgroups. Second not nearly all of the relevant parties are present, in fact, I would say that none of the people the people needed to make a final call is present in this bug (i.e. i'm not one of those people).

So for discussions about binary compatibility policies, I'd urge you to go to the mozilla.dev.platform newsgroup. It also is available as a mailing list if you prefer that.
blocking2.0: ? → -
I filed bug 599860 to handle remaining [@ FindNamedItems ] crashes.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Crash Signature: [@ nsGenericElement::DestroyContent() ] [@ FindNamedItems ] [@ nsFrame::~nsFrame() ] [@ UnionExpr::evaluate(txIEvalContext*, txAExprResult**) ] [@ nsNodeWeakReference::QueryReferent(nsID const&, void**) ]
Crash Signature: [@ nsGenericElement::DestroyContent() ] [@ FindNamedItems ] [@ nsFrame::~nsFrame() ] [@ UnionExpr::evaluate(txIEvalContext*, txAExprResult**) ] [@ nsNodeWeakReference::QueryReferent(nsID const&, void**) ] → [@ nsGenericElement::DestroyContent() ] [@ FindNamedItems ] [@ nsFrame::~nsFrame() ] [@ UnionExpr::evaluate(txIEvalContext*, txAExprResult**) ] [@ nsNodeWeakReference::QueryReferent(nsID const&, void**) ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: