4.0b11pre crash [@ NotificationController::TextEnumerator(nsPtrHashKey<nsIContent>*, void*) ][@ nsINode::GetFlags()]

RESOLVED FIXED in mozilla2.0b11

Status

()

Core
Disability Access APIs
P1
critical
RESOLVED FIXED
7 years ago
2 years ago

People

(Reporter: chris hofmann, Assigned: surkov)

Tracking

({crash, regression, topcrash})

unspecified
mozilla2.0b11
x86
Windows XP
crash, regression, topcrash
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(blocking2.0 betaN+, status1.9.2 unaffected)

Details

(Whiteboard: [ignore comments 0-29][sg:critical?][hardblocker][has patch], crash signature, URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
possible new crash on mozilla-central maybe first appearing in 
build 2011 01 28 030208

stack looks like
https://crash-stats.mozilla.com/report/index/e944c84d-58d8-4d56-bf6f-5c6632110129

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	NotificationController::TextEnumerator 	accessible/src/base/NotificationController.cpp:601
1 	xul.dll 	NotificationController::QueueEvent 	accessible/src/base/NotificationController.cpp:139
2 	xul.dll 	nsTArray<nsAutoPtr<nsPropertyTable>,nsTArrayDefaultAllocator>::~nsTArray<nsAutoPtr<nsPropertyTable>,nsTArrayDefaultAllocator> 	obj-firefox/dist/include/nsTArray.h:373
3 	xul.dll 	PL_DHashTableEnumerate 	obj-firefox/xpcom/build/pldhash.c:754
4 	xul.dll 	nsTArray_base<nsTArrayInfallibleAllocator>::ShrinkCapacity 	obj-firefox/dist/include/nsTArray-inl.h:135
5 	xul.dll 	NotificationController::WillRefresh 	accessible/src/base/NotificationController.cpp:247
6 	xul.dll 	nsTArray<nsAutoPtr<nsPropertyTable>,nsTArrayDefaultAllocator>::~nsTArray<nsAutoPtr<nsPropertyTable>,nsTArrayDefaultAllocator> 	obj-firefox/dist/include/nsTArray.h:373
7 	xul.dll 	PresShell::FlushPendingNotifications 	layout/base/nsPresShell.cpp:4924
8 	xul.dll 	NotificationController::CreateTextChangeEventFor 	accessible/src/base/NotificationController.cpp:574
9 	xul.dll 	nsRefreshDriver::Notify 	layout/base/nsRefreshDriver.cpp:254
10 	user32.dll 	user32.dll@0x1baf8 	
11 	user32.dll 	user32.dll@0x1bd31 	
12 	xul.dll 	xul.dll@0xa3776f 	
13 	nspr4.dll 	PR_AssertCurrentThreadOwnsLock 	nsprpub/pr/src/threads/combined/prulock.c:404
14 	xul.dll 	mozilla::TimeDuration::ToSeconds 	xpcom/ds/TimeStamp.cpp:63
15 	nspr4.dll 	PR_Unlock

more reports at:

https://crash-stats.mozilla.com/report/list?signature=NotificationController%3A%3ATextEnumerator(nsPtrHashKey<nsIContent>*%2C void*)&version=Firefox%3A4.0b11pre

source at the top of the stack appears to have been recently changed.

2011-01-28 16:42 +0800	Alexander Surkov - Bug 625652 - make sure accessible tree is correct when rendered text is changed, r=davidb, sr=roc, a=roc

2011-01-28 13:15 +0800	Alexander Surkov - Bug 629394, part3 - replace do_QueryObject on AsHyperText, r=fer, a=davidb

2011-01-28 12:37 +0800	Alexander Surkov - Bug 606924, part5 - rename GetCachedAccessible, r=fer, a=final+

2011-01-26 14:35 +0800	Alexander Surkov - Bug 606924, part3 - handing document concept, r=davidb, a=blocking2.0Final+

2011-01-24 10:58 +0800	Alexander Surkov - Bug 606924, part2 - create initial tree, r=davidb, a=blocking2.0Final+

base	Alexander Surkov - Bug 498015 - update accessible tree on content insertion after layout, r=davidb, sr=bz, a=blockingBetaN
(Reporter)

Comment 1

7 years ago
rising pretty fast, so this should probably block b11.
blocking1.9.2: --- → ?
Thanks Chris, easy fix coming.
Assignee: nobody → bolterbugz
blocking1.9.2: ? → ---
blocking2.0: --- → betaN+
Whiteboard: [hardblocker]
Actually I'm not sure why this is failing yet.
This stack is interesting:
https://crash-stats.mozilla.com/report/index/81503836-b361-4e49-8e9c-eefcd2110129

0 	xul.dll 	NotificationController::TextEnumerator 	accessible/src/base/NotificationController.cpp:604
1 	xul.dll 	nsCycleCollector::Suspect2 	xpcom/base/nsCycleCollector.cpp:2363
2 	mozcrt19.dll 	arena_dalloc_small 	obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:4158
3 	xul.dll 	NotificationController::QueueEvent 	accessible/src/base/NotificationController.cpp:139
4 	xul.dll 	nsTArray<nsAutoPtr<nsPropertyTable>,nsTArrayDefaultAllocator>::~nsTArray<nsAutoPtr<nsPropertyTable>,nsTArrayDefaultAllocator> 	obj-firefox/dist/include/nsTArray.h:373
5 	xul.dll 	PL_DHashTableEnumerate 	obj-firefox/xpcom/build/pldhash.c:754
6 	xul.dll 	nsTArray_base<nsTArrayInfallibleAllocator>::ShrinkCapacity 	obj-firefox/dist/include/nsTArray-inl.h:135
7 	xul.dll 	NotificationController::WillRefresh
So far all the stacks look like they are on amd64 hardware.
CC'ing dbaron because he's awesome, and also might know something about the stack in comment 4.
Jonas, how does AbortIfOffMainThreadIfCheckFast work?
Keywords: regression, testcase-wanted
Unassigning as I can't own this for the next while ( AFK :( )
Assignee: bolterbugz → nobody

Comment 9

7 years ago
This is the third topcrasher on b11pre.
Keywords: topcrash
AbortIfOffMainThreadIfCheckFast is used to exit firefox if you try to addref or release a cycle collected object from any thread other than the main thread. I.e. if you're trying to use mainthread-only objects on other threads.

So if you're seeing that at the top of a crash stack, then you're having a threading issue of some sort.

Unfortunately crash-stats seems to be having some issue right now so can't look at the stacks there.

(The "IfCheckFast" part of the name is there since the function is a no-op on platforms where we can't quickly check if we're currently on the main thread.)

Comment 11

7 years ago
I don't see AbortIfOffMainThreadIfCheckFast anywhere on the stack.

The bug here seems rather simple.  This comment <http://hg.mozilla.org/mozilla-central/annotate/993b69aa088a/accessible/src/base/NotificationController.cpp#l584> seems to say that the node is guaranteed to be in the document, because if it has been removed, the content removal notification has removed it from the hashtable.  But that's clearly not the case at all.  In fact, I can't find any code which removes any content node from mTextHash anywhere (it's just cleared at times), so no wonder we crash when we try to get the parent pointer without checking its validity.

A wallpaper fix would be to bail out if !textNode->IsInDoc(), but I don't know if that's the right fix here.  Maybe we should do what the comment says?
Many of the crashes are reads from 0xffffffffffffffff or near-null which is not too worrying, but a bunch have intermediate values. A few look clearly exploitable, e.g. bp-8d22f1c9-140a-4f01-af82-40e742110129 . "moderate" because it doesn't look like a reliable vector, but it could be worse.

Why is this only amd64? Is there some external accessibility software or driver involved in the crash? The correlations tab says "ERROR: No reports generated on 20110129 for Firefox 4.0b11pre." :-(
Whiteboard: [hardblocker] → [sg:moderate][hardblocker]
(Assignee)

Comment 13

7 years ago
(In reply to comment #11)

> A wallpaper fix would be to bail out if !textNode->IsInDoc(), but I don't know
> if that's the right fix here.  Maybe we should do what the comment says?

If you're right then we could do
- if (!containerNode) {
+ if (!containerNode || !textNode->IsInDoc()) {

but honestly stack is confusing.
I filed a possible dupe of this in bug 629995. Saw that crasher once in current nightly build. However the top of the stack is different than this bug, so am unsure. Maybe it helps! The crash ID from that bug is:
bp-451b86fd-8662-4040-9bd3-776732110130 .

Updated

7 years ago
Duplicate of this bug: 629995
(Assignee)

Comment 16

7 years ago
Could it because nsIContent is not addrefed? If so then we could either keep nsCOMPtr instead of nsIContent or remove entries from hash when accessible subtree is shutdown.
(Assignee)

Comment 17

7 years ago
Created attachment 508232 [details] [diff] [review]
patch

this should fix either case (comment #11 or comment #16)
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #508232 - Flags: review?(bolterbugz)
Summary: 4.0b11pre crash [@ NotificationController::TextEnumerator(nsPtrHashKey<nsIContent>*, void*) ] → 4.0b11pre crash [@ NotificationController::TextEnumerator(nsPtrHashKey<nsIContent>*, void*) ][@ nsINode::GetFlags()]
Comment on attachment 508232 [details] [diff] [review]
patch

r=me thanks Alexander.
Attachment #508232 - Flags: review?(bolterbugz) → review+
(Assignee)

Comment 19

7 years ago
Created attachment 508241 [details] [diff] [review]
part1v2 (landed 2011-01-30)

updated to trunk (I assume bug 626660 will be checked in after this one).
Attachment #508232 - Attachment is obsolete: true
Would be nice if this could get landed today, this crash (under various signatures) is 4 of the 5 topcrashes on nightlies.
(Reporter)

Comment 21

7 years ago
we definitely need this fix before beta 11 gets shipped, and freeze date for that is Tuesday.  It would be nice to have a few builds to verify the reductions in crashes.   This needs to be changed from "beta N+" to "beta1 1 +"

Updated

7 years ago
Blocks: 630014

Updated

7 years ago
Whiteboard: [sg:moderate][hardblocker] → [sg:moderate][hardblocker][has patch]
Severity: normal → critical
Priority: -- → P1
(Assignee)

Comment 22

7 years ago
landed on 2.0 beta 11 - http://hg.mozilla.org/mozilla-central/rev/46c4c8b31b60
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b11
(Assignee)

Comment 23

7 years ago
I can reproduce Marco's crash (bug 629995).

 	xul.dll!nsINode::GetFlags()  Line 858 + 0x14 bytes	C++
 	xul.dll!nsINode::HasFlag(unsigned long aFlag)  Line 853 + 0x8 bytes	C++
 	xul.dll!nsINode::IsElement()  Line 378	C++
>	xul.dll!NotificationController::TextEnumerator(nsPtrHashKey<nsIContent> * aEntry, void * aUserArg)  Line 883 + 0xb bytes	C++
 	xul.dll!nsTHashtable<nsPtrHashKey<nsIContent> >::s_EnumStub(PLDHashTable * table, PLDHashEntryHdr * entry, unsigned int number, void * arg)  Line 420 + 0x12 bytes	C++
 	xul.dll!PL_DHashTableEnumerate(PLDHashTable * table, PLDHashOperator (PLDHashTable *, PLDHashEntryHdr *, unsigned int, void *)* etor, void * arg)  Line 754 + 0x19 bytes	C
 	xul.dll!nsTHashtable<nsPtrHashKey<nsIContent> >::EnumerateEntries(PLDHashOperator (nsPtrHashKey<nsIContent> *, void *)* enumFunc, void * userArg)  Line 241 + 0x12 bytes	C++
 	xul.dll!NotificationController::WillRefresh(mozilla::TimeStamp aTime)  Line 249	C++

The text node return bad parent, has not null primary frame that has all null value members (mContent and etc). There's no accessible for this text node. If we weren't in time to create an accessible before text node goes away then the proposed patch doesn't work.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 24

7 years ago
Created attachment 508352 [details] [diff] [review]
part2v1: keep text nodes addrefed (landed 2011-01-31)
Attachment #508352 - Flags: superreview?(neil)
Attachment #508352 - Flags: review?(bolterbugz)
(Assignee)

Updated

7 years ago
Attachment #508241 - Attachment description: patch2 → part1v2
Comment on attachment 508352 [details] [diff] [review]
part2v1: keep text nodes addrefed (landed 2011-01-31)

>+  template<class T>
>+  class nsCOMPtrHashKey : public PLDHashEntryHdr
(This class should probably be moved into nsHashKeys.h at some point.)

If you had noticed nsISupportsHashKey (which is effectively the same as nsCOMPtrHashKey<nsISupports>) you might not have made these two nits:

>+    ~nsCOMPtrHashKey() { mKey = nsnull; }
No need to set mKey here, we're about to destroy it anyway.

>+    KeyType GetKey() const { return mKey.get(); }
No need for the .get() here, the compiler should be able to cast it.
Attachment #508352 - Flags: superreview?(neil) → superreview+
Comment on attachment 508352 [details] [diff] [review]
part2v1: keep text nodes addrefed (landed 2011-01-31)

I'm not davidb, but r=me as per IRC question from Alexander.
Attachment #508352 - Flags: review?(bolterbugz) → review+
(Assignee)

Comment 27

7 years ago
landed with Neil's comments addressed - http://hg.mozilla.org/mozilla-central/rev/732a38102733
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
(Reporter)

Comment 28

7 years ago
not seeing any more reports on mozilla-central builds after 2011 01 31 03 03:35
(Reporter)

Updated

7 years ago
Status: RESOLVED → VERIFIED
(Assignee)

Comment 30

7 years ago
It looks like either mContent of nsTextFrame is dead when a11y is notified from nsTextFrame::TextReflow - http://hg.mozilla.org/mozilla-central/diff/95a9192221ea/layout/generic/nsTextFrameThebes.cpp, either mContent's parent wasn't cleared due to some reason and GetNodeParent() returns dead object (http://hg.mozilla.org/mozilla-central/annotate/26421a3b68f3/accessible/src/base/NotificationController.cpp#l603).

Boris, do you have any ideas?
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 31

7 years ago
(In reply to comment #29)
> I'm still hitting this on today's nightly: 

it's possible that backing out the first part of this patch (CancelTextUpdate stuffs) in bug 631772 triggers this crash (since it was landed yesterday). If we're not able to find actual reason of the bug then we can get back CancelTextUpdate so that it will collect text nodes in additional hash rather than remove them from main hash.
> It looks like either mContent of nsTextFrame is dead when a11y is notified from
> nsTextFrame::TextReflow -

That can't happen.

Looking at the three stacks from comment 29:

1)  Not sure what's going on here.
2)  textNode is null (0xc is the offset of mParentPtrBits in nsINode).
3)  Not sure.

I definitely don't see a way that we could end up with null in that hashtable, barring some sort of memory corruption...

Comment 31 is possible; if you're modifying the hashtable during enumeration, then you could easily read garbage memory.  Don't do that!
(Assignee)

Comment 33

7 years ago
(In reply to comment #32)

> Comment 31 is possible; if you're modifying the hashtable during enumeration,
> then you could easily read garbage memory.  Don't do that!

Text nodes aren't removed from hash when hash is iterated because http://hg.mozilla.org/mozilla-central/rev/2e5aced41e8d was landed 11 Feb and Kyle's build is dated by 13 Feb. 

If the problem is the hash is modified while it's traversed then I could think of only one way. We insert new accessible into a tree when hash is traversed and that somehow triggers nsTextFrame::ReflowText what appends text node into hash.

Kyle, do you have reliable steps to reproduce or can you trigger the crash often enough so that you can say if a patch helps or not?
> Text nodes aren't removed from hash when hash is iterated

OK.  In that case, I'm really not sure what's going on here....  I'd hope inserting new accessibles can't trigger reflow; if it can we have serious problems.  Can you check on that?
(Assignee)

Comment 35

7 years ago
(In reply to comment #34)
> > Text nodes aren't removed from hash when hash is iterated
> 
> OK.  In that case, I'm really not sure what's going on here....  I'd hope
> inserting new accessibles can't trigger reflow;

it shouldn't but iirc we had that in the past

> if it can we have serious
> problems.  Can you check on that?

I can check if we have flush layout stuffs on the stack (and perhaps remove them at all since it should be ok now). But I don't have ideas what else can trigger reflow. Can you give me a hint what should I look for?
> it shouldn't but iirc we had that in the past

Well, any time that happens seems like an exploitable security issue, offhand, so I'd really hope we make sure it can't happen.

> Can you give me a hint what should I look for?

1)  Any time you flush.
2)  Any time you call code you don't control and that might flush.

Examples of #2 would be any DOM API asking for position information, say.  Or scrolling.  Or anything that spins the event loop, of course.

That said, there should be asserts for these sort of things; if we aren't hitting them then chances are we're not doing them.  Then again, do we really do much running of debug builds with a11y enabled?
(Assignee)

Comment 37

7 years ago
I filed bug 634197 for that.
(In reply to comment #33)
> Kyle, do you have reliable steps to reproduce or can you trigger the crash
> often enough so that you can say if a patch helps or not?

Unfortunately not.  I can start running a debug build and see if I'm hitting asserts.  Let me know if you want me to try that.
What are the specific asserts to look for?
Um.... anything about reentering frame construction or reflow, probably?
Alexander, the FF4 endgame drivers would like an ETA on this bug. How about a best case, worst case range? (I realize the difficulty, given investigation is continuing and we have no reliable STR)
David suggests the new crashes might be exploitable. Marking as such.
Group: core-security
Whiteboard: [sg:moderate][hardblocker][has patch] → [sg:critical?][hardblocker][has patch]
(Reporter)

Comment 43

7 years ago
it looks like one of the signatures hasn't been seen since jan30 builds, and the other signature has possibly been reduced in volume back down to the residual level.

        NotificationController::TextEnumerator.nsPtrHashKey.nsIContent..,.void..

date     total    breakdown by build
         crashes  count build, count build, ...


20110207 3 4.0b11pre2011013103 	3 , 
20110208 4  	2 4.0b11pre2011013003, 
        		1 4.0b11pre2011013103, 	1 4.0b11pre2011012803, 
20110209 1 4.0b11pre2011012803 	1 , 
20110210 2  	1 4.0b11pre2011013003, 
        		1 4.0b11pre2011012903, 
20110211 1 4.0b11pre2011013003 	1 , 
20110212 1 4.0b11pre2011013003 	1 , 
20110213   
20110214   


         nsINode::GetFlags..
date     total    breakdown by build
         crashes  count build, count build, ...

20110212 61  	25 3.6.132010120307, 
        		17 4.0b12010063014, 	7 4.0b112011020314, 
        		2 3.6.142011020713, 	1 4.0b12pre2011021103, 
        		1 4.0b11pre2011013003, 	1 4.0b11pre2011012903, 
        		1 4.0b102011012116, 	1 4.0b12010062821, 
        		1 3.6.82010072215, 	1 3.6.142011012114, 
        		1 3.6.132010112205, 	1 3.6.122010102621, 
        		1 3.62010011514, 
20110213 48  	18 3.6.132010120307, 
        		10 4.0b12010063014, 	8 3.5.162010113007, 
        		7 4.0b112011020314, 	2 3.6.102010091412, 
        		1 4.0b72010110414, 	1 3.6.82010072215, 
        		1 3.6.122010102621, 
20110214 56  	26 3.6.132010120307, 
        		12 4.0b112011020314, 	6 4.0b12010063014, 
        		3 3.5.162010113007, 	2 3.7a52010061006, 
        		2 3.0.52008120122, 	1 4.0b12pre2011021403, 
        		1 4.0b12010062821, 	1 3.6.62010062523, 
        		1 3.6.22010031607, 	1 3.6.142011020713,
I'm going to try to catch this in a debug build.
I haven't been able to reproduce a crash, but a11y is definitely being naughty.  Example stack:

>	xul.dll!NS_DebugBreak_P(unsigned int aSeverity, const char * aStr, const char * aExpr, const char * aFile, int aLine)  Line 372	C++
 	xul.dll!PL_DHashTableOperate(PLDHashTable * table, const void * key, PLDHashOperator op)  Line 612 + 0x42 bytes	C
 	xul.dll!nsTHashtable<NotificationController::nsCOMPtrHashKey<nsIContent> >::PutEntry(nsIContent * aKey)  Line 188 + 0xd bytes	C++
 	xul.dll!NotificationController::ScheduleTextUpdate(nsIContent * aTextNode)  Line 160 + 0x12 bytes	C++
 	xul.dll!nsDocAccessible::UpdateText(nsIContent * aTextNode)  Line 320 + 0x12 bytes	C++
 	xul.dll!nsAccessibilityService::UpdateText(nsIPresShell * aPresShell, nsIContent * aContent)  Line 538	C++
 	xul.dll!nsTextFrame::ReflowText(nsLineLayout & aLineLayout, int aAvailableWidth, nsIRenderingContext * aRenderingContext, int aShouldBlink, nsHTMLReflowMetrics & aMetrics, unsigned int & aStatus)  Line 6969	C++
 	xul.dll!nsLineLayout::ReflowFrame(nsIFrame * aFrame, unsigned int & aReflowStatus, nsHTMLReflowMetrics * aMetrics, int & aPushedFrame)  Line 864	C++
 	xul.dll!nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & aState, nsLineLayout & aLineLayout, nsLineList_iterator aLine, nsIFrame * aFrame, LineReflowStatus * aLineReflowStatus)  Line 3812	C++
 	xul.dll!nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & aState, nsLineLayout & aLineLayout, nsLineList_iterator aLine, nsFlowAreaRect & aFloatAvailableSpace, int & aAvailableSpaceHeight, nsFloatManager::SavedState * aFloatStateBeforeLine, int * aKeepReflowGoing, LineReflowStatus * aLineReflowStatus, int aAllowPullUp)  Line 3607 + 0x17 bytes	C++
 	xul.dll!nsBlockFrame::ReflowInlineFrames(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 3467	C++
 	xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 2566	C++
 	xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState)  Line 1999 + 0x13 bytes	C++
 	xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus)  Line 1081	C++
 	xul.dll!nsContainerFrame::ReflowChild(nsIFrame * aKidFrame, nsPresContext * aPresContext, nsHTMLReflowMetrics & aDesiredSize, const nsHTMLReflowState & aReflowState, int aX, int aY, unsigned int aFlags, unsigned int & aStatus, nsOverflowContinuationTracker * aTracker)  Line 740 + 0x16 bytes	C++
 	xul.dll!nsHTMLScrollFrame::ReflowScrolledFrame(ScrollReflowState * aState, int aAssumeHScroll, int aAssumeVScroll, nsHTMLReflowMetrics * aMetrics, int aFirstPass)  Line 535 + 0x2b bytes	C++
 	xul.dll!nsHTMLScrollFrame::ReflowContents(ScrollReflowState * aState, const nsHTMLReflowMetrics & aDesiredSize)  Line 686 + 0x2b bytes	C++
 	xul.dll!nsHTMLScrollFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aDesiredSize, const nsHTMLReflowState & aReflowState, unsigned int & aStatus)  Line 868 + 0x3b bytes	C++
 	xul.dll!nsBlockReflowContext::ReflowBlock(const nsRect & aSpace, int aApplyTopMargin, nsCollapsingMargin & aPrevMargin, int aClearance, int aIsAdjacentWithTop, nsLineBox * aLine, nsHTMLReflowState & aFrameRS, unsigned int & aFrameReflowStatus, nsBlockReflowState & aState)  Line 297 + 0x2d bytes	C++
 	xul.dll!nsBlockFrame::ReflowFloat(nsBlockReflowState & aState, const nsRect & aAdjustedAvailableSpace, nsIFrame * aFloat, nsMargin & aFloatMargin, int aFloatPushedDown, unsigned int & aReflowStatus)  Line 5793 + 0x1f bytes	C++
 	xul.dll!nsBlockReflowState::FlowAndPlaceFloat(nsIFrame * aFloat)  Line 825	C++
 	xul.dll!nsBlockReflowState::AddFloat(nsLineLayout * aLineLayout, nsIFrame * aFloat, int aAvailableWidth)  Line 576 + 0x8 bytes	C++
 	xul.dll!nsLineLayout::ReflowFrame(nsIFrame * aFrame, unsigned int & aReflowStatus, nsHTMLReflowMetrics * aMetrics, int & aPushedFrame)  Line 899	C++
 	xul.dll!nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & aState, nsLineLayout & aLineLayout, nsLineList_iterator aLine, nsIFrame * aFrame, LineReflowStatus * aLineReflowStatus)  Line 3812	C++
 	xul.dll!nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & aState, nsLineLayout & aLineLayout, nsLineList_iterator aLine, nsFlowAreaRect & aFloatAvailableSpace, int & aAvailableSpaceHeight, nsFloatManager::SavedState * aFloatStateBeforeLine, int * aKeepReflowGoing, LineReflowStatus * aLineReflowStatus, int aAllowPullUp)  Line 3607 + 0x17 bytes	C++
 	xul.dll!nsBlockFrame::ReflowInlineFrames(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 3467	C++
 	xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 2566	C++
 	xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState)  Line 1999 + 0x13 bytes	C++
 	xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus)  Line 1081	C++
 	xul.dll!nsLineLayout::ReflowFrame(nsIFrame * aFrame, unsigned int & aReflowStatus, nsHTMLReflowMetrics * aMetrics, int & aPushedFrame)  Line 853 + 0x87 bytes	C++
 	xul.dll!nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & aState, nsLineLayout & aLineLayout, nsLineList_iterator aLine, nsIFrame * aFrame, LineReflowStatus * aLineReflowStatus)  Line 3812	C++
 	xul.dll!nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & aState, nsLineLayout & aLineLayout, nsLineList_iterator aLine, nsFlowAreaRect & aFloatAvailableSpace, int & aAvailableSpaceHeight, nsFloatManager::SavedState * aFloatStateBeforeLine, int * aKeepReflowGoing, LineReflowStatus * aLineReflowStatus, int aAllowPullUp)  Line 3607 + 0x17 bytes	C++
 	xul.dll!nsBlockFrame::ReflowInlineFrames(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 3467	C++
 	xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 2566	C++
 	xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState)  Line 1999 + 0x13 bytes	C++
 	xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus)  Line 1081	C++
 	xul.dll!nsBlockReflowContext::ReflowBlock(const nsRect & aSpace, int aApplyTopMargin, nsCollapsingMargin & aPrevMargin, int aClearance, int aIsAdjacentWithTop, nsLineBox * aLine, nsHTMLReflowState & aFrameRS, unsigned int & aFrameReflowStatus, nsBlockReflowState & aState)  Line 297 + 0x2d bytes	C++
 	xul.dll!nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 3190	C++
 	xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 2507	C++
 	xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState)  Line 1999 + 0x13 bytes	C++
 	xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus)  Line 1081	C++
 	xul.dll!nsBlockReflowContext::ReflowBlock(const nsRect & aSpace, int aApplyTopMargin, nsCollapsingMargin & aPrevMargin, int aClearance, int aIsAdjacentWithTop, nsLineBox * aLine, nsHTMLReflowState & aFrameRS, unsigned int & aFrameReflowStatus, nsBlockReflowState & aState)  Line 297 + 0x2d bytes	C++
 	xul.dll!nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 3190	C++
 	xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 2507	C++
 	xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState)  Line 1999 + 0x13 bytes	C++
 	xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus)  Line 1081	C++
 	xul.dll!nsBlockReflowContext::ReflowBlock(const nsRect & aSpace, int aApplyTopMargin, nsCollapsingMargin & aPrevMargin, int aClearance, int aIsAdjacentWithTop, nsLineBox * aLine, nsHTMLReflowState & aFrameRS, unsigned int & aFrameReflowStatus, nsBlockReflowState & aState)  Line 297 + 0x2d bytes	C++
 	xul.dll!nsBlockFrame::ReflowFloat(nsBlockReflowState & aState, const nsRect & aAdjustedAvailableSpace, nsIFrame * aFloat, nsMargin & aFloatMargin, int aFloatPushedDown, unsigned int & aReflowStatus)  Line 5793 + 0x1f bytes	C++
 	xul.dll!nsBlockReflowState::FlowAndPlaceFloat(nsIFrame * aFloat)  Line 825	C++
 	xul.dll!nsBlockReflowState::AddFloat(nsLineLayout * aLineLayout, nsIFrame * aFloat, int aAvailableWidth)  Line 576 + 0x8 bytes	C++
 	xul.dll!nsLineLayout::ReflowFrame(nsIFrame * aFrame, unsigned int & aReflowStatus, nsHTMLReflowMetrics * aMetrics, int & aPushedFrame)  Line 899	C++
 	xul.dll!nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & aState, nsLineLayout & aLineLayout, nsLineList_iterator aLine, nsIFrame * aFrame, LineReflowStatus * aLineReflowStatus)  Line 3812	C++
 	xul.dll!nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & aState, nsLineLayout & aLineLayout, nsLineList_iterator aLine, nsFlowAreaRect & aFloatAvailableSpace, int & aAvailableSpaceHeight, nsFloatManager::SavedState * aFloatStateBeforeLine, int * aKeepReflowGoing, LineReflowStatus * aLineReflowStatus, int aAllowPullUp)  Line 3607 + 0x17 bytes	C++
 	xul.dll!nsBlockFrame::ReflowInlineFrames(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 3467	C++
 	xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 2566	C++
 	xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState)  Line 1999 + 0x13 bytes	C++
 	xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus)  Line 1081	C++
 	xul.dll!nsBlockReflowContext::ReflowBlock(const nsRect & aSpace, int aApplyTopMargin, nsCollapsingMargin & aPrevMargin, int aClearance, int aIsAdjacentWithTop, nsLineBox * aLine, nsHTMLReflowState & aFrameRS, unsigned int & aFrameReflowStatus, nsBlockReflowState & aState)  Line 297 + 0x2d bytes	C++
 	xul.dll!nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 3190	C++
 	xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 2507	C++
 	xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState)  Line 1999 + 0x13 bytes	C++
 	xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus)  Line 1081	C++
 	xul.dll!nsBlockReflowContext::ReflowBlock(const nsRect & aSpace, int aApplyTopMargin, nsCollapsingMargin & aPrevMargin, int aClearance, int aIsAdjacentWithTop, nsLineBox * aLine, nsHTMLReflowState & aFrameRS, unsigned int & aFrameReflowStatus, nsBlockReflowState & aState)  Line 297 + 0x2d bytes	C++
 	xul.dll!nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 3190	C++
 	xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 2507	C++
 	xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState)  Line 1999 + 0x13 bytes	C++
 	xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus)  Line 1081	C++
 	xul.dll!nsBlockReflowContext::ReflowBlock(const nsRect & aSpace, int aApplyTopMargin, nsCollapsingMargin & aPrevMargin, int aClearance, int aIsAdjacentWithTop, nsLineBox * aLine, nsHTMLReflowState & aFrameRS, unsigned int & aFrameReflowStatus, nsBlockReflowState & aState)  Line 297 + 0x2d bytes	C++
 	xul.dll!nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 3190	C++
 	xul.dll!nsBlockFrame::ReflowLine(nsBlockReflowState & aState, nsLineList_iterator aLine, int * aKeepReflowGoing)  Line 2507	C++
 	xul.dll!nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & aState)  Line 1999 + 0x13 bytes	C++
 	xul.dll!nsBlockFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aMetrics, const nsHTMLReflowState & aReflowState, unsigned int & aStatus)  Line 1081	C++
 	xul.dll!nsContainerFrame::ReflowChild(nsIFrame * aKidFrame, nsPresContext * aPresContext, nsHTMLReflowMetrics & aDesiredSize, const nsHTMLReflowState & aReflowState, int aX, int aY, unsigned int aFlags, unsigned int & aStatus, nsOverflowContinuationTracker * aTracker)  Line 740 + 0x16 bytes	C++
 	xul.dll!nsCanvasFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aDesiredSize, const nsHTMLReflowState & aReflowState, unsigned int & aStatus)  Line 498	C++
 	xul.dll!nsContainerFrame::ReflowChild(nsIFrame * aKidFrame, nsPresContext * aPresContext, nsHTMLReflowMetrics & aDesiredSize, const nsHTMLReflowState & aReflowState, int aX, int aY, unsigned int aFlags, unsigned int & aStatus, nsOverflowContinuationTracker * aTracker)  Line 740 + 0x16 bytes	C++
 	xul.dll!nsHTMLScrollFrame::ReflowScrolledFrame(ScrollReflowState * aState, int aAssumeHScroll, int aAssumeVScroll, nsHTMLReflowMetrics * aMetrics, int aFirstPass)  Line 535 + 0x2b bytes	C++
 	xul.dll!nsHTMLScrollFrame::ReflowContents(ScrollReflowState * aState, const nsHTMLReflowMetrics & aDesiredSize)  Line 686 + 0x2b bytes	C++
 	xul.dll!nsHTMLScrollFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aDesiredSize, const nsHTMLReflowState & aReflowState, unsigned int & aStatus)  Line 868 + 0x3b bytes	C++
 	xul.dll!nsContainerFrame::ReflowChild(nsIFrame * aKidFrame, nsPresContext * aPresContext, nsHTMLReflowMetrics & aDesiredSize, const nsHTMLReflowState & aReflowState, int aX, int aY, unsigned int aFlags, unsigned int & aStatus, nsOverflowContinuationTracker * aTracker)  Line 740 + 0x16 bytes	C++
 	xul.dll!ViewportFrame::Reflow(nsPresContext * aPresContext, nsHTMLReflowMetrics & aDesiredSize, const nsHTMLReflowState & aReflowState, unsigned int & aStatus)  Line 294	C++
 	xul.dll!PresShell::DoReflow(nsIFrame * target, int aInterruptible)  Line 7873	C++
 	xul.dll!PresShell::ProcessReflowCommands(int aInterruptible)  Line 8002 + 0xc bytes	C++
 	xul.dll!PresShell::FlushPendingNotifications(mozFlushType aType)  Line 4901 + 0x11 bytes	C++
 	xul.dll!nsAccessible::GetState(unsigned int * aState, unsigned int * aExtraState)  Line 1534	C++
 	xul.dll!nsAccUtils::State(nsIAccessible * aAcc)  Line 307	C++
 	xul.dll!nsLinkableAccessible::BindToParent(nsAccessible * aParent, unsigned int aIndexInParent)  Line 265 + 0x1a bytes	C++
 	xul.dll!nsAccessible::AppendChild(nsAccessible * aChild)  Line 2778	C++
 	xul.dll!nsAccessible::CacheChildren()  Line 3146 + 0x2c bytes	C++
 	xul.dll!nsAccessible::EnsureChildren()  Line 3194	C++
 	xul.dll!nsDocAccessible::ProcessContentInserted(nsAccessible * aContainer, const nsTArray<nsCOMPtr<nsIContent>,nsTArrayDefaultAllocator> * aInsertedContent)  Line 1773	C++
 	xul.dll!NotificationController::TextEnumerator(NotificationController::nsCOMPtrHashKey<nsIContent> * aEntry, void * aUserArg)  Line 676	C++
 	xul.dll!nsTHashtable<NotificationController::nsCOMPtrHashKey<nsIContent> >::s_EnumStub(PLDHashTable * table, PLDHashEntryHdr * entry, unsigned int number, void * arg)  Line 420 + 0xd bytes	C++
 	xul.dll!PL_DHashTableEnumerate(PLDHashTable * table, PLDHashOperator (PLDHashTable *, PLDHashEntryHdr *, unsigned int, void *)* etor, void * arg)  Line 754 + 0xb bytes	C
 	xul.dll!nsTHashtable<NotificationController::nsCOMPtrHashKey<nsIContent> >::EnumerateEntries(PLDHashOperator (NotificationController::nsCOMPtrHashKey<nsIContent> *, void *)* enumFunc, void * userArg)  Line 241 + 0xf bytes	C++
 	xul.dll!NotificationController::WillRefresh(mozilla::TimeStamp aTime)  Line 250	C++
 	xul.dll!nsRefreshDriver::Notify(nsITimer * __formal)  Line 256	C++
 	xul.dll!nsTimerImpl::Fire()  Line 441	C++
 	xul.dll!nsTimerEvent::Run()  Line 519	C++
 	xul.dll!nsThread::ProcessNextEvent(int mayWait, int * result)  Line 633 + 0xe bytes	C++
 	xul.dll!NS_ProcessNextEvent_P(nsIThread * thread, int mayWait)  Line 250 + 0xd bytes	C++
 	xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate)  Line 110 + 0xa bytes	C++
 	xul.dll!MessageLoop::RunInternal()  Line 219 + 0x9 bytes	C++
 	xul.dll!MessageLoop::RunHandler()  Line 203	C++
 	xul.dll!MessageLoop::Run()  Line 177	C++
 	xul.dll!nsBaseAppShell::Run()  Line 198	C++
 	xul.dll!nsAppShell::Run()  Line 270	C++
 	xul.dll!nsAppStartup::Run()  Line 221	C++
 	xul.dll!XRE_main(int argc, char * * argv, const nsXREAppData * aAppData)  Line 3769	C++
 	firefox.exe!NS_internal_main(int argc, char * * argv)  Line 159	C++
 	firefox.exe!wmain(int argc, wchar_t * * argv)  Line 130	C++
 	firefox.exe!__tmainCRTStartup()  Line 552 + 0x19 bytes	C
 	firefox.exe!wmainCRTStartup()  Line 371	C
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes
I kinda wonder if *anyone* runs a11y in a debug build; it breaks some assertion on pretty much every navigation ....
AHA!  Yes, the stack in comment 46 is showing the hashtable being modified while being enumerated.  The relevant part of that stack:

PresShell::FlushPendingNotifications(mozFlushType aType)  Line
4901 + 0x11 bytes    C++
nsAccessible::GetState(unsigned int * aState, unsigned int *
aExtraState)  Line 1534    C++
nsAccUtils::State(nsIAccessible * aAcc)  Line 307    C++
nsLinkableAccessible::BindToParent(nsAccessible * aParent,
unsigned int aIndexInParent)  Line 265 + 0x1a bytes    C++
nsAccessible::AppendChild(nsAccessible * aChild)  Line 2778    C++
nsAccessible::CacheChildren()  Line 3146 + 0x2c bytes    C++
nsAccessible::EnsureChildren()  Line 3194    C++
nsDocAccessible::ProcessContentInserted(nsAccessible * aContainer,
const nsTArray<nsCOMPtr<nsIContent>,nsTArrayDefaultAllocator> *
aInsertedContent)  Line 1773    C++
NotificationController::TextEnumerator(NotificationController::nsCOMPtrHashKey<nsIContent>
* aEntry, void * aUserArg)  Line 676    C++

You need to stop doing that.  Or copy the hashtable before processing it.
Oh, and to be clear the rest of the stack is just reflow and then we reflow some textframe and it adds to the hashtable, and lossage proceeds.
I can reproduce the stack above by loading www.dailykos.com and switching focus from and back to the browser while the page is loading.
(In reply to comment #49)
> I can reproduce the stack above by loading www.dailykos.com and switching focus
> from and back to the browser while the page is loading.

Well, sort of reproduce.  It normally takes a few tries.  Let me know if I can help test patches for this or provide more information.
(Assignee)

Comment 51

7 years ago
Ok, the fix is we should remove flush layout calls from GetStates (also it makes sense to remove it from GetBounds to be on safe side). It appears we don't need it anymore. Boris, we're allowed to get frame size (and able to get correct result) when refresh driver notifies us, right?
> Boris, we're allowed to get frame size (and able to get
> correct result) when refresh driver notifies us, right?

You're a Display refresh observer, right?  If so, you'll be called after reflow is "done".  Whether you get "correct" results will depend on whether it was interrupted or not....
(Assignee)

Comment 53

7 years ago
(In reply to comment #52)
> > Boris, we're allowed to get frame size (and able to get
> > correct result) when refresh driver notifies us, right?
> 
> You're a Display refresh observer, right?

correct

>  If so, you'll be called after reflow
> is "done".  Whether you get "correct" results will depend on whether it was
> interrupted or not....

if I do layout flush then am I guaranteed it wont be interrupted ana processed sync?
(Assignee)

Comment 54

7 years ago
(In reply to comment #51)
> Ok, the fix is we should remove flush layout calls from GetStates (also it
> makes sense to remove it from GetBounds to be on safe side).

try server build will be here - http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/surkov.alexander@gmail.com-c90e3b156dc4
Anything in particular I should be looking out for? Any particular test scenarios?
I'm running the release build with a screen reader right now, testing different web apps and so far don't see anything wrong.
I'm getting a side by side error trying to run the debug try builds.
You need the 2005 debug CRT (which means you need the compiler installed) to run windows debug builds from try.  Personally I find it easier to just compile my own :-)
Ugh yeah I'm not installing an older compiler. Kyle are you picking up any asserts with the the try build?
Won't be able to test until this evening.

Comment 61

7 years ago
If you can give me a STR, I can test it (I have a debug build with a11y built in).
(In reply to comment #61)
> If you can give me a STR, I can test it (I have a debug build with a11y built
> in).

Comment 49 is the closest we have.
I'm also testing a local debug build FWIW.
> if I do layout flush then am I guaranteed it wont be interrupted

Yes, though you should clearly try to not flush if at all possible, since that will simply make interruptible reflow useless (while still paying the performance penalty for it).
The latest try build removes our only two flush calls. A local debug build that does the same is running pretty clean for me (yeah we still have some assertion noise to clean up but I don't think I'm seeing the bad assertions). Would still be good to hear back from Kyle (later).
David thinks the second part of this bug doesn't need to hard block, at which point it should be split out into its own follow up and this one closed out.
Whiteboard: [sg:critical?][hardblocker][has patch] → [sg:critical?][hardblocker]

Comment 67

7 years ago
I can't reproduce using comment 49.
Follow up to the endgame driver team:

Note the currently attached patches 'part1v2' and 'part2v1' already landed and mostly fixed things for the first incantation of this bug.

Based on low crash numbers (comment 43) I'm not sure if the resurrected version (born via comment 29) of this bug would hardblock, except that Kyle's stack in comment 45 is worries me.

So I'd keep hardblocking status as we need to sort this out but I don't think we absolutely need betaN+ if we're just looking to remove our flush calls.
Whiteboard: [sg:critical?][hardblocker] → [ignore comments 0-29][sg:critical?][hardblocker][has patch]
Alexander, just in case I'm sleeping when you ask for review.

r+ for http://hg.mozilla.org/try/rev/1bc1bc6b55b0
Attachment #508241 - Attachment description: part1v2 → part1v2 (landed 2011-01-30)
Attachment #508352 - Attachment description: part2v1: keep text nodes addrefed → part2v1: keep text nodes addrefed (landed 2011-01-31)

Comment 70

7 years ago
So are we saying this should this be changed to Final+?
I was unable to reproduce the hashtable recursion assertions after 30 minutes of banging on the browser with surkov's patch.
(Assignee)

Comment 72

7 years ago
part3 landed - http://hg.mozilla.org/mozilla-central/rev/6de5f3245650
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
Crash Signature: [@ NotificationController::TextEnumerator(nsPtrHashKey<nsIContent>*, void*) ] [@ nsINode::GetFlags()]
Group: core-security
Crash Signature: [@ NotificationController::TextEnumerator(nsPtrHashKey<nsIContent>*, void*) ] [@ nsINode::GetFlags()] → [@ NotificationController::TextEnumerator(nsPtrHashKey<nsIContent>*, void*) ] [@ nsINode::GetFlags()]
status1.9.2: --- → unaffected
Keywords: testcase-wanted
You need to log in before you can comment on or make changes to this bug.