Re: Include out of viewport frames in display list

On 7/20/16 9:16 AM, [email protected] 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