203041 - [FIX] M17rc2 - Removing nodes with line wraps can cause immediate crash of Mozilla - Trunk [@ 0x00000000 - nsCSSFrameConstructor::FindFrameWithContent ][@ nsCSSFrameConstructor::FindFrameWithContent ] (crash on file input)

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Kelley Reynolds]

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4a) Gecko/20030418
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4a) Gecko/20030418

Click on 'attach files' to add nodes, then click on 'delete' to remove nodes.
This works as long as 'delete' doesn't wrap around to the next line. If one
makes the browser window small enough so that the 'delete' word wraps around
underneath the 'file' form element, it will crash Mozilla 1.3 and 1.4a on
windows, freebsd, and linux.

Reproducible: Always

Steps to Reproduce:
1.Click on attach file.
2.Resize the window so that delete is underneath the file element
3.click on delete

Actual Results:  
Mozilla crashed entirely.

Expected Results:  
Mozilla should not have disappeared. It should have behaved the same as when
delete was at the end of the line.

1.2.1 on Windows doesn't appear to have this problem.

Comment 1

[Boris Zbarsky [:bzbarsky]]

###!!! ASSERTION: frame was not removed from primary frame map before
destruction or was readded to map after being removed:
'!PL_DHASH_ENTRY_IS_BUSY(entry) || entry->frame != aFrame', file
/home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsFrameManager.cpp,
line 1050

Stack is:

#0  0xdddddddd in ?? ()
#1  0x40ee6849 in nsCSSFrameConstructor::FindPrimaryFrameFor (this=0x8506a80, 
    aPresContext=0x87cfce0, aFrameManager=0x8524930, aContent=0x8791520, 
    aFrame=0xbfffce64, aHint=0x0)
    at
/home/bzbarsky/mozilla/xlib/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp:11822
#2  0x40ff4d9d in StyleSetImpl::FindPrimaryFrameFor (this=0x86dc548, 
    aPresContext=0x87cfce0, aFrameManager=0x8524930, aContent=0x8791520, 
    aFrame=0xbfffce64, aHint=0x0)
    at /home/bzbarsky/mozilla/xlib/mozilla/content/base/src/nsStyleSet.cpp:1825
#3  0x40e33328 in FrameManager::GetPrimaryFrameFor (this=0x8524930,
aContent=0x8791520, 
    aResult=0xbfffce64)
    at
/home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsFrameManager.cpp:681
#4  0x40e7cc13 in PresShell::GetPrimaryFrameFor (this=0x8506b70,
aContent=0x8791520, 
    aResult=0xbfffce64)
    at /home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsPresShell.cpp:5704
#5  0x41037c05 in nsGenericHTMLElement::GetPrimaryFrameFor (aContent=0x8791520, 
    aDocument=0x8579328, aFlushContent=0)
    at
/home/bzbarsky/mozilla/xlib/mozilla/content/html/content/src/nsGenericHTMLElement.cpp:2619
#6  0x41037c3d in nsGenericHTMLElement::GetFormControlFrameFor (aContent=0x8791520, 
    aDocument=0x8579328, aFlushContent=0)
    at
/home/bzbarsky/mozilla/xlib/mozilla/content/html/content/src/nsGenericHTMLElement.cpp:2632
#7  0x4103d95d in nsGenericHTMLElement::GetFormControlFrame (this=0x8791520, 
    aFlushContent=0)
    at
/home/bzbarsky/mozilla/xlib/mozilla/content/html/content/src/nsGenericHTMLElement.h:254
#8  0x4106170d in nsHTMLInputElement::GetValue (this=0x8791520, aValue=@0xbfffcf90)
    at
/home/bzbarsky/mozilla/xlib/mozilla/content/html/content/src/nsHTMLInputElement.cpp:657
#9  0x41065df0 in nsHTMLInputElement::SaveState (this=0x8791520)
    at
/home/bzbarsky/mozilla/xlib/mozilla/content/html/content/src/nsHTMLInputElement.cpp:2493

-- this is the request for a primary frame we always get as a form control is
being removed from the doc... In particular, this tends to repopulate the
primary frame map with the about-to-be-destroyed frame...

Comment 2

[Jay Patel [:jay]]

Here's a recent Talkback incident:
Incident ID 19440535
Stack Signature 	0x00000000 33c05baf
Email Address 	[e-mail]
Product ID 	MozillaTrunk
Build ID 	2003042308
Trigger Time 	2003-04-23 15:14:07
Platform 	Win32
Operating System 	Windows NT 5.0 build 2195
Module 	
URL visited 	
User Comments 	B#203041
Trigger Reason 	Access violation
Source File Name 	
Trigger Line No. 	
Stack Trace 	
0x00000000
nsCSSFrameConstructor::FindFrameWithContent
[c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 11670]
nsCSSFrameConstructor::FindPrimaryFrameFor
[c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 11847]
StyleSetImpl::FindPrimaryFrameFor
[c:/builds/seamonkey/mozilla/content/base/src/nsStyleSet.cpp, line 1826]
FrameManager::GetPrimaryFrameFor
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsFrameManager.cpp, line 683]
PresShell::GetPrimaryFrameFor
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 5705]
nsGenericHTMLElement::GetPrimaryFrameFor
[c:/builds/seamonkey/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 2630]
nsGenericHTMLElement::GetFormControlFrameFor
[c:/builds/seamonkey/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 2643]
nsHTMLInputElement::GetValue
[c:/builds/seamonkey/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 659]
nsHTMLInputElement::SaveState
[c:/builds/seamonkey/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 2497]
nsGenericHTMLLeafFormElement::SetDocument
[c:/builds/seamonkey/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 4278]
nsHTMLInputElement::SetDocument
[c:/builds/seamonkey/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 1781]
nsGenericElement::SetDocumentInChildrenOf
[c:/builds/seamonkey/mozilla/content/base/src/nsGenericElement.cpp, line 1640]
nsGenericElement::SetDocument
[c:/builds/seamonkey/mozilla/content/base/src/nsGenericElement.cpp, line 1704]
nsGenericHTMLElement::SetDocument
[c:/builds/seamonkey/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 1340]
nsGenericHTMLContainerElement::RemoveChildAt
[c:/builds/seamonkey/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 3814]
nsGenericElement::doRemoveChild
[c:/builds/seamonkey/mozilla/content/base/src/nsGenericElement.cpp, line 2892]
nsHTMLTableCellElement::RemoveChild
[c:/builds/seamonkey/mozilla/content/html/content/src/nsHTMLTableCellElement.cpp,
line 63]
XPTC_InvokeByIndex
[c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2025]
XPC_WN_CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1285]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 845]
js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2836]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 861]
js_InternalInvoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 936]
JS_CallFunctionValue [c:/builds/seamonkey/mozilla/js/src/jsapi.c, line 3529]
nsJSContext::CallEventHandler
[c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1082]
nsJSEventListener::HandleEvent
[c:/builds/seamonkey/mozilla/dom/src/events/nsJSEventListener.cpp, line 183]
nsEventListenerManager::HandleEventSubType
[c:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp, line
1192]
nsEventListenerManager::HandleEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp, line
1363]
nsGenericElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/base/src/nsGenericElement.cpp, line 1925]
nsGenericHTMLElement::HandleDOMEventForAnchors
[c:/builds/seamonkey/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 1433]
nsHTMLLinkElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/html/content/src/nsHTMLLinkElement.cpp,
line 360]
PresShell::HandleEventInternal
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6377]
PresShell::HandleEventWithTarget
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6338]
nsEventStateManager::CheckForAndDispatchClick
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 2911]
nsEventStateManager::PostHandleEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 1906]
PresShell::HandleEventInternal
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6414]
PresShell::HandleEvent
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6321]
nsViewManager::HandleEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2292]
nsView::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 308]
nsViewManager::DispatchEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2028]
HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 82]
nsWindow::DispatchEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1057]
nsWindow::DispatchWindowEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1074]
nsWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5177]
ChildWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5432]
nsWindow::ProcessMessage
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 4021]
nsWindow::WindowProc
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1337]
USER32.dll + 0x2a244 (0x77e3a244)
USER32.dll + 0x45e5 (0x77e145e5)
USER32.dll + 0xa792 (0x77e1a792)
nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 479]
main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1284]
main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1650]
WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1672]
WinMainCRTStartup()
KERNEL32.dll + 0x2847c (0x77ea847c) 

Comment 3

[Matthias Versen [:Matti]]

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

Comment 4

[Matthias Versen [:Matti]]

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

Comment 5

[kurros (Wade Majors)]

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

Comment 6

[Mats Palmgren (inactive)]

This is a regression from bug 152844 (credits to Andrew Schultz bug 207775).

+nsFileControlFrame::Destroy(nsIPresContext* aPresContext)
+{
+  // Toss the value into the control from the anonymous content, which is about
+  // to get lost.
+  if (mTextContent) {
+    nsCOMPtr<nsIDOMHTMLInputElement> input = do_QueryInterface(mTextContent);
+    nsAutoString value;
+    input->GetValue(value);
+
+    // Have it take the value, just like when input type=text goes away
+    nsCOMPtr<nsITextControlElement> fileInput = do_QueryInterface(mContent);
+    fileInput->TakeTextFrameValue(value);
+  }
+  return nsAreaFrame::Destroy(aPresContext);
 }


If I remove "input->GetValue(value);" it does not crash.
The crash is not on that line per se, it comes later, but this line seems to
be the culprit.

Comment 7

[Mats Palmgren (inactive)]

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

Comment 8

[Mats Palmgren (inactive)]

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

Comment 9

[Boris Zbarsky [:bzbarsky]]

This comes up every so often...  Basically, as I recall it, the GetValue calls
GetPrimaryFrameFor, which puts a pointer to the form control frame back into the
primary frame map (this code is running _after_ the frame has been removed from
the map).  Then the frame gets destroyed, and there is a stale pointer living in
the primary frame map.

Could you try manually removing the frame from the primary frame map after that
GetValue() call and seeing whether that helps the crash?

Comment 10

[Mats Palmgren (inactive)]

That fixed one of the bugs while others still crashed.
Instead, I found some code in nsTextControlFrame which does something similar
and that fixed all the bugs. I will attach the patch after I clean it up a bit.

Comment 11

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

Comment 12

[Mats Palmgren (inactive)]

Don't know who I should ask for review - Boris?

Comment 13

[John Keiser (jkeiser)]

Comment on attachment 125139 [details] [diff] [review]
Patch rev. 1

That would be me.  What is the actual root cause here?	Is PreDestroy() not
being called on the anonymous contents' frames?

Comment 14

[Mats Palmgren (inactive)]

There was no nsFileControlFrame::PreDestroy() - the patch adds it in the same way
as in nsTextControlFrame.  I think Boris' comment 9 explains the situation.

Comment 15

[John Keiser (jkeiser)]

What I'm trying to figure out is, why is it calling GetPrimaryFrameFor() at all?
 Since nsTextControlFrame has a PreDestroy, *that* should have been called,
which would have given the value to the input type=file, which would have set
mOwnsValue = PR_TRUE.  I'll debug here.  I just think there is a deeper problem
with the order we destroy things.

Comment 16

[Olivier Cahagne]

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

Comment 17

[Andrew Schultz]

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

Comment 18

[Andrew Schultz]

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

Comment 19

[Mats Palmgren (inactive)]

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

Comment 20

[Boris Zbarsky [:bzbarsky]]

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

Comment 21

[Boris Zbarsky [:bzbarsky]]

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

Comment 22

[WD]

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

Comment 23

[Mats Palmgren (inactive)]

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

Comment 24

[Boris Zbarsky [:bzbarsky]]

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

Comment 25

[Isaac Hwak Han]

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

Comment 26

[José Jeria]

URL is dead, updating with minimized testcase.

Comment 27

[David Baron :dbaron:]

Perhaps we should just move removal from the primary frame map later (to where
we currently have the assertion)?  Or is there a problem that still having the
frame in the primary frame map that late would cause?

Comment 28

[Isaac Hwak Han]

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

Comment 29

[Charles Fenwick]

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

Comment 30

[Charles Fenwick]

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

Comment 31

[Olivier Cahagne]

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

Comment 32

[PikeUK]

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

Comment 33

[Tuukka Tolvanen (sp3000)]

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

Comment 34

[Ben Fowler]

Attachment: backtrace

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040412
Firefox/0.8.0+

This crash is still in.

Comment 35

[Jay Patel [:jay]]

Adding M17beta to summary and topcrash keyword for tracking since this is a
topcrasher for Mozilla 1.7 Beta.

Comment 36

[Jay Patel [:jay]]

I just crashed with the testcase
(http://bugzilla.mozilla.org/attachment.cgi?id=139119&action=view) using Mozilla
1.7 RC1 on WinXP. 

Updated summary for tracking: M17beta -> M17rc1

Comment 37

[Asa Dotzler [:asa]]

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

Comment 38

[Asa Dotzler [:asa]]

Attachment: click "OK" in the alert to trigger the crash

moving testcase over from dupe bug 242620

Comment 39

[Rodd Clarkson]

Actually, the alert is just a 'pause' immediately before the crash.  Removed the
alert from the test case and the browser will just crash.

Comment 40

[chris hofmann]

anyone have any more thoughts on how to fix this?

Comment 41

[OstGote!]

I guess my crashs with recent trunk builds (not 1.7) are the same issue. See
TB40744Q, TB40732E and more. But I never noticed it before, I wonder in spite of
my heavy use. I only crash in Mail & News if I *drag* the vertical scrollbar
(not if I click the up/down arrows) of the recipients list in a message window.
Now this crash is the No. 1 topcrash of the trunk builds.

Comment 42

[Andreas Kunz]

The attached patch might be bitrotted, but maybe still contains the solution or
hints towards it.
Please note that jkeiser is unlikely to do the review, so maybe someone else
should be contacted...

Comment 43

[OstGote!]

(In reply to comment #41)
> I only crash in Mail & News if I *drag* the vertical scrollbar
> (not if I click the up/down arrows) of the recipients list in a message window.
see bug 243189 comment 4: ... or If I use the keyboard to navigate through the
whole list (down/up).

Comment 44

[Jay Patel [:jay]]

Reassigning to default owners (which right now is [e-mail]).

Asa:  Any idea who might be able to look at this?

Comment 45

[Boris Zbarsky [:bzbarsky]]

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

Comment 46

[Brendan Eich [:brendan]]

dbaron, bz: either of you able to take this bug?

/be

Comment 47

[OstGote!]

(In reply to comment #43)
These crashes are gone with the fix for bug 243203 for me (although I always had
the stack signature nsCSSFrameConstructor::FindFrameWithContent). The testcase
here still crashes. Sorry for the unnecessary spam.

Comment 48

[Jay Patel [:jay]]

Updating summary with M17rc2 since this testcase crashes for me too with Mozilla
1.7 rc2:

Incident ID: 52751
Stack Signature	0x00000000 75613caa
Email Address	[e-mail]
Product ID	Mozilla17
Build ID	2004051408
Trigger Time	2004-05-19 14:47:49.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	
URL visited	http://bugzilla.mozilla.org/attachment.cgi?id=139119&action=view
User Comments	Bug 203041
Since Last Crash	sec
Total Uptime	sec
Trigger Reason	Access violation
Source File Name	
Trigger Line No.	
Stack Trace 	
0x00000000
GetNifOrSpecialSibling
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 400]
nsCSSFrameConstructor::FindFrameWithContent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 11022]
nsCSSFrameConstructor::FindPrimaryFrameFor
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 11088]
nsFrameManager::GetPrimaryFrameFor
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsFrameManager.cpp,
line 460]
PresShell::GetPrimaryFrameFor
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5389]
nsGenericHTMLElement::GetPrimaryFrameFor
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 2189]
nsGenericHTMLElement::GetFormControlFrameFor
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 2199]
nsHTMLButtonElement::HandleDOMEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsHTMLButtonElement.cpp,
line 375]
.
.
.

The stack looks a lot like bug 238906, but still not sure if they're dups.

Comment 49

[Brian Ryner (not reading)]

Attachment: patch updated to trunk

Comment 50

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 148920 [details] [diff] [review]
patch updated to trunk

r+sr=bzbarsky.	The answer to comment 15 is that the textnode gets the frame
_unconditionally_ during the GetValue call, since the frame is what knows
whether it owns the value.  So we end up calling GetPrimaryFrameFor after the
frames have been removed from the primary frame map (that happens before we
start destroying them).

So this is exactly the right patch....

Comment 51

[chris hofmann]

Comment on attachment 148920 [details] [diff] [review]
patch updated to trunk

a=chofmann for 1.7

Comment 52

[Brian Ryner (not reading)]

checked into trunk, 1.7 branch, and aviary branch.

Comment 53

[Olivier Cahagne]

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

Comment 54

[timeless]

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

Comment 55

[Stephen Donner [:stephend] Not actively reading bugmail]

I've verified that all testcases in this bug no longer crash for me using build
2004-11-12-04 on Windows XP, Seamonkey trunk.

Comment 56

[Ryuichi KUBUKI]

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

Comment 57

[Jesse Ruderman]

Crashtest added as part of http://hg.mozilla.org/mozilla-central/rev/afc662d52ab1