On 7/20/16 9:16 AM, jip.de.b...@gmail.com wrote:
Then when I try to assign it, I get this error:
8:10.55 In file included from /build/dom/base/Unified_cpp_dom_base5.cpp:92:
8:10.55 /source/release/dom/base/nsDocument.cpp:3580:18: error: no viable
overloaded '='
8:10.55 e->mNode = node;
8:10.55 ~~~~~~~~ ^ ~~~~
8:10.55 /build/dist/include/mozilla/dom/BindingDeclarations.h:297:7: note: candidate
function (the implicit copy assignment operator) not viable: no known conversion from
'nsIContent *' to 'const mozilla::dom::Optional<mozilla::OwningNonNull<nsINode>
>' for 1st argument
8:10.55 class Optional<OwningNonNull<T> > : public Optional_base<T,
OwningNonNull<T> >
8:10.55 ^
8:11.94 1 error generated.
I understood from your reply that I should make the Node variable required. But
the documentation doesn't show how this works.
That's because "required" is a WebIDL spec concept, not a Mozilla
extenson. How it works is covered by the spec.
The way you do it is like this:
dictionary myFunctionElementInfo {
required Node node;
};
That will make the dictionary member be an OwningNonNull<nsINode>
instead of an Optional<OwningNonNull<nsINode>>.
This doesn't:
dictionary myFunctionElementInfo {
Element element;
};
I'm guessing that the problem is that doing that causes
DocumentBinding.h to include Element.h. Presumably Element.h
(indirectly) includes nsIDocument.h; not sure what the exact path is
here. nsIDocument.h includes DocumentBinding.h. So you end up with an
#include loop, and some things never end up included correctly.
It gives many errors similar to this:
0:12.03 /build/dist/include/mozilla/dom/Element.h:810:12: error: incomplete
type 'nsPresContext' named in nested name specifier
0:12.03
nsPresContext::AppUnitsToIntCSSPixels(sf->GetScrollRange().XMost()) :
0:12.03 ^~~~~~~~~~~~~~~
The interesting thing here is the very _first_ error it gives.
I'm not sure if I need Node or Element in my case, I just want to return the
HTML elements so I can do more with them on the JavaScript side. The return
value of ElementsFromPoint() is what I'm after, so that's why I think I need to
use Element instead of Node.
It doesn't matter, really. You can use Node; it'll still be the same
thing on the JS side.
You could also put your dictionary in a separate webidl file, so it
doesn't change the includes for DocumentBinding.h. Then as long as you
just forward-declare the dictionary type in nsIDocument.h and include
your new binding header in nsDocument.cpp things will be fine.
-Boris
_______________________________________________
dev-tech-layout mailing list
dev-tech-layout@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-layout
