Commit Graph

13 Commits

Author SHA1 Message Date
Peter Van der Beken
e6c18ed006 Fix for bug 774775 (XRayWrapper does not handle new bindings constants) - refactor code. r=bz.
--HG--
extra : rebase_source : 317d5942dde4427384320cb334f794f7fef37a2e
2012-07-18 13:52:07 +02:00
Ms2ger
d900ce7ddd Bug 765464 - Part c: Throw some TypeErrors; r=khuey 2012-07-18 12:36:08 +02:00
Bobby Holley
051ea1ec66 Bug 763341 - Handle wrappers in new dom binding QI. r=bz
The |ok| parent check goes away because it's ill-conceived. All it's really checking is that proxies are parented to the global, and it's impossible to port to SpecialPowers, because SpecialPowers will think that the proxy is parented to the SpecialPowers global. I don't think this check is very important, so I removed it.
2012-06-12 15:44:21 +02:00
Boris Zbarsky
31ccf86cf9 Bug 761707 part 2. Drop the vestigial jsclass argument to UnwrapDOMObject. r=bholley 2012-06-06 15:59:46 -04:00
Boris Zbarsky
07d55e8274 Bug 753522. Add support for controlling the existence of methods, properties, interface constants, etc with a pref. r=peterv 2012-05-23 12:44:48 -04:00
Ms2ger
5a68e74435 Bug 754968 - Part c: Make BindingUtils.h not require private xpconnect headers; r=bholley 2012-05-18 10:29:40 +02:00
David Rajchenbach-Teller
e6457109ef Bug 739740 - Export libc constants to JS. r=khuey 2012-05-09 12:00:48 +02:00
Ryan VanderMeulen
4392d08bb5 Back out b5fd22efe23d (bug 739740) due to bustage. r=TryFTW 2012-05-03 18:51:14 -04:00
David Rajchenbach-Teller
e67cd24a59 Bug 739740 - Export libc constants to JS. r=khuey,glandium 2012-04-30 12:14:38 +02:00
Peter Van der Beken
88f4933669 Fix for bug 741367 (Creating second XMLHttpRequest via Components.Constructor throws NS_ERROR_FAILURE): don't overwrite content-defined properties. r=bz.
--HG--
extra : rebase_source : f9c7fe34d4cde28cafea0536e305704e2dc04ff7
2012-04-27 09:57:09 +02:00
Peter Van der Beken
111e784c34 Fix for bug 742156 (Stringifying EventTarget throws): implement a toString method for interface objects. r=bz.
--HG--
extra : rebase_source : cd692b5231e4d183e0bbd368965e704ede54661f
2012-05-02 15:28:17 +02:00
Boris Zbarsky
7080045141 Bug 748983. Fix the instanceof behavior for new bindings in situations where we don't need a custom hasInstance hook. r=peterv 2012-05-03 00:35:38 -04:00
Boris Zbarsky
224115946f 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
2012-05-03 00:35:38 -04:00