This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
CompareCacheHashEntry::mCrit[] is the only case where the nsXPIDLString-ness
was important. The patch adds an explicit SetIsVoid() call to that class's
constructor and changes some null checks to IsVoid() checks.
--HG--
extra : rebase_source : e68befcde4dd098bac2a550bc666eaf3bf1298d7
CreateFrameFor only gets called for frames that get constructed by the special
nsCSSFrameConstructor::CreateAnoymousFrames path
There's nothing special about buttons, so they just take the normal
AddFCItemsForAnonymousContent path. That path actually asserts against
a non-trivial CreateFrameFor implementation, but the assert currently
doesn't fire due to the mismatch between aPossiblyLeafFrame (which is the
nsGfxButtonControlFrame used to generate the anonymous content) and aFrame
(which is the inner block frame passed as the container to
AddFCItemsForAnonymousContent).
* we know all types frames may be cast to at compile time, so instead of extensible GUID IIDs, use a big enum (see nsQueryFrame::FrameIID)
* eliminate all vestiges of refcounting, since frames aren't refcounted
Some frames (SVG frames in particular) still implement nsISupports-derived interfaces, for example nsISVGValue. There is a FrameIID for nsISVGValue that lets you go from a frame to the XPCOM interface, but you can't query back.
r+sr=roc
nsITextControlFrame didn't have an IID the first time around, but this wasn't a compile error because nsITextControlFrame::kFrameIID inherited from nsIFormControlFrame::kFrameIID. I've added a static analysis pass to verify the correct behavior, since I can't figure out a way to make the compiler do it.
--HG--
extra : rebase_source : 4894a2ca0278e2ab92f27459db77165f8348cf41
* we know all types frames may be cast to at compile time, so instead of extensible GUID IIDs, use a big enum (see nsQueryFrame::FrameIID)
* eliminate all vestiges of refcounting, since frames aren't refcounted
Some frames (SVG frames in particular) still implement nsISupports-derived interfaces, for example nsISVGValue. There is a FrameIID for nsISVGValue that lets you go from a frame to the XPCOM interface, but you can't query back.
r+sr=roc
This patch locally causes two REFTEST-UNEXPECTED-PASS for Bidi stuff. It's possible that I accidentally fixed a bug, but I'm not sure, so I'm going to wait for the tinderboxes to confirm my local results.
