This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
The opening of the AutoCompletePopup will always start from content, but closing the
popup can occur in the parent (for example, if the user switches focus from the browser),
or in content (the user hits Esc, for example, which tells the parent to close the popup).
This relationship between content and the popup has been true for a while, but the
patch in bug 1294502 didn't account for it. In particular, before this patch, it was
possible for AutoCompletePopup in browser-content.js and AutoCompletePopup.jsm to get
out of sync on whether or not the popup is open.
Mainly, this is because the parent wasn't telling the content that the popup had
hidden if the hide was initialized by the parent. The other reason, was because
the popupOpen state in browser-content.js was being set immediately, instead
of waiting for the parent to report that the popup had indeed opened or closed.
MozReview-Commit-ID: CRkg49lP1Hd
Bug 1294502 recently refactored the form autocomplete code to
combine the e10s and non-e10s mechanisms. The new combined
mechanism works using something mostly similar to what we
used for e10s, except that we forgot to re-set the nsITreeView
when the autocomplete results are invalidated.
MozReview-Commit-ID: 4veXklEgLGl