Closed Bug 400735 Opened 17 years ago Closed 17 years ago

New startup crash [@ nsXBLBinding::AllowScripts]

Categories

(Core :: XBL, defect)

1.8 Branch
x86
Windows XP
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: samuel.sidler+old, Assigned: sicking)

References

()

Details

(4 keywords)

Crash Data

Attachments

(1 file, 2 obsolete files)

A new topcrash has appeared in Firefox 2.0.0.8. It looks to be Windows-only and Dan says it's a result of the XBL rewrite.

Sample stack from Windows Vista (TB37237703):

Stack Signature	 nsXBLBinding::AllowScripts c18d9b85
Product ID	Firefox2
Build ID	2007100816
Trigger Time	2007-10-22 11:59:35.0
Platform	Win32
Operating System	Windows NT 6.0 build 6000
Module	firefox.exe + (0029bfd8)
URL visited	
User Comments	I am starting firefox under vista
Since Last Crash	1 sec
Total Uptime	33971 sec
Trigger Reason	Access violation
Source File, Line No.	c:/builds/tinderbox/Fx-Mozilla1.8-Release/WINNT_5.2_Depend/mozilla/content/xbl/src/nsXBLBinding.cpp, line 1222
Stack Trace 	
nsXBLBinding::AllowScripts  [mozilla/content/xbl/src/nsXBLBinding.cpp, line 1222]
nsXBLBinding::ExecuteAttachedHandler  [mozilla/content/xbl/src/nsXBLBinding.cpp, line 794]
nsDocument::EndUpdate  [mozilla/content/base/src/nsDocument.cpp, line 2269]
mozAutoDocUpdate::~mozAutoDocUpdate  [../../../../dist/include/content/nsIDocument.h, line 938]
nsGenericElement::RemoveChildAt  [mozilla/content/base/src/nsGenericElement.cpp, line 2915]
nsXULElement::RemoveChildAt  [mozilla/content/xul/content/src/nsXULElement.cpp, line 1273]
nsContentOrDocument::RemoveChildAt  [mozilla/content/base/src/nsGenericElement.cpp, line 2968]
nsGenericElement::doReplaceOrInsertBefore  [mozilla/content/base/src/nsGenericElement.cpp, line 3618]
nsGenericElement::InsertBefore  [mozilla/content/base/src/nsGenericElement.cpp, line 3073]
XPCWrappedNative::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2169]
XPC_WN_CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1375]
js_Interpret  [mozilla/js/src/jsinterp.c, line 3946]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1394]
nsXPCWrappedJSClass::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1453]
nsXPCWrappedJS::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
SharedStub  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147]
nsEventListenerManager::HandleEventSubType  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1655]
nsEventListenerManager::HandleEvent  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1762]
nsGlobalWindow::HandleDOMEvent  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 1733]
nsXULDocument::HandleDOMEvent  [mozilla/content/xul/document/src/nsXULDocument.cpp, line 1238]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2214]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleChromeEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2897]
nsGlobalWindow::HandleDOMEvent  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 1720]
DocumentViewerImpl::LoadComplete  [mozilla/layout/base/nsDocumentViewer.cpp, line 1014]
nsDocShell::EndPageLoad  [mozilla/docshell/base/nsDocShell.cpp, line 4822]
nsWebShell::EndPageLoad  [mozilla/docshell/base/nsWebShell.cpp, line 673]
nsDocShell::OnStateChange  [mozilla/docshell/base/nsDocShell.cpp, line 4737]
nsDocLoader::FireOnStateChange  [mozilla/uriloader/base/nsDocLoader.cpp, line 1210]
nsDocLoader::doStopDocumentLoad  [mozilla/uriloader/base/nsDocLoader.cpp, line 844]
nsDocLoader::OnStopRequest  [mozilla/uriloader/base/nsDocLoader.cpp, line 665]
nsLoadGroup::RemoveRequest  [mozilla/netwerk/base/src/nsLoadGroup.cpp, line 732]
nsDocument::UnblockOnload  [mozilla/content/base/src/nsDocument.cpp, line 5064]
nsBindingManager::ProcessAttachedQueueEvent::~ProcessAttachedQueueEvent  [mozilla/content/xbl/src/nsBindingManager.cpp, line 1411]
0x778b0c24
0x2df2e804
0x0e8b0000
0x74084139
0xc8835f06
0x8bc35eff
0x89480847
0x0d750847
0x5e5f168b
0x04245489
0x00064fe9
0xc0335f00
0x9090c35e
0x90909090
0x90909090
0x2dbae856
0x4c8b0000
0x518b0824
0x8b128b04
0xf03b0872
0x8b04755e
0x33c30841


Sample stack from Windows XP (TB37236972):

Stack Signature	 nsXBLBinding::AllowScripts 8027da8c
Product ID	Firefox2
Build ID	2007100816
Trigger Time	2007-10-22 11:41:34.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (0029bfd8)
URL visited	
User Comments	
Since Last Crash	4 sec
Total Uptime	11706 sec
Trigger Reason	Access violation
Source File, Line No.	c:/builds/tinderbox/Fx-Mozilla1.8-Release/WINNT_5.2_Depend/mozilla/content/xbl/src/nsXBLBinding.cpp, line 1222
Stack Trace 	
nsXBLBinding::AllowScripts  [mozilla/content/xbl/src/nsXBLBinding.cpp, line 1222]
nsXBLBinding::ExecuteAttachedHandler  [mozilla/content/xbl/src/nsXBLBinding.cpp, line 794]
nsDocument::EndUpdate  [mozilla/content/base/src/nsDocument.cpp, line 2269]
mozAutoDocUpdate::~mozAutoDocUpdate  [../../../../dist/include/content/nsIDocument.h, line 938]
nsGenericElement::RemoveChildAt  [mozilla/content/base/src/nsGenericElement.cpp, line 2915]
nsXULElement::RemoveChildAt  [mozilla/content/xul/content/src/nsXULElement.cpp, line 1273]
nsContentOrDocument::RemoveChildAt  [mozilla/content/base/src/nsGenericElement.cpp, line 2968]
nsGenericElement::doReplaceOrInsertBefore  [mozilla/content/base/src/nsGenericElement.cpp, line 3618]
nsGenericElement::InsertBefore  [mozilla/content/base/src/nsGenericElement.cpp, line 3073]
XPCWrappedNative::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2169]
XPC_WN_CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1375]
js_Interpret  [mozilla/js/src/jsinterp.c, line 3946]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1394]
nsXPCWrappedJSClass::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1453]
nsXPCWrappedJS::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
SharedStub  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147]
nsEventListenerManager::HandleEventSubType  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1655]
nsEventListenerManager::HandleEvent  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1762]
nsGlobalWindow::HandleDOMEvent  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 1733]
nsXULDocument::HandleDOMEvent  [mozilla/content/xul/document/src/nsXULDocument.cpp, line 1238]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2214]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2211]
nsXULElement::HandleChromeEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2897]
nsGlobalWindow::HandleDOMEvent  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 1720]
DocumentViewerImpl::LoadComplete  [mozilla/layout/base/nsDocumentViewer.cpp, line 1014]
nsDocShell::EndPageLoad  [mozilla/docshell/base/nsDocShell.cpp, line 4822]
nsWebShell::EndPageLoad  [mozilla/docshell/base/nsWebShell.cpp, line 673]
nsDocShell::OnStateChange  [mozilla/docshell/base/nsDocShell.cpp, line 4737]
nsDocLoader::FireOnStateChange  [mozilla/uriloader/base/nsDocLoader.cpp, line 1210]
nsDocLoader::doStopDocumentLoad  [mozilla/uriloader/base/nsDocLoader.cpp, line 844]
nsDocLoader::OnStopRequest  [mozilla/uriloader/base/nsDocLoader.cpp, line 665]
nsLoadGroup::RemoveRequest  [mozilla/netwerk/base/src/nsLoadGroup.cpp, line 732]
nsDocument::UnblockOnload  [mozilla/content/base/src/nsDocument.cpp, line 5064]
nsBindingManager::ProcessAttachedQueueEvent::~ProcessAttachedQueueEvent  [mozilla/content/xbl/src/nsBindingManager.cpp, line 1411]
0x778b0c24
nsSVGTextFrame::nsSVGTextFrame  [mozilla/layout/svg/base/src/nsSVGTextFrame.cpp, line 233]
0x029a0292
0x00340000
Flags: blocking1.8.1.9?
Flags: blocking1.8.1.10?
Most of the comments seem to indicate that this crash is happening on startup. Adding that to the summary.

This is probably related to an extension (Flashblock maybe?).

Sample comments:
  * I started firefox and there was a fail error
  * opened firefox 
  * crashed after clicking start bar icon to start open browser
  * Opening after installing the latest update
  * clicked from a link in email then this came up has only happened since 
    updating firefox to f.f 8
  * when starting up, fails to start
  * Attempted to start it... just upgraded Firefox last night
Summary: New Crash [@ nsXBLBinding::AllowScripts] → New startup crash [@ nsXBLBinding::AllowScripts]
Jonas - can you take a look here?
Flags: blocking1.8.1.9? → blocking1.8.1.9+
Assignee: nobody → jonas
Flags: blocking1.8.1.10? → blocking1.8.1.10+
I'll look at this, but it would be a huge help if someone could come up with steps to reproduce.
Fwiw, bug 292717 seemed to have a testcase that crashed with a similar stack as this one.
Attached file iframe document, needed for testcase (obsolete) —
Ok, I think I managed to get a testcase that crashes with this stack trace on branch. The testcase that I'll attach should crash within 500ms.
Attached file testcase (obsolete) —
Hmm.  I wonder whether we're hitting EM restart weirdness here or something.  smaug, can we port bug 373911 to branch without too much pain?
Depends on: 373911
Martijn: I'm unable to crash with any of the attached testcases. Do I need to run them in any particular way? What platform are you on?
I'm on windowsXP. The testcase should just crash on load.
Did you try out the testcases in bug 373911, they are basically the same, more or less.
Checked in patch for Bug 373911, attachment 285804 [details] doesn't crash for me anymore.
Marking fixed in hopes that the crash we know about is in fact the crash users are suffering from. Won't know for sure until after we ship, unfortunately.
no crash for me with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.9pre) Gecko/2007102404 BonEcho/2.0.0.9pre after tests with the  testcase from this Bug.

-> Adding verified keyword
What are these testcases based on? Bug 373911 is all about xbl destructors, but the stack here shows us crashing while in xbl constructors.
The fact that both crash in nsXBLBinding::AllowScripts I suspect is because both call functions on deleted nxXBLBindings.
I don't think these testcases are about this bug at all. Is anyone really crashing with nsXBLBinding::ExecuteAttachedHandler on the stack
So...  Looking at the stacks, we're crashing because the binding's mBoundElement is somehow busted (has a non-null bogus GetOwnerDoc()), right?  At least if the line number can be trusted?

That does make it likely that we're talking deleted bindings.  The question is how.  The binding manager holds a strong ref to its bindings, right?  The event is holding a strong ref to the binding manager... then again we're really running constructors for a document different from the one that posted the event, I think.

I'd love to have an idea of what's calling nsBindingManager::ProcessAttachedQueueEvent::~ProcessAttachedQueueEvent.  The stacks in this bug seem to be bogus-ish down there.
Just something I noticed while reading the code (may not cause the problem);
should ~ProcessAttachedQueueEvent keep strong pointer to the document when 
calling UnblockOnload()? Document owns bindingmanager, but bm has only raw
pointer back to document.
Hmm.  That's probably a good idea, yes.
Another thing that is weird here is that nsGenericElement::RemoveChildAt ends up executing XBL ctors. All we should have done between its BeginUpdate and EndUpdate is removing elements which should not add to the queue. Additionally, there is an mozAutoDocUpdate living higher up on the stack in nsGenericElement::doReplaceOrInsertBefore, so we should still be waiting for the last EndUpdate and not even looking at xbl.

I wonder if it simply is the document dying from the missing strong reference after all...
> is removing elements which should not add to the queue.

Removing elements can trigger frame reconstructs (e.g. with {ib} splits), which could in fact run XBL ctors...  Now that sort of thing _shouldn't_ be happening in our UI, I would hope.

> there is an mozAutoDocUpdate living higher up on the stack in
> nsGenericElement::doReplaceOrInsertBefore

It's only a real update batch if we're replacing or if we're inserting a document fragment.
(In reply to comment #25)
> > is removing elements which should not add to the queue.
> 
> Removing elements can trigger frame reconstructs (e.g. with {ib} splits), 
> which could in fact run XBL ctors...  Now that sort of thing _shouldn't_ be 
> happening in our UI, I would hope.

That shouldn't add new bindings to the attached-stack though, would it? Though I guess in theory any sort of new style rules could kick in and attach new bindings.

However it seems unlikely that that is what's happening here.

> > there is an mozAutoDocUpdate living higher up on the stack in
> > nsGenericElement::doReplaceOrInsertBefore
> 
> It's only a real update batch if we're replacing or if we're inserting a
> document fragment.

Doh! Very true. That explains some of the weirdness I thought was there.
Hi

I don't know, if I can help. But I received an email from Mozilla Security concerning this crash, asking me, if I had any add-ons installed.

And yes, I have. This crash started, after I had installed a theme called Modern Aluminum and Nasa Night Launch. I had also installed some Dictionaries. After this, it started to crash at start up. Oh yes, and I had asked Firefox to, every time it opens, show my last screen. 

Now I set it to default, so it shows my homepage at start up - this has stopped the crashes. 

Please tell if information like this can help - so I know, if I should tell another time.

Regards

Daniel, 

Denmark
Attached patch This might workSplinter Review
I found one bug that might be the cause of this. When we're adding bindings to the mAttachedStack in order to execute their ctor we add binding->GetFirstBindingWithConstructor, however when removing, we try to remove the binding itself. This means that if:

1. A binding is attached to the element
2. The binding doesn't have a constructor, but one of its inherited bindings do
and
3. The element looses the binding (and is potentially destroyed) before we
   execute the constructor

We will execute the constructor when we shouldn't, potentially after the element has gone away.

I also added the strong reference while calling doc->UnblockOnload just in case.

While reviewing, plase add any concerns about potential regressions since this will get very little testing. I can't think of any risks here though.

(marking testcases obsolete since they don't apply to this bug)
Attachment #285803 - Attachment is obsolete: true
Attachment #285804 - Attachment is obsolete: true
Attachment #286107 - Flags: superreview?
Attachment #286107 - Flags: review?(Olli.Pettay)
Do we need a similar change on trunk?  Or not with your change to implementation installation?
Attachment #286107 - Flags: superreview? → superreview?(jst)
I've installed:

Themes:
Aluminium Kai
Nasa Nigth Launch
Red Shift V2

Add-ons
Adblock
Bookmark Dublicate Detector
Cookiesafe
Del.icio.us bookmarks
DOM inspector
Downloadhelper
DownThemAll
FastVideoDownload
FasterFox
Flashgot
Gmail Manager
Google Browse Sync
Google Calendar Notifier
Google Calender Quick Add
Google Video Downloader
IE TAB
NoScript
OpenTaalWoordenlijst
Talkback
United States English Dictionary
VideoDownloader
Woordenboek Nederlands

Comment on attachment 286107 [details] [diff] [review]
This might work

sr=jst
Attachment #286107 - Flags: superreview?(jst) → superreview+
(In reply to comment #27)
[...]
> Please tell if information like this can help - so I know, if I should tell
> another time.

Hello Daniel,

Yes, this kind of information is helpful in general. The more details the better generally. Thank you.
Comment on attachment 286107 [details] [diff] [review]
This might work

approved for 1.8.1.9/1.8.1.10 pending r+ from Smaug, a=dveditz

Please land on GECKO181_200710004_RELBRANCH for 1.8.1.9, the regular 1.8 branch for 1.8.1.10
Attachment #286107 - Flags: approval1.8.1.9?
Attachment #286107 - Flags: approval1.8.1.9+
Attachment #286107 - Flags: approval1.8.1.10+
Olli, feel free to only land on the 1.8.1.9 minibranch, i can take care of the other branches if you'd like.

Boris: As things stand now we do need to land on trunk. But my installimplementation patch would fix it too.
Comment on attachment 286107 [details] [diff] [review]
This might work

Ugh, nsIXBLService::LoadBindings' out param is misleading.
Attachment #286107 - Flags: review?(Olli.Pettay) → review+
Checked in to GECKO181_20071004_RELBRANCH (that is the right branch, not GECKO181_200710004_RELBRANCH, right?) and MOZILLA_1_8_BRANCH.
Setting fixed1.8.1.9, fixed1.8.1.10, but some verification is needed.
Daniel, John (and whoever crashs with this talkback crash signature): Can you try the latest Nightly 1.8 Windows Build (the firefox-2.0.0.9pre.en-US.win32.installer.exe) from: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/
if you still crash ? In this build the patch form this bug is included.

Thanks ! :-)
John already tried out the latest 1.8 branch build, this is what he replied to me:
"
Hi, Martijn - I installed firefox-2.0.0.9pre.en-US.win32.installer.exe from
the link below, and it installed Bon Echo version 2.0.0.9pre.  I have
completely exited, verified that firefox.exe was no longer loaded, and
restarted, BE more than 10 times without any startup problems.

I just tried running Firefox, and it crashed upon startup (I *did* send the
error report and referenced this bug #)

Looks like the patch might have fixed the startup problem.

I'll run with Bon Echo today - hopefully it's stable enough.  I'll continue
to try Firefox every now and then until the next update comes down.
"

So it seems that it fixes the startup crash for John (fingers crossed).
I'm not completely sure he tested with today's 1.8 build or yesterday's 1.8 build, though.
(In reply to comment #37)
> Daniel, John (and whoever crashs with this talkback crash signature): Can you
> try the latest Nightly 1.8 Windows Build (the
> firefox-2.0.0.9pre.en-US.win32.installer.exe) from:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/
> if you still crash ? In this build the patch form this bug is included.
> 
> Thanks ! :-)
> 

I'll try it right away.
I have installed now. What is this Bon Echo? :)

It didnt crash EVERY time, I started Firefox, so I dont know, if it has helped anything yet.
"Bon Echo" is the code name for pre-release/testing versions of Firefox 2. We change the in-product branding so people know they don't have an official release version (particularly handy for active testers who switch back and forth -- sometimes you can forget which one you're using).

When Firefox 2.0.0.9 is released please switch back to branded versions of Firefox.
Thank you, Daniel :)

It may be a stupid question, but how do I switch back, and will I be noticed, when the new is released?

Since this is branch-only it can be marked FIXED over-all
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
The crash may be, but the underlying bug is not.  See comment 34...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #42)
> how do I switch back, and will I be noticed, when the new is released?

If you stick with "Bon Echo" you will get a new test build every day. Unless you're a tester you will probably find this annoying.

To switch back, install any version of Firefox 2 and it will upgrade when the new release is available. If you've installed them in separate directories (which is the default) you probably still have Firefox 2.0.0.8 and can just start using it again.
Ah, great :)

Who ever you are, you are some pretty amazing programmers.
I have switched back, and the bug is still there. I am just gonna wait for a Firefox-update. Again, I solved the problem by choosing " Show Homepage at start-up".
Comment on attachment 286107 [details] [diff] [review]
This might work

Would be great to get this on trunk too, just to get more testing on it.
Attachment #286107 - Flags: approvalM9?
Comment on attachment 286107 [details] [diff] [review]
This might work

a=endgame drivers for M9
Attachment #286107 - Flags: approvalM9?
Attachment #286107 - Flags: approvalM9+
Attachment #286107 - Flags: approval1.9+
Marking this FIXED as the patch in bug 345711 happens to fix this one as well. So the patch never ended up landing on trunk as it's not needed any more.
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
Comment on attachment 286107 [details] [diff] [review]
This might work

Resetting flags as this is no longer needed.
Attachment #286107 - Flags: approvalM9+
Attachment #286107 - Flags: approval1.9+
Flags: in-testsuite?
We don't need the strong ref to document on trunk?
Doh!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment on attachment 286107 [details] [diff] [review]
This might work

Putting back flags i errorously reset.
Attachment #286107 - Flags: approvalM9+
Attachment #286107 - Flags: approval1.9+
Flags: blocking1.9?
My Bad :(

patch already have:
approval1.9+
approvalM9+
(In reply to comment #45)
> (In reply to comment #42)
> > how do I switch back, and will I be noticed, when the new is released?
> 
> If you stick with "Bon Echo" you will get a new test build every day. Unless
> you're a tester you will probably find this annoying.
> 
> To switch back, install any version of Firefox 2 and it will upgrade when the
> new release is available. If you've installed them in separate directories
> (which is the default) you probably still have Firefox 2.0.0.8 and can just
> start using it again.
> 

To have BonEcho warn you when a new release of Firefox is available (and not install a new version every day), install the "Update Channel Selector" extension and select the "Release" channel from that extension's preferences. (Note: setting it by hand in about:config , prefs.js or user.js doesn't work. Don't ask me why.) Also, you might want to select "Ask me what I want to do" under Tools => Options => Advanced => Update.
Thanks.
(In reply to comment #56)
> To have BonEcho warn you when a new release of Firefox is available (and not
> install a new version every day), install the "Update Channel Selector"
> extension and select the "Release" channel from that extension's preferences.
> (Note: setting it by hand in about:config , prefs.js or user.js doesn't work.
> Don't ask me why.) Also, you might want to select "Ask me what I want to do"
> under Tools => Options => Advanced => Update.

Tony, you're saying something different to comment #45. The nightly channel is the odd-one-out, working differently from all others (release etc).
 * on nightly, you're always offered the most recent nightly build from the same branch, regardless of the particular build you're using now
 * on release, only specific builds are offered the latest release

So if you have some Bon Echo build on nightly, and you switch to release, then you won't get any updates (as the nightly buildID and version don't match any prior releases). That's why dveditz suggested installing a release version of Firefox 2.
(In reply to comment #58)
[...]
> So if you have some Bon Echo build on nightly, and you switch to release, then
> you won't get any updates (as the nightly buildID and version don't match any
> prior releases). That's why dveditz suggested installing a release version of
> Firefox 2.
> 

ah, sorry, I thought it would work. OTOH installing a release version of Fx2 (built before the patch landed, there aren't any others yet) as suggested in comment #45, certainly wouldn't cure the crash. Unless you keep that Fx2 release build on somme innocuous page (such as about: ) and do _not_ browse with it (browse with BonEcho instead), but use it _only_ to watch for updates.
is this fixed on 2.0.0.9 (RC1) ?
(In reply to comment #60)
> is this fixed on 2.0.0.9 (RC1) ?

It should be. Please test that it does!
(In reply to comment #61)
> (In reply to comment #60)
> > is this fixed on 2.0.0.9 (RC1) ?
> 
> It should be. Please test that it does!
> 

no startup-crash both 2.0.0.8 and 2.0.0.9(RC) for me.

but this is not marked as "fixed", marked as "reopened"
why? what for ?
not completely fixed yet ?
Checked in the remaining parts to trunk.

pal-moz, the fixedx.x.x.x keywords are used to track branch status of a bug. We only mark it FIXED once it's fixed on trunk, which this wasn't.
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
(In reply to comment #63)
> Checked in the remaining parts to trunk.
> 
> pal-moz, the fixedx.x.x.x keywords are used to track branch status of a bug. We
> only mark it FIXED once it's fixed on trunk, which this wasn't.
> 

OK, understood. thanks.
The incoming crash data on the 2.0.0.9 release candidate does not show any crashes at this location, but given the total number of crashes we'd only expect one or two reports so there are not yet enough data to be conclusive. Anecdotally half a dozen people who were regularly experiencing this crash in 2.0.0.8 have reported that 2.0.0.9 fixes the problem, and none report that it does not (but that's out of 150 or so mails sent out so not a great response rate).
An anecdotal comment.   This bug fix, it seems, has eliminated a persistent and annoying history of crashes [with and without talkback sessions] with the recent versions of 2.--x.

These crashes, or more accurately, the propensity of crashes while operating [not just on startup] seems to come and go in waves.  There have been 3 or 4 episodes of this that I remember over the course of versions 1.5.x and into 2.009.  They waves start up with an update, and persist, and then disappear, with some subsequent update.

I mention this, as I wonder if there is some meta process that could be changed that might minimize the appearance of these unexplained crashes, until someone identifies a particular bug that, for all intensive purpose, is unknown to the users, and where the crashes have been unsolvable.

Would the meta changes be a shift in the attention to assumptions made by various routines in the mass of code which is Fox?   Is there a global search/pattern that could be undertaken that would flush out potential future problems?   Are the [if there is even one assumption...] routines' assumptions not fully documented in some way, so that users of called routines, see the assumptions, and might be more likely to encode and anticipate?   Does the existence of these assumptions, or the non documentation or non awareness...  could this be an artifact of the way, particularly, the Fox software is organized [ as opposed to the nature of the collaborative programming that is Moz and Fox, generally?]

I mention these ideas, because I am superbly and genuinely appreciative of the dedicated and professional [and even hobby] programmers who contribute to Moz/Fox/etc., but also tested by the crashes which run amok and unexplained.

Consequently, I wonder if adjustments to the process, or something, might lessen the chances of error.  I realize there is no quick fix, coming from initiating these thoughts; but felt that they would be useful, in addition to providing an anecdotal addition to this fixes comments. 

--bs/ms engr., jd 
If the crashes have disappeared they probably were due to this bug and are now fixed. So all is well, no?
Absolutely no sign of nsXBLBinding::AllowScripts crashes in FF2.0.0.9 talkback reports. Unlike my tentative report in comment 65 we now have a definitive amount of feedback and can confidently put this one to rest.
Flags: blocking1.8.1.11+ → blocking1.8.1.10+
That is fantastic. Well done everyone!
Status: RESOLVED → VERIFIED
Marking "verified1.8.1.10" as this was already "verified1.8.1.9" and we haven't touched this since 1.8.1.9.
Since there's no reproducible testcase we didn't verify 1.8.1.9 until we got crash-data back. 1.8.1.10 shipped from a different branch, and no matter how small the chance, there might have been a screw-up landing it. We can't really claim verified just because it worked on a different branch. A CVS diff of the two branches might suffice, but I'd be happier waiting for beta crash-data.
I didn't realize that we'd landed it separately. You're right.
we should verify what to do on 1.8.0 after bug 373911 landed.
Flags: blocking1.8.0.15?
Flags: blocking1.8.0.15? → blocking1.8.0.15+
Crash Signature: [@ nsXBLBinding::AllowScripts]
You need to log in before you can comment on or make changes to this bug.