gecko-dev/js/xpconnect/wrappers/ChromeObjectWrapper.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

43 lines
1.6 KiB
C
Raw Normal View History

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#ifndef __ChromeObjectWrapper_h__
#define __ChromeObjectWrapper_h__
#include "mozilla/Attributes.h"
#include "FilteringWrapper.h"
namespace xpc {
struct OpaqueWithSilentFailing;
// When a vanilla chrome JS object is exposed to content, we use a wrapper that
// fails silently on GET, ENUMERATE, and GET_PROPERTY_DESCRIPTOR for legacy
// reasons. For extra security, we override the traps that allow content to pass
// an object to chrome, and perform extra security checks on them.
#define ChromeObjectWrapperBase \
FilteringWrapper<js::CrossCompartmentSecurityWrapper, OpaqueWithSilentFailing>
class ChromeObjectWrapper : public ChromeObjectWrapperBase {
public:
constexpr ChromeObjectWrapper() : ChromeObjectWrapperBase(0) {}
virtual bool defineProperty(JSContext* cx, JS::Handle<JSObject*> wrapper,
JS::Handle<jsid> id,
JS::Handle<JS::PropertyDescriptor> desc,
JS::ObjectOpResult& result) const override;
virtual bool set(JSContext* cx, JS::HandleObject wrapper, JS::HandleId id,
Bug 1142794 - Change 'receiver' argument to SetProperty functions and ProxyHandler::set methods to be a HandleValue. r=Waldo. Also: Change signature of these functions and methods to all have the same arguments in the same order: (cx, obj, id, v, receiver). Also change v from MutableHandleValue to HandleValue. There is no change in behavior. In fact the new error message `JSMSG_SET_NON_OBJECT_RECEIVER` is impossible to trigger from scripts for now, I think (after re-reading the whole patch with this in mind). JS_ForwardSetPropertyTo is the only way to get a non-object receiver into the engine, but no caller currently does so. We're installing new pipes here, and they should work, but for now it's the same cold water flowing through as before. Actually hooking up the hot water is left for another bug (one with tests, not to put too fine a point on it). Notes: * InvokeGetterOrSetter had to be split into two functions: InvokeGetter takes a MutableHandleValue out-param, InvokeSetter a HandleValue in-param. * Watchpoints can still tamper with values being assigned. So can JSSetterOps. I'm pleased we can support this craziness in a way that doesn't have to spread via the type system to encompass the entire codebase. * Change in GlobalObject::setIntrinsicValue is not really a change. Yes, it asserted before, but an exception thrown during self-hosting initialization is not going to go unnoticed either. * Since the receiver argument to js::SetProperty() is at the end now, it makes sense for it to be optional. Some callers look nicer. --HG-- extra : rebase_source : e89f916fe267800bc73890e11aceef5c4855b272
2015-03-01 19:16:19 +00:00
JS::HandleValue v, JS::HandleValue receiver,
JS::ObjectOpResult& result) const override;
static const ChromeObjectWrapper singleton;
};
} /* namespace xpc */
#endif /* __ChromeObjectWrapper_h__ */