Bug 832920 - fix failure for browser_dbg_bug723069_editor-breakpoints.js.  r=past
Bug 832920.  Add a way for chrome iframes to opt into having a separate refresh driver (e.g. if they plan to be moved between windows) and make devtools use that opt-in.  r=tnikkel,paul
Bug 843261.  Add support for sequence<DOMString> arguments in WebIDL callbacks.  r=peterv

This does allow people to accidentally hit the slower path through use
of non-const strings, but I think that's OK now that we're mostly
autogenerating this stuff
Bug 776536 part 1.  Rename nsNodeIterator to mozilla::dom::NodeIterator.  r=peterv

--HG--
rename : content/base/src/nsNodeIterator.cpp => content/base/src/NodeIterator.cpp
rename : content/base/src/nsNodeIterator.h => content/base/src/NodeIterator.h
Bug 776536 part 2.  Rename nsTreeWalker to mozilla::dom::TreeWalker.  r=peterv

--HG--
rename : content/base/src/nsTreeWalker.cpp => content/base/src/TreeWalker.cpp
rename : content/base/src/nsTreeWalker.h => content/base/src/TreeWalker.h
Bug 776536 part 3.  Add a WebIDL API to NodeIterator and TreeWalker.  r=peterv
Bug 776536 part 4.  Turn on WebIDL bindings for NodeIterator and TreeWalker.  r=peterv

The behavior here is a bit weird because Document is still not a
WebIDL object, so calling createNodeIterator or createTreeWalker via
an Xray will call the XPCOM versions of those methods.  That means
that I can't just disable XPCOM-based wrapping for TreeWalker and
NodeIterator altogether, unfortunately, which means a web page could
try stashing a TreeWalker in something like userdata and then getting
it back and end up wrapping it as an XPCOM object the second time.

I could "fix" that by adding a wrapper cache and whatnot, I guess, if
desired...  But the problem will go away once we convert Document in
any case.