Skip to content
This repository

Jun 28, 2012

  1. bholley

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

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

    Bug 754202 - Remove mContextPrincipal usage from within nsScriptSecur…

    …ityManager. r=mrbkap
    bholley authored
  3. bholley

    Bug 754202 - Remove context pushing/popping API. r=mrbkap 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'?
    bholley authored
  4. bholley

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

    …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.
    bholley authored
  5. bholley

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

    …assert that behavior doesn't change. r=bz
    bholley authored

Jun 19, 2012

  1. Justin Lebar

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

    … 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 : 8f861c2
    jlebar authored

Jun 13, 2012

  1. Ehsan Akhgari

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

    …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
    ehsan authored

Jun 11, 2012

  1. Ryan VanderMeulen

    Merge m-c to inbound

  2. David Baron

    Backout bug 754202 (all patches, rather than just patches 3-7).

    dbaron authored

Jun 10, 2012

  1. Ryan VanderMeulen

    Backout 90107a2a0c64 (bug 754202) for real due to orange.

  2. Ryan VanderMeulen

    Revert c39d36167b99 due to a horribly munged backout.

  3. Ryan VanderMeulen

    Backout the bug 754202 backout due to orange.

  4. bholley

    Merge backout.

    bholley authored
  5. bholley

    Back out bug 754202. r=me

    bholley authored
  6. Ms2ger

    Bug 734891 - Followup: Fix build warnings in nsPrincipal.cpp.

    Ms2ger authored

Jun 09, 2012

  1. Gabor Krizsanits

    Bug 734891 - part 2: Adding ExpandedPrincipal support

    krizsa authored
  2. Gabor Krizsanits

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

    … related logic of nsPrincipal
    krizsa authored
  3. Gabor Krizsanits

    Bug 734891 - part 0: rearanging nsPrincipal methods for follow up

    krizsa authored

Jun 07, 2012

  1. bholley

    Bug 754202 - Remove mContextPrincipal usage from within nsScriptSecur…

    …ityManager. r=mrbkap
    bholley authored
  2. bholley

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

    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'?
    bholley authored
  3. bholley

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

    …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.
    bholley authored
  4. bholley

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

    … assert that behavior doesn't change. r=bz
    bholley authored

Jun 06, 2012

  1. Boris Zbarsky

    Bug 761707 part 2. Drop the vestigial jsclass argument to UnwrapDOMOb…

    …ject. r=bholley
    bzbarsky authored

May 21, 2012

  1. Bug 716478 - update licence to MPL 2.

    Gervase Markham authored

May 19, 2012

  1. Brian Hackett

    Use handles in API object hooks where possible, bug 750733. r=billm

  2. Brian Hackett

    Backed out changeset 5fc7462dd394 for android orange.

  3. Brian Hackett

    Use handles in API object hooks where possible, bug 750733. r=billm

May 18, 2012

  1. Ms2ger

    Bug 754968 - Part c: Make BindingUtils.h not require private xpconnec…

    …t headers; r=bholley
    Ms2ger authored

May 11, 2012

  1. Tom Schuster

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

    evilpie authored
  2. Ed Morley

    Backout 9b0fcaacb788 & bf3fef257e68 (bug 752226) for mochitest-other …

    …orange
    edmorley authored
  3. Tom Schuster

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

    --HG--
    extra : rebase_source : edf2077
    evilpie authored

May 05, 2012

  1. Ms2ger

    Bug 741245 - Remove nsresult return value from nsXPConnect::GetSafeJS…

    …Context(); r=bholley
    Ms2ger authored

May 03, 2012

  1. Boris Zbarsky

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

    …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
    bzbarsky authored

May 02, 2012

  1. bholley

    Bug 750859 - Remove {Disable,Revert}Capability. r=bz, PGO helper on C…

    …LOSED TREE
    bholley authored
  2. bholley

    Bug 750859 - Remove (most of) SetCanEnableCapability. r=bz

    bholley authored
Something went wrong with that request. Please try again.