This is the real fix for this bug. Previously we mistakenly thought
that if a text node is empty (or has only whitespace content), it is not
editable. This patch removes that check completely and makes us treat
text nodes the same way that we treat element nodes.
This part, similar to the previous one, ensures that we skip empty text
nodes when setting inline properties. Previously we were implicitly
getting this behavior becasue we were calling IsEditable, but we need to
be explicit about this.
The code here is just missing this condition, and this patch is needed
to make the last part of this series pass tests. Previously,
nsEditor::IsEditable would return false when it hit an empty text node,
which implied this property almost by accident. This check makes this
property explicit, so this patch by itself doesn't really change
semantics.
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.
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.
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.
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.
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.
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.
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.
