628c6823da4fc3bd5c22476eab295cb3a8a323d0: Bug 798135: Make GeckoAsyncTask run on GeckoBackgroundThread. [r=cpeterson]
Sriram Ramasubramanian <sriram@mozilla.com> - Fri, 05 Oct 2012 11:07:14 -0700 - rev 113024
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 798135: Make GeckoAsyncTask run on GeckoBackgroundThread. [r=cpeterson]
d54999bfe1dd18ba5ca302dac6ca272d648fce79: Bug 798429 - Add new talos test names. r=jhammel.
Rafael Ávila de Espíndola <respindola@mozilla.com> - Fri, 05 Oct 2012 13:06:34 -0400 - rev 113023
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 798429 - Add new talos test names. r=jhammel.
3b4562fd4f202ee9759092a69c26c07f8bf6012f: Bug 761695 - Put Proxy and DOM expandos on the expando object, rather than the holder. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:24 +0200 - rev 113022
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Put Proxy and DOM expandos on the expando object, rather than the holder. r=peterv
563787d9f0bb8f6595f8b2f87b4dfea1ac416e9f: Bug 761695 - Hoist expando-checking (but not expando-creating) operations into common code. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:24 +0200 - rev 113021
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Hoist expando-checking (but not expando-creating) operations into common code. r=peterv We do this for delete_, enumerateNames, and resolveOwnProperty. This doesn't change existing behavior, because for ProxyXrayTraits and DOMXrayTraits the expando object will (currently) always be null.
b2bb146b3fa7bfed6c68d4b6491a0801b415c177: Bug 761695 - Create XrayTraits::resolveOwnProperty. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:23 +0200 - rev 113020
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Create XrayTraits::resolveOwnProperty. r=peterv
d8c15d5aeaa238904349eb285887653f1a191aae: Bug 761695 - Reorder checks for expandos and nodePrincipal. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:23 +0200 - rev 113019
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Reorder checks for expandos and nodePrincipal. r=peterv Peter and I decided this was ok. We can't hoist expando stuff otherwise.
bc5648cb99722667dc9ea4dca572214504b1c16d: Bug 761695 - Implement expando traps for ProxyXrayTraits DOMXrayTraits. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:23 +0200 - rev 113018
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Implement expando traps for ProxyXrayTraits DOMXrayTraits. r=peterv For new DOM proxies, we could probably use the Xray expando machinery for the regular expando object as well, and free up one of the reserved slots. That's more than I want to bite off for the moment, though. I also decided not to block on bug 760095 and just kick the problem of globals with new binding down the road a little bit.
509ebfec55a1cf2006e49b8d7897c4e9d0a949ae: Bug 761695 - Move wrapper preservation stuff into a virtual trap. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:23 +0200 - rev 113017
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Move wrapper preservation stuff into a virtual trap. r=peterv I'm not sure this stuff is correct for non-WN objects. Hopefully that will come out in review. Anyway, with this change, the expando infrastructure in XrayTraits is now fully generic and non-WN-specific. To make things work for other objects, we now need to implement the virtual traps and hoist the code that calls the expando machinery out of XPCWrappedNativeXrayTraits.
5763702031329ea3e5072bde2d73be170f5c50ef: Bug 761695 - Make expando chain getting/setting a virtual trap. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:23 +0200 - rev 113016
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Make expando chain getting/setting a virtual trap. r=peterv
0e13f5279a6e3fe2c99ec2ddc4dab40ae7713ea6: Bug 761695 - Hoist expando infrastructure into XrayTraits. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:23 +0200 - rev 113015
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Hoist expando infrastructure into XrayTraits. r=peterv It's still WN-only, now we can move the WN-only bits into virtual traps. Note that the new-binding reparenting code will need to have a call to CloneExpandoChain.
861cd25072734fd6f76f657f1eacc10326e24267: Bug 761695 - Hoist Xray identification machinery into XrayWrapper, and use it for trait identification. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:23 +0200 - rev 113014
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Hoist Xray identification machinery into XrayWrapper, and use it for trait identification. r=peterv We don't currently have a good way of selecting the traits used by a given Xray wrapper. This lets us do that. Note: We add a call to js::UnwrapObject to GetXrayType while hoisting it. When it was used only in WrapperFactory, this was unnecessary, because |obj| was always unwrapped. But for our new purposes, it might not be. Aside from that, there are no changes to the function.
455e5bd1cd2a48e06c7c4fcb3529e860e8d81141: Bug 761695 - Move Xray expando infrastructure further down in the file. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:23 +0200 - rev 113013
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Move Xray expando infrastructure further down in the file. r=peterv Just cut/paste. No code changes.
b1c000f475d45cb532e567d7a099b80cc2597fa4: Bug 761695 - Unify holder creation and access. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:23 +0200 - rev 113012
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Unify holder creation and access. r=peterv With this patch, all holders are created lazily. There are two common accessors, getHolder() and ensureHolder(). The former returns null if no holder exists, the latter lazily creates the holder if it doesn't exist. It does this by calling into a virtual trap on XrayTraits, which lets the appropriate Xray type do its thing.
03667c5bc77b2eea5e3faf521282ee0d30486716: Bug 761695 - Get the WN directly from the wrapper. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:23 +0200 - rev 113011
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Get the WN directly from the wrapper. r=peterv All this indirection was getting seriously mucky. This, incidentally, means that the XPCWN holder no longer needs a reserved slot pointing to the WN.
f5225ec3579517e083d62a5ea6161368ee1d6bae: Bug 761695 - Hoist call and construct traps into Traits, since the current implementations are XPCWN-specific. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:22 +0200 - rev 113010
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Hoist call and construct traps into Traits, since the current implementations are XPCWN-specific. r=peterv
317a3211dfad1e17310c3a427892a354fde2b394: Bug 761695 - Rename getInnerObject to getTargetObject. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:22 +0200 - rev 113009
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Rename getInnerObject to getTargetObject. r=peterv The current name potentially implies that the object returned is an inner object in the JS sense, which isn't true. Really we just want the thing we're Xraying to.
9af31b39e3f794fb0481559cca258992cb90720f: Bug 761695 - Hoist getInnerObject into XrayTraits. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:22 +0200 - rev 113008
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Hoist getInnerObject into XrayTraits. r=peterv The only special handling here with wrapped natives is to make sure that we bypass outer windows. But we can do this with js::UnwrapObject.
8d62ef879869f54b2c7c5ee6155a64924a41619f: Bug 761695 - Make Xray traits inherit from a common superclass and give them a singleton instance. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:22 +0200 - rev 113007
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Make Xray traits inherit from a common superclass and give them a singleton instance. r=peterv There's some code that can be shared between different Xray traits, but can't (yet) be hoisted into XrayWrapper, because it needs to be callable from outside XrayWrapper where we don't have the appropriate template parameters. Moreover, this code benefits from virtual function specialization. The use case here is illuminated in the next patch. For the moment, we skip converting the bulk of the traits calls to virtual methods, because they're working just fine.
cf00f8f3f80dc41c497ce3d5715365784aa6c132: Bug 761695 - Stop stashing a raw WN pointer in XPCWN Xray holders. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:22 +0200 - rev 113006
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Stop stashing a raw WN pointer in XPCWN Xray holders. r=peterv We might as well do this dynamically, which simplifies the code. Note that we could avoid the reserved slot by parenting the holder to the wrapper. But the JS parent API is deprecated, and we need to move away from it to reserved slots anyhow. We might as well start here, with the added advantage that parenting to the global makes us consistent with the other Xray types.
26ffd02bc89ce5b1df54129ca7e8d872f5414f4f: Bug 761695 - Simplify XPCWN Xray holder creation. r=peterv
Bobby Holley <bobbyholley@gmail.com> - Fri, 05 Oct 2012 18:59:22 +0200 - rev 113005
Push 2248 by akeybl@mozilla.com at Mon, 08 Oct 2012 19:23:44 +0000
Bug 761695 - Simplify XPCWN Xray holder creation. r=peterv The major semantic change here is that we parent holders directly to their global. This should be fine.
(0) -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip