Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
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
  3. @bholley

    Bug 750859 - Kill the CAPS confirm dialog. r=bz

    bholley authored
    This will break addons using enablePrivilege, but that's going away too. We've been warning for many releases now, so it's time to bite the bullet.
  4. @bholley
Commits on Apr 28, 2012
  1. @krizsa
Commits on Apr 26, 2012
  1. @rvandermeulen
  2. @krizsa
Commits on Apr 25, 2012
  1. @rvandermeulen
  2. @krizsa
Commits on Apr 16, 2012
  1. @dvander

    Remove simple JS_FrameIterator use from content, DOM, and caps (bug 7…

    dvander authored
    …44617, r=mrbkap).
    
    --HG--
    extra : rebase_source : 003a5285b549845d47c9298606d737620db5bb3d
Commits on Apr 14, 2012
  1. @Ms2ger
  2. @Ms2ger
Commits on Apr 12, 2012
  1. @mcapella

    Bug 740688 - Use uintptr_t instead of PRUword, and intptr_t instead o…

    mcapella authored
    …f PRWord. r=jwalden
    
    --HG--
    extra : rebase_source : 648a581323d2c2893df780f71fe34dadcc4bbaab
Commits on Apr 5, 2012
  1. @bholley
Commits on Mar 31, 2012
  1. @petervanderbeken

    Fix for bug 740069 (Generate JS bindings in C++ with a python script …

    petervanderbeken authored
    …for DOM objects on the main thread and in workers. Infrastructure and new bindings for XMLHttpRequest). Patch by bent/bz/bholley/jst/khuey/peterv, r=bent/bz/bholley/jlebar/khuey/peterv/sicking/smaug.
    
    --HG--
    rename : js/xpconnect/tests/mochitest/test_bug462428.html => dom/bindings/test/test_lookupGetter.html
Commits on Mar 24, 2012
  1. Backed out changeset 30798fdc5bad

    Dão Gottwald authored
  2. @Ms2ger
Commits on Mar 15, 2012
  1. @bholley
Commits on Mar 14, 2012
  1. @gavinsharp

    Bug 732413: make DISALLOW_INHERIT_PRINCIPAL flag passed to checkLoadU…

    gavinsharp authored
    …RI effective even when the source principal is the system principal, r=bz
    
    --HG--
    rename : caps/tests/mochitest/test_bug470804.html => caps/tests/mochitest/test_disallowInheritPrincipal.html
    extra : transplant_source : %CD%A3%DD%8Aa%DC%1F%BE%F8%0DB%BE%86%3FQ%D8%95%88%9E%CA
Commits on Mar 12, 2012
  1. @jlebar

    Bug 729940 - Part 2: Stop using crappy hash functions in Gecko. r=bz

    jlebar authored
    --HG--
    extra : rebase_source : 6fa267a89878cc1a766d8618569debcea9b12e48
Commits on Mar 9, 2012
  1. @ibukanov

    bug 728250 - remove JSPrincipals::codebase. r=:luke,:bz

    ibukanov authored
    In just 2 cases where JSPrincipals::codebase is used it can be reconstructed from the values stored in the associated nsJSPrincipal. In addition the patch makes nsJSprincipals to inherit both from nsIPrincipal and JSPrincipals allowing to use static_cast to convert between nsIPrincipal and JSPrincipals pointers and to drop many cases of manual JSPrincipal reference counting.
Commits on Feb 20, 2012
  1. @ibukanov

    bug 737624 - memory-only encoding/decoding of scripts and functions. …

    ibukanov authored
    …r=:luke
    
    The patch shrinks the API presented in jsxdrapi.h down to 4 functions to
    encode/decode scripts and interpreted functions to/from the memory. The
    newly introduced implementation header vm/Xdr.h replaces the former
    JSXDRState with the template class XDRState parametrized by the enum
    type with two constants, XDR_ENCODE and XDR_DECODE. This way a compiler
    can fully eliminate the former runtime checks for the decoding/encoding
    mode. As a drawback this required to explicitly instantiate the xdr
    implementation as I do not want to put all the xdr code to header files.
    
    The memory-only XDR allows to avoid coping filename and to-be-atomized
    chars to a temporary buffer as the code can just access the buffer
    directly. Another change is that new XDRScript takes as a parameter its
    parent script. This allowed to avoid keeping filename in XDRState and
    simplify the filename management.
    
    Another change is the removal of JS_HAS_HDR. As CloneScript uses XDR to
    copy a script, JS_HAS_XDR cannot be disabled.
    
    --HG--
    rename : js/src/jsxdrapi.cpp => js/src/vm/Xdr.cpp
    extra : rebase_source : f8f1536a86b7c3fe7296a16b6677bd21664af98a
  2. @ibukanov

    bug 737624 - memory-only encoding/decoding of scripts and functions. …

    ibukanov authored
    …r=:luke
    
    The patch shrinks the API presented in jsxdrapi.h down to 4 functions to
    encode/decode scripts and interpreted functions to/from the memory. The
    newly introduced implementation header vm/Xdr.h replaces the former
    JSXDRState with the template class XDRState parametrized by the enum
    type with two constants, XDR_ENCODE and XDR_DECODE. This way a compiler
    can fully eliminate the former runtime checks for the decoding/encoding
    mode. As a drawback this required to explicitly instantiate the xdr
    implementation as I do not want to put all the xdr code to header files.
    
    The memory-only XDR allows to avoid coping filename and to-be-atomized
    chars to a temporary buffer as the code can just access the buffer
    directly. Another change is that new XDRScript takes as a parameter its
    parent script. This allowed to avoid keeping filename in XDRState and
    simplify the filename management.
    
    Another change is the removal of JS_HAS_HDR. As CloneScript uses XDR to
    copy a script, JS_HAS_XDR cannot be disabled.
    
    --HG--
    rename : js/src/jsxdrapi.cpp => js/src/vm/Xdr.cpp
  3. @ibukanov

    bug 737624 - memory-only encoding/decoding of scripts and functions. …

    ibukanov authored
    …r=:luke
    
    The patch shrinks the API presented in jsxdrapi.h down to 4 functions to
    encode/decode scripts and interpreted functions to/from the memory. The
    newly introduced implementation header vm/Xdr.h replaces the former
    JSXDRState with the template class XDRState parametrized by the enum
    type with two constants, XDR_ENCODE and XDR_DECODE. This way a compiler
    can fully eliminate the former runtime checks for the decoding/encoding
    mode. As a drawback this required to explicitly instantiate the xdr
    implementation as I do not want to put all the xdr code to header files.
    
    The memory-only XDR allows to avoid coping filename and to-be-atomized
    chars to a temporary buffer as the code can just access the buffer
    directly. Another change is that new XDRScript takes as a parameter its
    parent script. This allowed to avoid keeping filename in XDRState and
    simplify the filename management.
    
    Another change is the removal of JS_HAS_HDR. As CloneScript uses XDR to
    copy a script, JS_HAS_XDR cannot be disabled.
    
    --HG--
    rename : js/src/jsxdrapi.cpp => js/src/vm/Xdr.cpp
Commits on Feb 13, 2012
  1. @ibukanov

    bug 730221 - delegating serialization of script principals to the emb…

    ibukanov authored
    …edding. r=:luke,:bz
    
    Currently to serialize principals stored in JSScript we have a rather complex
    schema. First there is the transcode callback that the embedding must provide
    to transcode principals using XDR API. Second we use rather complex glue code
    to implement that callback in terms of writing/reading nsIObjectOutputStream/
    nsIObjectInputStream. This glue code is duplicated in 3 places. All this can
    be avoided if we simply delegate transcoding of principals to the caller. In
    addition, at least in the case of the cached startup scripts we do not even
    need to transcode the principals as the the cached scripts always have the
    system principal so we can skip all the transcode complexity there.
    
    The patch implemnts this idea. In particular, the code in JS engine
    responsible for transcoding of principals is replaced by the single API
    function JS_XDRSetPrincipals that the embedding can use to set principals for
    decoded scripts and functions. Then the startup cache uses this to set the
    principals for the decoded script to the system principals. The other two
    places in nsJSContext::Serialize and  XBL_SerializeFunction that need to
    serialize principals together with a function or script now uses common
    utilities in nsXPConnect so the serialization complexity resides in the single
     place.
Something went wrong with that request. Please try again.