Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Jun 28, 2012
  1. @bholley

    Bug 754202 - Check principal in IsCapabilityEnabled when there's no c…

    bholley authored
    …ode on the stack. r=mrbkap
  2. @bholley
  3. @bholley

    Bug 754202 - Remove context pushing/popping API. r=mrbkap Each one of…

    bholley authored
    … these uses grabs the principal off of an object for pushing, but also enters the compartment of that object. So we shouldn't need this anymore.
    
    Can I get a 'hell yeah'?
  4. @bholley

    Bug 754202 - Pull subject principals directly off the compartment. r=…

    bholley authored
    …mrbkap It would be nice to check these principals against the principals acquired using the old mechanism. Unfortunately, they often differ. Because CAPS uses JS stack frames, any time we enter a compartment and do an operation (even throwing an Access-Denied exception) without running any JS code, we'll end up with a different principal.
    
    Our security story is pretty darn tied to compartments at this point, so let's
    just pull the trigger.
  5. @bholley

    Bug 754202 - Pull object principals directly off the compartment and …

    bholley authored
    …assert that behavior doesn't change. r=bz
Commits on Jun 19, 2012
  1. @jlebar

    Bug 766173 - Hold a strong ref to nsScriptSecurityManager, instead of…

    jlebar authored
    … hoping that it won't get addref'ed or released. r=bsmedberg
    
    --HG--
    rename : mobile/android/base/resources/drawable/tabs_button_contracted.xml => mobile/android/base/resources/drawable/tabs_button.xml
    extra : rebase_source : 8f861c2298fd053a0e1f6deb6f9945040ea8db90
Commits on Jun 13, 2012
  1. @ehsan

    Bug 758992 - Make the classes which use the XPCOM nsISupports impleme…

    ehsan authored
    …ntation macros final, to avoid the warning about deleting using a pointer to a base class with virtual functions and no virtual dtor (caps parts); r=bholley
Commits on Jun 11, 2012
  1. @rvandermeulen

    Merge m-c to inbound

    rvandermeulen authored
  2. @dbaron
Commits on Jun 10, 2012
  1. @rvandermeulen
  2. @rvandermeulen
  3. @rvandermeulen
  4. @bholley

    Merge backout.

    bholley authored
  5. @bholley

    Back out bug 754202. r=me

    bholley authored
  6. @Ms2ger
Commits on Jun 9, 2012
  1. @krizsa
  2. @krizsa

    Bug 734891 - part 1: Decoupling URI based logic from caps/certificate…

    krizsa authored
    … related logic of nsPrincipal
  3. @krizsa
Commits on Jun 7, 2012
  1. @bholley
  2. @bholley

    Bug 754202 - Remove context pushing/popping API. r=mrbkap

    bholley authored
    Each one of these uses grabs the principal off of an object for pushing, but also enters the compartment of that object. So we shouldn't need this anymore.
    
    Can I get a 'hell yeah'?
  3. @bholley

    Bug 754202 - Pull subject principals directly off the compartment. r=…

    bholley authored
    …mrbkap
    
    It would be nice to check these principals against the principals acquired
    using the old mechanism. Unfortunately, they often differ. Because CAPS uses
    JS stack frames, any time we enter a compartment and do an operation (even
    throwing an Access-Denied exception) without running any JS code, we'll end
    up with a different principal.
    
    Our security story is pretty darn tied to compartments at this point, so let's
    just pull the trigger.
  4. @bholley

    Bug 754202 - Pull object principals directly off the compartment, and…

    bholley authored
    … assert that behavior doesn't change. r=bz
Commits on Jun 6, 2012
  1. @bzbarsky
Commits on May 21, 2012
  1. Bug 716478 - update licence to MPL 2.

    Gervase Markham authored
Commits on May 19, 2012
  1. @bhackett1024
  2. @bhackett1024
  3. @bhackett1024
Commits on May 18, 2012
  1. @Ms2ger
Commits on May 11, 2012
  1. @evilpie
  2. @edmorley
  3. @evilpie

    Bug 752226 - Remove any use of JSVAL_IS_OBJECT. r=luke,Ms2ger

    evilpie authored
    --HG--
    extra : rebase_source : edf2077f8b8bad1970eab6ebe9996e761d4e596c
Commits on May 5, 2012
  1. @Ms2ger
Commits on May 3, 2012
  1. @bzbarsky

    Bug 742217. Reduce the use of nested namespaces in our binding code. …

    bzbarsky authored
    …r=peterv,bent
    
    In the new setup, all per-interface DOM binding files are exported into
    mozilla/dom.  General files not specific to an interface are also exported into
    mozilla/dom.
    
    In terms of namespaces, most things now live in mozilla::dom.  Each interface
    Foo that has generated code has a mozilla::dom::FooBinding namespace for said
    generated code (and possibly a mozilla::bindings::FooBinding_workers if there's
    separate codegen for workers).
    
    IDL enums are a bit weird: since the name of the enum and the names of its
    entries all end up in the same namespace, we still generate a C++ namespace
    with the name of the IDL enum type with "Values" appended to it, with a
    ::valuelist inside for the actual C++ enum.  We then typedef
    EnumFooValues::valuelist to EnumFoo.  That makes it a bit more difficult to
    refer to the values, but means that values from different enums don't collide
    with each other.
    
    The enums with the proto and constructor IDs in them now live under the
    mozilla::dom::prototypes and mozilla::dom::constructors namespaces respectively.
    Again, this lets us deal sanely with the whole "enum value names are flattened
    into the namespace the enum is in" deal.
    
    The main benefit of this setup (and the reason "Binding" got appended to the
    per-interface namespaces) is that this way "using mozilla::dom" should Just
    Work for consumers and still allow C++ code to sanely use the IDL interface
    names for concrete classes, which is fairly desirable.
    
    --HG--
    rename : dom/bindings/Utils.cpp => dom/bindings/BindingUtils.cpp
    rename : dom/bindings/Utils.h => dom/bindings/BindingUtils.h
Commits on May 2, 2012
  1. @bholley
  2. @bholley
Something went wrong with that request. Please try again.