crash in js::ion::BaselineScript::pcForReturnOffset

VERIFIED FIXED in Firefox 23

Status

()

defect
--
critical
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: scoobidiver, Assigned: djvj)

Tracking

(4 keywords)

23 Branch
mozilla25
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox22 unaffected, firefox23+ fixed, firefox24+ verified, firefox25+ verified, firefox-esr17 unaffected, b2g18 unaffected)

Details

(Whiteboard: [adv-main23-] reqs Firebug or similar, crash signature)

Attachments

(1 attachment)

Reporter

Description

6 years ago
It first showed up in 23.0a1/20130427 but is discontinuous across builds. The regression range might be:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a6104e0e5a2c&tochange=0e45f1b9521f
It's likely a regression from bug 857838 based on the stack trace.

A comment says: "using knockout's ko.toJSON method."

Signature 	js::ion::CompactBufferReader::readByte() More Reports Search
UUID	9896406e-b4fa-4d20-bfe4-d12482130530
Date Processed	2013-05-30 19:15:54
Uptime	200
Last Crash	3.5 minutes before submission
Install Age	4.6 hours since version was first installed.
Install Time	2013-05-30 14:40:34
Product	Firefox
Version	24.0a1
Build ID	20130530031141
Release Channel	nightly
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 30 stepping 5
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x1010e000
App Notes 	
AdapterVendorID: 0x1002, AdapterDeviceID: 0x6899, AdapterSubsysID: 29701682, AdapterDriverVersion: 9.12.0.0
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ 
Processor Notes 	sp-processor02_phx1_mozilla_com_32086:2012
EMCheckCompatibility	False
Adapter Vendor ID	0x1002
Adapter Device ID	0x6899
Total Virtual Memory	4294836224
Available Virtual Memory	3382218752
System Memory Use Percentage	33
Available Page File	6193532928
Available Physical Memory	2862821376

Frame 	Module 	Signature 	Source
0 	mozjs.dll 	js::ion::CompactBufferReader::readByte 	js/src/ion/CompactBuffer.h:57
1 	mozjs.dll 	js::ion::BaselineScript::pcForReturnOffset 	js/src/ion/BaselineJIT.cpp:618
2 	mozjs.dll 	js::ion::BaselineScript::pcForReturnAddress 	js/src/ion/BaselineJIT.cpp:638
3 	mozjs.dll 	js::ion::IonFrameIterator::baselineScriptAndPc 	js/src/ion/IonFrames.cpp:215
4 	mozjs.dll 	js::ion::GetPcScript 	js/src/ion/IonFrames.cpp:1025
5 	mozjs.dll 	MaybeCallMethod 	js/src/jsobj.cpp:4590
6 	mozjs.dll 	js::DefaultValue 	js/src/jsobj.cpp:4618
7 	mozjs.dll 	JSObject::defaultValue 	js/src/jsobjinlines.h:67
8 	mozjs.dll 	js_ReportOverRecursed 	js/src/jscntxt.cpp:520
9 	mozjs.dll 	js_ErrorFromException 	js/src/jsexn.cpp:479
10 	xul.dll 	XPCConvert::JSValToXPCException 	js/xpconnect/src/XPCConvert.cpp:1210
11 	xul.dll 	nsXPCWrappedJSClass::CheckForException 	js/xpconnect/src/XPCWrappedJSClass.cpp:972
12 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/xpconnect/src/XPCWrappedJSClass.cpp:1470
13 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/xpconnect/src/XPCWrappedJS.cpp:573
14 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:85
15 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:112
16 	xul.dll 	jsds_ExecutionHookProc 	js/jsd/jsd_xpc.cpp:634

More reports at:
https://crash-stats.mozilla.com/report/list?signature=js%3A%3Aion%3A%3ACompactBufferReader%3A%3AreadByte%28%29
Reporter

Comment 1

6 years ago
More reports also at:
https://crash-stats.mozilla.com/report/list?signature=js%3A%3Aion%3A%3ACompactBufferReader%3A%3AreadVariableLength%28%29
Crash Signature: [@ js::ion::CompactBufferReader::readByte()] → [@ js::ion::CompactBufferReader::readByte()] [@ js::ion::CompactBufferReader::readVariableLength() ]
Reporter

Comment 2

6 years ago
(In reply to Scoobidiver from comment #0)
> It's likely a regression from bug 857838 based on the stack trace.
Confirmed by its first appearance in 23.0a1/20130423 on Mac

Mac reports at:
https://crash-stats.mozilla.com/report/list?signature=js%3A%3Aion%3A%3ABaselineScript%3A%3ApcForReturnOffset%28JSScript*%2C+unsigned+int%29
Crash Signature: [@ js::ion::CompactBufferReader::readByte()] [@ js::ion::CompactBufferReader::readVariableLength() ] → [@ js::ion::CompactBufferReader::readByte()] [@ js::ion::CompactBufferReader::readVariableLength() ] [@ js::ion::BaselineScript::pcForReturnOffset(JSScript*, unsigned int) ]
OS: Windows 7 → All
Hardware: x86 → All
Summary: crash in js::ion::CompactBufferReader::readByte → crash in js::ion::BaselineScript::pcForReturnOffset
Reporter

Comment 3

6 years ago
It's #3 browser crasher in 23.0b1 and #10 in 24.0a2 on Mac OS X.
Keywords: topcrash
Kannan can you take a look at this? Comment 0 talks about this being a possible regression from bug 857838.
Flags: needinfo?(kvijayan)
Assignee

Comment 5

6 years ago
Taking a look now.
Assignee: general → kvijayan
Flags: needinfo?(kvijayan)
Assignee

Comment 6

6 years ago
I downloaded the relevant release on OSX to try to reproduce this, but no luck.

Then I started looking through the crash reports.  One thing I noticed was that FireBug was heavily present in the crash reports.  In windows crashes, 43 of the first 50 (86%).. and in MacOSX 100% of the crashes checked.. had firebug installed.

I'll try browsing around with firebug installed and see if I can reproduce the issue.
Assignee

Comment 7

6 years ago
I can't replicate this at all.  I need to have something to go on here.

I'm told that I can get access to coredumps as well as URLs corresponding to the crashes.  Can I get those?  I'm blindly browsing now, hoping for a crash, and it's not working.
Status: NEW → UNCONFIRMED
Ever confirmed: false
Flags: needinfo?
Assignee

Comment 8

6 years ago
Jan, do you know where I can get info mentioned in comment 7?
Flags: needinfo? → needinfo?(jdemooij)

Comment 9

6 years ago
Running: Firefox 25.0a1 from mozilla-central 137496:17fe59f6c54a (https://hg.mozilla.org/mozilla-central/rev/17fe59f6c54a) with non-code modifications, built with Clang 3.3 and configure flags:

--enable-application=browser --enable-optimize=-O2 --with-ccache --enable-gstreamer --with-arch=native --enable-official-branding --disable-gio --disable-gconf --disable-accessibility --disable-parental-controls --disable-safe-browsing --enable-debug-symbols --disable-install-strip --enable-clang-plugin --enable-warnings-as-errors

I can reliably reproduce this crash in my application by opening Firebug and calling a function with invalid parameters. Doing the same with the builtin console with Firebug not activated prints "Error".

I have not yet tried to reduce the size of the code base to a usable test case, but it is almost always reproducible.

I have a core dump saved and can reproduce the crash while running under gdb.

Program received signal SIGSEGV, Segmentation fault.
js::ion::BaselineScript::pcForReturnOffset (this=<optimized out>, script=<optimized out>, nativeOffset=206814820) at /home/alex/mozilla-central/js/src/ion/BaselineJIT.cpp:672
warning: Source file is more recent than executable.
672             uint8_t b = reader.readByte();
(gdb) bt
#0  js::ion::BaselineScript::pcForReturnOffset (this=<optimized out>, script=<optimized out>, nativeOffset=206814820) at /home/alex/mozilla-central/js/src/ion/BaselineJIT.cpp:672
#1  0x00007ffff6bbb2f8 in js::ion::IonFrameIterator::baselineScriptAndPc (this=<optimized out>, scriptRes=<optimized out>, pcRes=0x7fffffefe340) at /home/alex/mozilla-central/js/src/ion/IonFrames.cpp:219
#2  0x00007ffff6bbce49 in js::ion::GetPcScript (cx=<optimized out>, scriptRes=0x7fffffefe4f8, pcRes=0x7fffffefe4f0) at /home/alex/mozilla-central/js/src/ion/IonFrames.cpp:1060
#3  0x00007ffff6afa2a1 in currentScript (ppc=<optimized out>, allowCrossCompartment=<optimized out>, this=<optimized out>, this=<optimized out>, ppc=<optimized out>, allowCrossCompartment=<optimized out>) at /home/alex/mozilla-central/js/src/jscntxtinlines.h:554
#4  js_InferFlags (cx=0x7fffea6ca000, defaultFlags=0) at /home/alex/mozilla-central/js/src/jsobj.cpp:1704
#5  0x00007ffff6b00ba3 in CallResolveOp (flags=<optimized out>, recursedp=<optimized out>, flags=<optimized out>, recursedp=<optimized out>, cx=<optimized out>, obj=..., id=..., objp=..., propp=...) at /home/alex/mozilla-central/js/src/jsobj.cpp:3614
#6  LookupPropertyWithFlagsInline<1> (root=0x0, root=0x0, flags=<optimized out>, cx=<optimized out>, cx=<optimized out>, obj=..., id=..., flags=<optimized out>, objp=..., propp=...) at /home/alex/mozilla-central/js/src/jsobj.cpp:3701
#7  GetPropertyHelperInline<1> (getHow=<optimized out>, cx=<optimized out>, obj=..., receiver=..., id=..., getHow=<optimized out>, vp=...) at /home/alex/mozilla-central/js/src/jsobj.cpp:3982
#8  js::baseops::GetProperty (cx=0x7fffc2199200, obj=..., receiver=..., id=..., vp=...) at /home/alex/mozilla-central/js/src/jsobj.cpp:4090
#9  0x00007ffff6b043aa in getGeneric (cx=<optimized out>, obj=..., receiver=..., id=..., vp=...) at /home/alex/mozilla-central/js/src/jsobj.h:870
#10 MaybeCallMethod (cx=<optimized out>, obj=..., id=..., vp=...) at /home/alex/mozilla-central/js/src/jsobj.cpp:4695
#11 0x00007ffff6b03ff5 in js::DefaultValue (cx=0x7fffc2199200, hint=JSTYPE_STRING, obj=..., vp=...) at /home/alex/mozilla-central/js/src/jsobj.cpp:4723
#12 0x00007ffff6b3c3a0 in defaultValue (root=..., dummy=0, hint=<optimized out>, cx=<optimized out>, cx=<optimized out>, obj=..., hint=<optimized out>, vp=...) at /home/alex/mozilla-central/js/src/jsobj.h:1010
#13 ToPrimitive (root=0xfffbffffc77d66a0, preferredType=<optimized out>, cx=<optimized out>, preferredType=<optimized out>, vp=...) at /home/alex/mozilla-central/js/src/jsobjinlines.h:903
#14 js::ToStringSlow<(js::AllowGC)1> (cx=0x7fffc2199200, arg=...) at /home/alex/mozilla-central/js/src/jsstr.cpp:3778
#15 0x00007ffff6a7b160 in ToString<1> (root=..., dummy=0, cx=<optimized out>, v=...) at /home/alex/mozilla-central/js/src/jsstr.h:149
#16 JS_ValueToString (cx=0x7fffea6ca000, valueArg=...) at /home/alex/mozilla-central/js/src/jsapi.cpp:444
#17 0x00007ffff5c7c937 in XPCConvert::JSValToXPCException (ifaceName=0x7fffbf7c2420 "jsdIExecutionHook", methodName=0x7ffff1f862c8 "onExecute", exceptn=0x7fffffefe9b0, sArg=...) at /home/alex/mozilla-central/js/xpconnect/src/XPCConvert.cpp:1164
#18 0x00007ffff5c98b5e in nsXPCWrappedJSClass::CheckForException (ccx=..., aPropertyName=0x7ffff1f862c8 "onExecute", anInterfaceName=0x7fffbf7c2420 "jsdIExecutionHook", aForceReport=true) at /home/alex/mozilla-central/js/xpconnect/src/XPCWrappedJSClass.cpp:971
#19 0x00007ffff5c99fde in nsXPCWrappedJSClass::CallMethod (this=0x7fffbdbfabc0, wrapper=<optimized out>, methodIndex=3, info_=0x7ffff1f862a8, nativeParams=0x7fffffefeda0) at /home/alex/mozilla-central/js/xpconnect/src/XPCWrappedJSClass.cpp:1472
#20 0x00007ffff5c96bea in nsXPCWrappedJS::CallMethod (this=0x7fffe7510c80, methodIndex=3, info=0x7ffff1f862a8, params=0x7fffffefeda0) at /home/alex/mozilla-central/js/xpconnect/src/XPCWrappedJS.cpp:589
#21 0x00007ffff63e0cc2 in PrepareAndDispatch (self=0x7fffbdb9be80, methodIndex=<optimized out>, args=<optimized out>, gpregs=<optimized out>, fpregs=<optimized out>) at /home/alex/mozilla-central/xpcom/reflect/xptcall/src/md/unix/xptcstubs_x86_64_linux.cpp:122
#22 0x00007ffff63e011f in SharedStub () from /usr/local/lib64/firefox-25.0a1/libxul.so
#23 0x00007ffff5e1f28d in jsds_ExecutionHookProc (jsdc=0x7fffbe16a700, jsdthreadstate=<optimized out>, type=4, callerdata=<optimized out>, rval=0x7fffffefefa8) at /home/alex/mozilla-central/js/jsd/jsd_xpc.cpp:637
#24 0x00007ffff5e18513 in jsd_CallExecutionHook (hook=<optimized out>, hookData=<optimized out>, type=<optimized out>, rval=<optimized out>, cx=<optimized out>, hook=<optimized out>, hookData=<optimized out>, cx=<optimized out>, type=<optimized out>, 
    rval=<optimized out>, jsdc=<optimized out>) at /home/alex/mozilla-central/js/jsd/jsd_hook.cpp:146
#25 jsd_ThrowHandler (cx=<optimized out>, script=<optimized out>, pc=<optimized out>, rval=0x7fffffefefa8, closure=0x7fffbe16a700) at /home/alex/mozilla-central/js/jsd/jsd_hook.cpp:117
#26 0x00007ffff6ab2470 in js::DebugExceptionUnwind (cx=0x7fffc2199200, pc=0x7fffebd84ae4 ":", frame=...) at /home/alex/mozilla-central/js/src/jsdbgapi.cpp:148
#27 0x00007ffff6bbb75e in HandleException (frame=..., cx=<optimized out>, calledDebugEpilogue=<optimized out>, rfe=<optimized out>, cx=<optimized out>, frame=..., rfe=<optimized out>, calledDebugEpilogue=<optimized out>)
    at /home/alex/mozilla-central/js/src/ion/IonFrames.cpp:371
#28 js::ion::HandleException (rfe=0x7fffffeff5d0) at /home/alex/mozilla-central/js/src/ion/IonFrames.cpp:515
#29 0x00007ffff341bf4e in ?? ()
#30 0x00007fffc566a0c0 in ?? ()
#31 0x00007fffffeff5d0 in ?? ()
#32 0x00007fffffeff6a8 in ?? ()
#33 0x00007fffffeff650 in ?? ()
#34 0x00007fffffeff6a8 in ?? ()
#35 0x00007fff00000000 in ?? ()
#36 0x00007fffffeff6a8 in ?? ()
#37 0xfff9000000000000 in ?? ()
#38 0x00007ffff7a5feb8 in js::ion::DoGetIntrinsicFallbackInfo () from /usr/local/lib64/firefox-25.0a1/libxul.so
#39 0x00007fffe7b40d30 in ?? ()
#40 0x00007fffe6eb9055 in ?? ()
#41 0x0000000000000901 in ?? ()
#42 0x00007fffffeff660 in ?? ()
#43 0x00007fffe92c5158 in ?? ()
#44 0xfffbffffc77c2400 in ?? ()
#45 0xfffbffffc77c2400 in ?? ()
#46 0xfffbffffc5639ec0 in ?? ()
#47 0xfffbffffc566a0c0 in ?? ()
#48 0xfffaffffc77cc300 in ?? ()
#49 0xfffbffffc77c2400 in ?? ()
#50 0x0000000000000000 in ?? ()
Flags: needinfo?(jdemooij)

Comment 10

6 years ago
Missing from last comment: Firebug 1.11.4

The code is called from the console like `myprogram.modules.run("asdfasdfgarbagehere")`. The exact string does not matter. It looks like this:

myprogram.modules = {
  run: function (str) {
    var data = myprogram.data[str] || str,
        i = 0,
        rundata = function () {
          var dat = data[i++];
          console.log(dat);
          switch (typeof dat) {
            case "string":
              this.run(dat);
          }
        }
  }
}

Thus, calling it goes into infinite recursion, printing "a" all the while.

Interestingly, calling it from the Web Console does not cause a crash, *even if Firebug is open*. If this is done, Firebug prints (using Copy Error):

firebug-service ERROR in ERROR: InternalError: too much recursion chrome://firebug/content/js/debugger.js@2929
resource://firebug/firebug-service.js
Line 4521

Comment 11

6 years ago
More interesting: running it once from Web Console appears to "fix" the issue. Running it again in Firebug after running it from the Web Console does not cause a crash.

Reloading doesn't reset it, but restarting the browser does.
Assignee

Comment 12

6 years ago
Awesome, thanks Alex.  Will look into this on monday.
Assignee

Comment 13

6 years ago
(In reply to Alex Xu from comment #11)
> More interesting: running it once from Web Console appears to "fix" the
> issue. Running it again in Firebug after running it from the Web Console
> does not cause a crash.
> 
> Reloading doesn't reset it, but restarting the browser does.

Alex: Just to confirm, those steps for replicating are for a 64-bit build on a Linux system?

Comment 14

6 years ago
(In reply to Kannan Vijayan [:djvj] from comment #13)
> (In reply to Alex Xu from comment #11)
> > More interesting: running it once from Web Console appears to "fix" the
> > issue. Running it again in Firebug after running it from the Web Console
> > does not cause a crash.
> > 
> > Reloading doesn't reset it, but restarting the browser does.
> 
> Alex: Just to confirm, those steps for replicating are for a 64-bit build on
> a Linux system?

Yes.
Reporter

Updated

6 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee

Comment 15

6 years ago
(In reply to Alex Xu from comment #14)
> (In reply to Kannan Vijayan [:djvj] from comment #13)
> > (In reply to Alex Xu from comment #11)
> > > More interesting: running it once from Web Console appears to "fix" the
> > > issue. Running it again in Firebug after running it from the Web Console
> > > does not cause a crash.
> > > 
> > > Reloading doesn't reset it, but restarting the browser does.
> > 
> > Alex: Just to confirm, those steps for replicating are for a 64-bit build on
> > a Linux system?
> 
> Yes.

Well, I tried building on my Linux system with clang 3.1 as per your specifications and I can't get it to replicate.  3.1 is the latest packaged version I have so I'm building 3.3 from source right now.  In the meantime, is there any way I can get my hands on a core file from one of your crashes?

Comment 16

6 years ago
I have successfully reproduced the crash on Firefox Nightly and have a core dump available. (currently compressing)

Where should I send this to?

Comment 17

6 years ago
Hit submit too fast.

I meant to say: I have successfully reproduced the crash on Firefox Nightly (built from http://hg.mozilla.org/mozilla-central/rev/04d8c309fe72) with a clean profile with only Firebug installed. I have a core dump available, which is currently being uploaded to my host. (only 19M after xz)

Where can I send it off to? (still would prefer not to have it open to the world)
Assignee

Comment 18

6 years ago
Send it to me.  My e-mail address should be visible to you.
Assignee

Comment 19

6 years ago
(In reply to Alex Xu from comment #17)
> Where can I send it off to? (still would prefer not to have it open to the
> world)

Any luck on the upload?  I'm reasonably sure this bug is related to a bad return address being written out.  Jan pointed out BaselineFrame::initForOsr a a potential culprit.

I want to take a look at what the return address looks like in this code, and where it's mapping to, and how it compares to the ICEntry table.

My clang3.3 build is going poorly - llvm 3.3 and clang build fine, but they're throwing assertions when I try to compile firefox with them.. not sure what's going on.

Comment 20

6 years ago
Sent it to you a few hours ago; maybe it got caught in spam box. Trying again from my personal domain.
Locking s-s per djvj's request on IRC.
Group: core-security
Assignee

Comment 22

6 years ago
Alex: Thanks a bunch for all the help in with reproducing this issue.  I was able to replicate it here, then get it replicating on a debug build, which led quite quickly to the problem.


Here's the issue:
When unwinding frames during exceptions, we update ionTop to point successively to the frame above the one we have just handled.

This can make it so that ionTop points to a Rectifier (or potentially Unwound_Rectifier) frame.

However, ion::GetPcScript doesn't handle the case where ionTop is at a rectifier frame.  It assumes that ionTop will always be either a Baseline, BaselineStub, or OptimizedJS frame (or Unwound variants thereof).  It tries reading doing script/pc retreival on the rectifier frame, thinking it's a baseline frame, and crashes.

This code path is invoked in particular by exception handling in debug mode, which seems to traverse the stack for some reason.
Attachment #773631 - Flags: review?(jdemooij)
Comment on attachment 773631 [details] [diff] [review]
Handle rectifier frames in GetPcScript

Review of attachment 773631 [details] [diff] [review]:
-----------------------------------------------------------------

Ugh, good find!
Attachment #773631 - Flags: review?(jdemooij) → review+
Assignee

Comment 24

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/cad670b92cfe

Alex:  Thanks again for the invaluable help!
https://hg.mozilla.org/mozilla-central/rev/cad670b92cfe

Possible to write a test for this?
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
Assignee

Comment 26

6 years ago
Comment on attachment 773631 [details] [diff] [review]
Handle rectifier frames in GetPcScript

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
Bug 810824.

User impact if declined:
Potentially exploitable crash in debug mode (e.g. w/ firebug)

Testing completed (on m-c, etc.):
Green on m-i for two days.

Risk to taking this patch (and alternatives if risky):
Very low.  Handles a case that will otherwise always crash if encountered (or silently generate incorrect behaviour).
 
String or IDL/UUID changes made by this patch:
None.
Attachment #773631 - Flags: approval-mozilla-beta?
Attachment #773631 - Flags: approval-mozilla-aurora?
Attachment #773631 - Flags: approval-mozilla-beta?
Attachment #773631 - Flags: approval-mozilla-beta+
Attachment #773631 - Flags: approval-mozilla-aurora?
Attachment #773631 - Flags: approval-mozilla-aurora+
Assignee

Comment 28

6 years ago
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #25)
> https://hg.mozilla.org/mozilla-central/rev/cad670b92cfe
> 
> Possible to write a test for this?

I'll look into writing a test for this, but it might not be easy.  I will add it to my list of tests-needed bugs to look at.
Whiteboard: [adv-main23-]
Assignee

Comment 29

6 years ago
A few weeks ago I tried for quite a while to write up a test case that revealed this error, and wasn't successful.  It's a pretty subtle set of interactions that lead to this, and they're proving very hard to replicate.

I'm removing the testsuite flag for this bug as I don't expect to be able to write a test case that triggers the issue this patch fixes.
Flags: in-testsuite?
Calling this verified fixed since I don't see any instances of the signatures in this bug for Firefox 24 or 25 in the last week.
Status: RESOLVED → VERIFIED
Blocks: 810824
Group: core-security
Keywords: sec-moderate
Whiteboard: [adv-main23-] → [adv-main23-] reqs Firebug or similar
You need to log in before you can comment on or make changes to this bug.