424982 - Code running in context of hiddenDOMWindow runs unprivileged?

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Manuel Reimer]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008032505 SeaMonkey/2.0a1pre
Build Identifier: 

If I run code in context of hiddenDOMWindow using subscript loader, then I'm not longer able to get access to Components.classes in latest nightlies. I get the error message:

Error: Permission denied to get property XPCComponents.classes
Source File: chrome://prefbar/content/prefbar.js
Line: 213

Reproducible: Always

Comment 1

[Mike Shaver (:shaver emeritus)]

Does your extension use xpcnative wrappers?  Is that source location from the sourced file, or the sourcing file?

Do you see this in Firefox, or SeaMonkey?

Test case would help a big ton muchly.

Comment 2

[Manuel Reimer]

As possible testcase, just get PrefBar 4.1 Beta from http://prefbar.mozdev.org/

I don't use "xpcnative wrappers" and I don't want to use them. The file, I inject to hiddenDOMWindow has to be run privileged!

I see this in SeaMonkey, but others told me, that they have the same problem with Firefox 3.0 nightlies.

Comment 3

[Manuel Reimer]

Download URL:

http://prefbar.mozdev.org/installation.html/prefbar4.1beta.xpi

Hope this helps, as creating a good testcase would be nearly as much work as creating a whole new extension, in the Mozilla world...

Comment 4

[Mike Shaver (:shaver emeritus)]

The whole point of XPCNativeWrappers is to be used by privileged code, so that their privileges aren't abused by content!  If you enable them, do you get the same error?  Running "in the context of the window" is different here from just overlaying a script into it, I presume?  Can you paste some relevant code, if there's no standalone testcase?

(Installing that extension triggers the error?  No action necessary?)

Comment 5

[Manuel Reimer]

Yes, just install and you'll see the error and you'll have an empty new toolbar, as PrefBar can't place the global PrefBar "service".

I'll search the relevant code parts and post links to my CVS web view. Please wait some minutes.

Comment 6

[Manuel Reimer]

Anything starts with "prefbar-loader.js". Goal of this script file is to load the file "prefbar.js" to "hiddenDOMWindow.goPrefBar" if not already there. As soon as the file is loaded to this global context, a pointer to it is left in the *current* context as "goPrefBar" to allow access from this context (like browser window or preferences window).

This is the code which loads the file "prefbar.js" to global context
http://www.mozdev.org/source/browse/prefbar/source/prefbar/content/prefbar/prefbar-loader.js?f=h;content-type=text%2Fx-cvsweb-markup;ln=1;rev=1.4#l42
"prefbar-loader2.js" is just for creating the "goPrefBar" onto "hiddenDOMWindow" as it's not longer able to run this one line via data:-URL... :-(
If prefbar.js got loaded to global context, then "Init" in this file is called:
http://www.mozdev.org/source/browse/prefbar/source/prefbar/content/prefbar/prefbar.js?f=h;content-type=text%2Fx-cvsweb-markup;ln=1;rev=1.26#l57
And this calls the browser detection first:
http://www.mozdev.org/source/browse/prefbar/source/prefbar/content/prefbar/prefbar.js?f=h;content-type=text%2Fx-cvsweb-markup;ln=1;rev=1.26#l211
Which now fails in current nightlies (above error message).

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

I apologize in advance for adding nothing constructive about the bug in question, but you should not be using prefbar-loader.js or prefbar-loader2.js or hiddenWindow to create a singleton.

The cleaner method of doing this is to create a JavaScript XPCOM component encapsulating prefbar.js functionality. Then the extension code can use "getService" to get access to the one-and-only goPrefBar.

See this for more information:
http://developer.mozilla.org/en/docs/Working_with_windows_in_chrome_code#Advanced_data_sharing and stop into #extdev on mozilla IRC for help, if needed.

Comment 8

[Manuel Reimer]

Doesn't work in SeaMonkey 1.x, which is still my primary target as long as it is still supported by the SeaMonkey team.

Of course this would be a good solution for the future, but not for the near future. Could someone please have a look at the hiddenDOMWindow code? I checked out some CVS logs but couldn't find a change in the last few days that could have caused this bug...

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

Can you find a regression range? When did it stop working?

Comment 10

[Manuel Reimer]

I'm sure it still worked Wednesday last week. I don't have an exact date where it stopped working.

Comment 11

[Manuel Reimer]

Maybe it's really XPCNativeWrappers which runs wild here? Access from chrome:// to res:// which causes unprivileged access?

Comment 12

[Mark Finkle (:mfinkle) (use needinfo?)]

If I had to guess, I would not be blaming hiddenWindow. I would look at the changes to mozIJSSubScriptLoader instead:
http://starkravingfinkle.org/blog/2008/03/extension-developers-breaking-news-part-2/

Comment 13

[Manuel Reimer]

My URLs are both chrome://-URLs. Even the "one liner" which just does a "var goPrefBar = new Object;" is a new file in chrome:// context, so this doesn't seem to be the reason why I'm unable to access "Components.classes".

The change to "chrome URLs only" was the reason why I create prefbar-loader2.js and I'm sure it worked with this change. It got broken at a later date again, but I did the first try, where it worked, from windows. The tries, where it fails, where done on Linux. I don't know if this makes any difference.

Comment 14

[Manuel Reimer]

It seems like I'm losing the "privileged status" in later stage. The line
http://www.mozdev.org/source/browse/prefbar/source/prefbar/content/prefbar/prefbar.js?f=h;content-type=text%2Fx-cvsweb-markup;ln=1;rev=1.26#l44
runs well without any error, but line
http://www.mozdev.org/source/browse/prefbar/source/prefbar/content/prefbar/prefbar.js?f=h;content-type=text%2Fx-cvsweb-markup;ln=1;rev=1.26#l213
fails.
If I comment out the block from line 213 to line 217 in this file, then I fail on line
http://www.mozdev.org/source/browse/prefbar/source/prefbar/content/prefbar/prefbar.js?f=h;content-type=text%2Fx-cvsweb-markup;ln=1;rev=1.26#l221
again. Not much different to the first lines (44 and following). The only difference is, that the failing code is inside a subfunction. Even if I move the call to "Init" in prefbar.js from prefbar-loader.js line 60:
http://www.mozdev.org/source/browse/prefbar/source/prefbar/content/prefbar/prefbar-loader.js?f=h;content-type=text%2Fx-cvsweb-markup;ln=1;rev=1.4#l60
to the end of prefbar.js to get it called from the same context where I also define the functions, doesn't change anything.

Comment 15

[Manuel Reimer]

Attachment: minimal testcase

This is a minimal testcase. Just extract to your extensions/ directory in SeaMonkey 2.0 or Firefox 3.0 (didn't test with Firefox but should work).

The problem is definetly, that code, running directly from the "global.js" in this testcase, runs privileged and as soon as I define a function there and call it, my code inside this function runs unprivileged.

Comment 16

[Boris Zbarsky [:bzbarsky]]

So...  The hidden window has resource://gre/res/hiddenWindow.html loaded in it on Windows/Linux and chrome://browser/content/hiddenWindow.xul loaded in it on Mac.  The former URI is not pointing to privileged code, so the hidden window doesn't have the system principal there.  So the behavior will be OS-dependent, but should be the same on Linux and Windows.  Arguably, the OS-dependence here is a bug.  I'm not sure which way we want to go (privileged on all OSes, or unprivileged on all OSes).

Given the above, if you loadSubscript with the hidden window as the global, the functions end up with the hidden window on the parent chain, so nsScriptSecurityManager::GetFunctionObjectPrincipal will return the hidden window's principal for the functions.  See the "// Since principals follow scope" comment in that method.  On Linux and Windows this means the code is treated as unprivileged.

None of this should have changed as a result of the XPCNativeWrapper automation change we made to the scriptLoader, imo.  If it did, that seriously worries me.  Can someone confirm that the testcase in comment 15 used to work but now doesn't?  If so, what's the regression range, to the day?

Confirming and nominating so we make sure to investigate; changes to security behavior that weren't intended are worrisome.  We need to understand why the behavior changed and whether we want it to change.

Comment 17

[Ria Klaassen (not reading all bugmail)]

Regression window is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1206265620&maxdate=1206271439

Comment 18

[Johnny Stenback (:jst)]

Igor, the regression range here points at your fix for bug 424376, care to have a look?

Comment 19

[Boris Zbarsky [:bzbarsky]]

Ah, looks like the code flow I describe in comment 17 is in fact new as of bug 424376.  Before that, any time we had a non-cloned scripted function we used the principals compiled into the function (or rather its script).

Comment 20

[Igor Bukanov]

(In reply to comment #19)
> Ah, looks like the code flow I describe in comment 17 is in fact new as of bug
> 424376.  Before that, any time we had a non-cloned scripted function we used
> the principals compiled into the function (or rather its script).

The question is how one one gets non-cloned function. Before landing the bug  	424376 this could happen through calling JS_GetFunctionObject on a scripted function. Among all calls to the API that lxr.mozilla.org reports AFAICS only http://lxr.mozilla.org/seamonkey/source/js/jsd/jsd_xpc.cpp#1242 can call JS_GetFunctionObject on a scripted function.

So the big question for me is why prior bug 424376 this worked.
 


http://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/src/XPCIDispatchExtension.cpp#219 

Comment 21

[Boris Zbarsky [:bzbarsky]]

> this could happen through calling JS_GetFunctionObject on a scripted
> function.

Don't JS_Compile*Function and JS_ExecuteScript give you non-cloned function objects?

Comment 22

[Igor Bukanov]

(In reply to comment #21)
> > this could happen through calling JS_GetFunctionObject on a scripted
> > function.
> 
> Don't JS_Compile*Function and JS_ExecuteScript give you non-cloned function
> objects?

Right, this is the issue. The top-level functions evaluated by JS_Evaluate*ScriptForPrincipals and functions returned  JS_Compile*FunctionForPrincipals will be uncloned. 

Before the bug 424376 landed, it was possible to detect such uncloned functions using a particular JS API  pattern. When they were detected, the security manager trusted the principals stored in the functions ignoring function's parent chain. So one way to fix the bug is to allow for the security manager to check for uncloned functions again.

But this raises the question whether testing for clones is the right approach. Consider the following js code:

access_privileged_functionality_1;
outer();

function outer()
{
    access_privileged_functionality_2;
    inner();
    
    function inner()
    {
        access_privileged_functionality_3;
    }
}

Even before the bug 424376 has landed, access_privileged_functionality_3 would through a security exception as inner will always be a cloned function. 

So the question is why nsScriptSecurityManager::CheckFunctionAccess cannot trust the principals stored in the function itself and have to use parent's chain. I.e. why the following comments from http://lxr.mozilla.org/seamonkey/source/caps/src/nsScriptSecurityManager.cpp#2146 say that principals stored in JSScript referenced by a cloned function are unreliable: 

// Since principals follow scope, we must get the object
// principal from the function's scope chain. There are no
// reliable principals compiled into the function itself.

This comments comes from bug 201132 which have started to use parent's chain principals, not function principals:

+        if (JS_GetFunctionObject(fun) != obj)
+        {
+            // Function is a clone, its prototype was precompiled from
+            // brutally shared chrome. For this case only, get the
+            // principals from the object's scope since there's no
+            // reliable principals compiled into the function.
+            return doGetObjectPrincipal(cx, obj, result);
+        }

This tells me that another way to fix the bug is to detect "brutally shared chrome" and call doGetObjectPrincipal only in that case. Would this "brutally shared chrome" have null as a principal embedded into its script?

Comment 23

[Boris Zbarsky [:bzbarsky]]

No, it would not.  It would typically have the system principal.  This could be changed, of course.  Perhaps it should be.

I agree that we don't so much want to "detect cloned functions" as we want to "detect functions that got explicitly cloned by us using JS_CloneFunctionObject and stuck into a security context different from the compilation context".

brendan?  Thoughts?

By the way, I hope we'll end up with some regression tests for this bug (including the inner function example).

Comment 24

[Brendan Eich [:brendan]]

Once upon a time there were no closures, no pre-compiled (brutally shared) scripts and functions, just top level functions statically scoped by the objects scoping the scripts in which the functions were loaded. Scripted functions had script data structures, which had principals. The JS compiler created all of function objects, their private function data, and the functions' script data structures all at once.

Even more primordial to this design was the intrinsic scope chain link, the "parent" slot in every object. It was used also for DOM event handler scoping.

Equally primordial, and a bug in waiting, was the design by which the compiler created function objects which sometimes could be used at runtime because they had the right heritage (but as things evolved, sometimes this was unsafe). Yet this seemed like a good idea at the time :-/.

Obviously adding closures and precompilation meant needing diverse scope links, as the singular nature of a compiler-created function object's parent slot became a pigeon-hole problem. This begat cloned function objects, created both by the JS_CloneFunctionObject API and automatically by the interpreter when it processed function definitions on entry to an execution context (to use the ECMA-262 term).

Even after JS_CloneFunctionObject and its internal form were added, the compiler continued to make function objects with pre-set parent slots, which owned compiler-created functions owning scripts owning principals.

The compile-and-go (JS_Evaluate*Script* API) case was thought to be faster for this pre-setting, but it really doesn't matter who creates the function object (the compiler or the interpreter) in this case -- so we *probably* kept compiler-created function objects for no good reason -- but there is clearly an API compatibility constraint here (more below, final bullet).

Trust label and lexical scope should be the same, this is sound. But as the history recounted above shows, the linkage of function to script to principal, which came first in the JS engine and API, had the potential not to match the principal of the ultimate lexical scope object (a window object, a global object in ECMA terms) that was linked via parent. To put it in terms of the code, the fun->script->principal and fun->object->fslots[JSSLOT_PARENT] links could disagree.

So the mozilla/caps code was hacked to detect when parent might not lead to the same principal as the one sealed by the compiler. The hack checked whether the callee object for the frame being visited, call it funobj, was equal to the compiler-created fun->object. If so, then the fun->script->principals sealed by the compiler were reliable. If not, then the scope chain had to be walked.

For performance, it's still important to avoid walking the scope chain when using compiler-preset data is sound.

We're moving toward not creating function objects at compile time, but in the top of CVS trunk code we still do -- we just null out the parent slot (and the proto slot) to avoid leaks. This has regressed some use-cases.

(In reply to comment #22)
> Consider the following js code:
> 
> access_privileged_functionality_1;
> outer();
> 
> function outer()
> {
>     access_privileged_functionality_2;
>     inner();
> 
>     function inner()
>     {
>         access_privileged_functionality_3;
>     }
> }
> 
> Even before the bug 424376 has landed, access_privileged_functionality_3 would
> throw a security exception as inner will always be a cloned function. 

Did you test that? I don't think it's true -- for the particular patterns of API use implemented in Mozilla so far.

In the compile-and-go case, of course everything is in one global scope and compiled with one principal. Even the inner function, a closure, which will be cloned in order to have its wrong compiler-set parent slot reset to be the activation (Call) object of outer, will use the same principal, since scope chains all end in the that one global object.

In the precompiled ("brutal sharing") case, the top-level script is executed with the same principal sealed into it by the compiler, but with a different scope chain (global object). But this does not matter in practice because chrome XUL uses the system principal always, and XBL does not use top level scripts AFAIK.

For the functions in the precompiled case, the runtime parent (scope) differs from the compiler-memoized one and both inner and outer are cloned, which in the chrome XUL case still leads to a system principal. In the XBL case the right window is found and its principal used (bz, check me here).

Of course, remote XUL is in big trouble if it does not compile-and-go, but IIRC we never brutally share non-chrome XUL.

Obvious problems with the design:

* Igor's right, bz saw this: we shouldn't risk privilege escalations by saving the system principal in any script we precompile for later shared executions in different scopes/trust-domains -- we should set a null principal pointer. This should not hurt compile-and-go performance.

* We need to get rid of compiler-created function objects completely, so that execution or introspection via an API creates the function object for a given compiler-created function data structure. From first principals, given:

JS_Compile*Function*(...) -> JSFunction *

and

JS_GetFunctionObject(fun) -> JSObject *

we have a compatibility problem. If JS_Compile*Function* does not create a function object, then JS_GetFunctionObject must, so it needs to take a cx param and be fallible, etc. But even then, the question is what should the newborn function object's parent be? Should it be the object at the end of cx's scope chain? It should not be cx->globalObject unless that's the only possibility.

If we save a (strong) reference in the compiler-created function for use as the default parent later, we get leaks. If we don't, we get incompatibilities. We are going to have to choose, quickly for 1.9 and well for the longer run.

/be

Comment 25

[Igor Bukanov]

(In reply to comment #24)
> > Even before the bug 424376 has landed, access_privileged_functionality_3 would
> > throw a security exception as inner will always be a cloned function. 
> 
> Did you test that? I don't think it's true -- for the particular patterns of
> API use implemented in Mozilla so far.

I have not tested this, but this follows from the code: the inner function will be cloned and for such cases with or without the patch from the bug 424376 the security manager will call doGetObjectPrincipal which uses function's parent chain for principlas without any special treatment of call objects representing closures.  

Comment 26

[Igor Bukanov]

(In reply to comment #24)
>  we shouldn't risk privilege escalations by saving
> the system principal in any script we precompile for later shared executions in
> different scopes/trust-domains -- we should set a null principal pointer. This
> should not hurt compile-and-go performance.

The question where this precompilation happens?

Comment 27

[Boris Zbarsky [:bzbarsky]]

> The question where this precompilation happens?

content/xbl/*, content/xul/* should be the only places, I think.  We'd need to change those and rev the fastload version, I assume.  

I'll try to read Brendan's long comment and sort through it tomorrow.

Comment 28

[Brendan Eich [:brendan]]

(In reply to comment #25)
> (In reply to comment #24)
> > > Even before the bug 424376 has landed, access_privileged_functionality_3 would
> > > throw a security exception as inner will always be a cloned function. 
> > 
> > Did you test that? I don't think it's true -- for the particular patterns of
> > API use implemented in Mozilla so far.
> 
> I have not tested this, but this follows from the code: the inner function will
> be cloned and for such cases with or without the patch from the bug 424376 the
> security manager will call doGetObjectPrincipal which uses function's parent
> chain for principlas without any special treatment of call objects representing
> closures. 

I think that's ok though -- it'll find the same global object and its principal.

The cloned function object is scoped by the outer function's Call object -- its parent slot points to that activation object.

(In reply to comment #26)
> (In reply to comment #24)
> >  we shouldn't risk privilege escalations by saving
> > the system principal in any script we precompile for later shared executions in
> > different scopes/trust-domains -- we should set a null principal pointer. This
> > should not hurt compile-and-go performance.
> 
> The question where this precompilation happens?

http://lxr.mozilla.org/mozilla/ident?i=nsXULPrototypeScript
http://lxr.mozilla.org/mozilla/find?string=nsXBLProto

/be

Comment 29

[Igor Bukanov]

(In reply to comment #28)
> (In reply to comment #25)
> > I have not tested this, but this follows from the code: the inner function will
> > be cloned and for such cases with or without the patch from the bug 424376 the
> > security manager will call doGetObjectPrincipal which uses function's parent
> > chain for principlas without any special treatment of call objects representing
> > closures. 
> 
> I think that's ok though -- it'll find the same global object and its
> principal.

The parent of the call object for the inner function is the same global object for the outer function. If it would be ok, then this bug would not exist.


 

Comment 30

[Brendan Eich [:brendan]]

(In reply to comment #29)
> > I think that's ok though -- it'll find the same global object and its
> > principal.
> 
> The parent of the call object for the inner function is the same global object
> for the outer function.

The inner function here:

access_privileged_functionality_1;
outer();

function outer()
{
    access_privileged_functionality_2;
    inner();

    function inner()
    {
        access_privileged_functionality_3;
    }
}

is lightweight, it has no Call object reifying its activation when invoked. But it must be cloned to carry, via the clone's parent link, the outer function's Call object. The outer function's Call object for its invocation (outer(); in the second line) is scoped by the global object presented to the interpreter via the execution API -- I hope! If this is broken there is indeed trouble.

> If it would be ok, then this bug would not exist.

Is that a schematic simplification of this bug? I didn't think so from reading comment #16.

/be

Comment 31

[Igor Bukanov]

(In reply to comment #30)
> The inner function here:
> 
> access_privileged_functionality_1;
> outer();
> 
> function outer()
> {
>     access_privileged_functionality_2;
>     inner();
> 
>     function inner()
>     {
>         access_privileged_functionality_3;
>     }
> }
> 
> is lightweight, it has no Call object reifying its activation when invoked. But
> it must be cloned to carry, via the clone's parent link, the outer function's
> Call object. The outer function's Call object for its invocation (outer(); in
> the second line) is scoped by the global object presented to the interpreter
> via the execution API -- I hope! If this is broken there is indeed trouble.

But this is exactly the bug: in this case the code should use the principals embedded into JSScript behind the function, not the principals from the global object.

Now, with landing of the bug 424376, it is not only the "inner" function but also the "outer" function that is affected as the code effectively assumes that all the functions are clones.

Comment 32

[Igor Bukanov]

Attachment: v1

This is what I am testing now. The patch marks all the clones that are not created by the interpreter with a special bit and check for that bit in the security manager. Effectively now nsScriptSecurityManager::GetFunctionObjectPrincipal is restored to the state it was before the bug 424376 was landed except the code now uses FUN_IS_EXPLICIT_CLONE(fun) to check for clones:

~/m/ff/mozilla/caps/src/> cvs diff -r 1.354 nsScriptSecurityManager.cpp
Index: nsScriptSecurityManager.cpp
...
-    else if (JS_GetFunctionObject(fun) != obj)
+    else if (FUN_IS_EXPLICIT_CLONE(fun))
     {
-        // Here, obj is a cloned function object.  In this case, the
-        // clone's prototype may have been precompiled from brutally
-        // shared chrome, or else it is a lambda or nested function.
-        // The general case here is a function compiled against a
-        // different scope than the one it is parented by at runtime,
-        // hence the creation of a clone to carry the correct scope
-        // chain linkage.
+        // Here, obj was created using js_CloneFunctionObject from, for
+        // example, brutally shared precompiled chrome. The general case
+        // here is a function compiled against a different scope than the one
+        // it is parented by at runtime, hence the creation of a clone to
+        // carry the correct scope chain linkage.
         //
         // Since principals follow scope, we must get the object
         // principal from the clone's scope chain. There are no
         // reliable principals compiled into the function itself.

Comment 33

[Igor Bukanov]

Attachment: v2

The new version fixes some typos and adds more asserts.

Comment 34

[Igor Bukanov]

(In reply to comment #33)
> Created an attachment (id=312110) [details]
> v2
> 
> The new version fixes some typos and adds more asserts.
> 

I got 3 mochi test failures with the patch.

Comment 35

[Boris Zbarsky [:bzbarsky]]

So from my point of view as a JSAPI consumer here, here's what things look like.  When I compile a script/function/whatever, I pass in two things: a scope object and a principal.  These can easily become "mismatched" in the sense that the principal is not the object principal of the scope object.  I believe right now we more or less rely on cases like that using the passed-in principal.  That's certainly the case for the subscript loader, and might be the case for SJOW, since SJOW aims to seal in principals, iirc.

In the compile-and-go case, the toplevel parts of a script use the passed-in principal no matter what as things stand.  The parts in functions should imo do the same.

I think what would make the most sense to me here, and this is what Igor seems to be doing, is to use the passed-in principal except in the explicit brutally-shared case, and to use the scope chain in that case.

Comment 36

[Igor Bukanov]

(In reply to comment #33)
> Created an attachment (id=312110) [details]
> v2
> 
> The new version fixes some typos and adds more asserts.

The patch is wrong: for precompiled shared scripts all the function and closures (which are cloned functions) have to use the parent scope chain as a source of principals. For compile-and-go scripts all its functions and closures wants to use the principal embedded into the script. 

With the patch the closures created with precompiled scripts would use the principal embedded into the script. This is a bug.

A proper way to address this would be to have a special kind of marker principals for shared scripts that tells to use the principals from the current scope chain.

Since I have almost zero experience with this code, I am not the right person to address this ideally. So for now I will update the patch to always mark cloned functions as such. It should revert the situation back to pre-bug  	424376 state.

So I will update the patch to always set the cloned flag on the cloned

Comment 37

[Igor Bukanov]

Attachment: v3

The patch should restore the same semantic of principals checks that was before the bug 424376 has been addressed.

Comment 38

[Igor Bukanov]

Comment on attachment 312159 [details] [diff] [review]
v3

The patch has passed mochi tests.

Comment 39

[Brendan Eich [:brendan]]

Comment on attachment 312159 [details] [diff] [review]
v3

Looks good, thanks.

/be

Comment 40

[Igor Bukanov]

Marking as fixed as the patch from bug 424376 that caused the regression was backed out.