Bugzilla

Yeah, I "fixed" some of the include paths in https://phabricator.services.mozilla.com/D15231#384160 . I was going for consistency with e.g. dom/base, where for example (to pick a few included files):
 - 35 .cpp files include "mozilla/dom/Element.h" with its dom/base export path, vs. 1 lacks it.
 - 7 .cpp files include "mozilla/dom/Text.h" with the path, vs. 0 lack it.
 - 6 .cpp files include "mozilla/dom/Attr.h" with the path, vs. 0 lack it.
 - 6 .cpp files include "mozilla/dom/DOMRect.h" with the path, vs. 0 lack it

I gathered the above numbers using these commands, which I ran in dom/base:
 grep \/DOMRect.h *.cpp
 grep \"DOMRect.h *.cpp

So: at least in dom/base, it seems like we've essentially standardized on using the full include path.  Having said that, if there's a functional reason to do it the other way, that's fine with me since it doesn't seem to be explicitly mentioned in oru c++ coding style guide (or in Google's).

I'll let jwatt have the final say here. :)

Yeah, I "fixed" some of the include paths in https://phabricator.services.mozilla.com/D15231#384160 . I was going for consistency with e.g. dom/base, where for example (to pick a few local included files):
 - 35 .cpp files include "mozilla/dom/Element.h" with its full export path, vs. 1 lacks it.
 - 7 .cpp files include "mozilla/dom/Text.h" with the path, vs. 0 lack it.
 - 6 .cpp files include "mozilla/dom/Attr.h" with the path, vs. 0 lack it.
 - 6 .cpp files include "mozilla/dom/DOMRect.h" with the path, vs. 0 lack it

I gathered the above numbers using these commands, which I ran in dom/base:
 grep \/DOMRect.h *.cpp
 grep \"DOMRect.h *.cpp

So: at least in dom/base, it seems like we've essentially standardized on using the full include path.  Having said that, if there's a functional reason to do it the other way, that's fine with me since it doesn't seem to be explicitly mentioned in oru c++ coding style guide (or in Google's).

I'll let jwatt have the final say here. :)