This allows the JS to work in HTML documents, where whitespace is preserved. In XUL
documents, whitespace is ignored when parsing so text nodes are generally not returned.
The following changes were made, with manual cleanups as necessary (i.e. when firstChild actually
refers to a text node, or when firstChild is used in a loop to empty out an element):
firstChild->firstElementChild
lastChild->lastElementChild
nextSibling->nextElementSibling
previousSibling->previousElementSibling
childNodes->children
MozReview-Commit-ID: 95NQ8syBhYw
--HG--
extra : rebase_source : 186d805f7a2a56694dda9032aceac2dfe5424753
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
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
This patch does a minor refactor of the code used to style popup menu for
the <select> element.
It improves the custom styling experience on MacOS, preserves the functionality
on Windows and removes the unnecessary per-item CSS rules significantly
improving the performance of opening the <select> list.
MozReview-Commit-ID: 7myXq8aDAWr
--HG--
extra : rebase_source : 3ff52f832ec471cca0942e5d8a39961dbc84cff4
Since the order of events is 'blur' followed by 'focus', we send a message from the content process to the parent process and wait for a reply to give enough time for the parent process to signal that the 'blur' was related to the focusing of the search field. If the parent process hasn't signaled as such, then the content process will proceed with hiding the dropdown.
MozReview-Commit-ID: 6ngoo9uHcsM
--HG--
extra : rebase_source : caf43a975827aec71ba82fe39435b05c954673bc
The comparison being removed was only put in place because it seemed like a "good-idea" to prevent <select> from being unreadable, though it's not a fool-proof strategy and it breaks content that uses different styling approaches. This removal does not regress any of the other test cases.
MozReview-Commit-ID: 8HeXZXnjpbl
--HG--
extra : rebase_source : f4eb33de4a8b795fe5dd90c1ede510e8584bf53e
This patch also fixes a bug in our UpdateDropDown code where we weren't computing updated styles for <select> element, as well as another bug where we weren't passing the correct number of arguments to this.populate.
MozReview-Commit-ID: 8LAeIliRXhZ
--HG--
extra : rebase_source : 19c573ffebf700de4b4a470ceb1d2706a8088574
This matches parity with Google Chrome Canary Version 59.0.3046.0 (Official Build) canary (64-bit).
MozReview-Commit-ID: 3rkhiFv8ezX
--HG--
extra : rebase_source : 3cb05e6c1e048bab4c7573bd050ea7477fc128fb
This problem only occurs when optgroups are involved since they introduce recursion in to the menu-building code and we weren't correctly passing state through
the recursion.
MozReview-Commit-ID: 514zcjgXbIY
--HG--
extra : rebase_source : fdb9309ec8b08f5ab8ca77d901065d5e7db1617f
This problem only occurs when optgroups are involved since they introduce recursion in to the menu-building code and we weren't correctly passing state through
the recursion.
MozReview-Commit-ID: 514zcjgXbIY
--HG--
extra : rebase_source : fdb9309ec8b08f5ab8ca77d901065d5e7db1617f
Previously we were respecting the webpages request to show a translucent background on popups, though it now seems that content didn't actually
want a translucent background. After comparing with Chrome, I see that they remove the alpha channel and always show the background color as
fully opaque. This patch also fixes a related bug where the background-color may have been set to a transparent color (not rgba(0, 0, 0, 0)) and
we would show the popup as transparent. This is now fixed with this patch as well.
MozReview-Commit-ID: KqDtvI0zwqP
--HG--
extra : rebase_source : 865bbcd9890997cb0c21f20132a0f033c5c365e4
Portions of the patch were written by Jared Beach (beachjar@msu.edu)
MozReview-Commit-ID: 1SpUTJP8tPq
--HG--
extra : rebase_source : 26c4d857e42bb52a5d728ebeb9bfd8b1b57f98cd
Original patch by Tyler Maklebust <tmaklebust@gmail.com> and Jared Beach <beachjar@msu.edu>
MozReview-Commit-ID: 7FW6PHIrXF4
--HG--
extra : rebase_source : e8132fc8af91657ca80f18a841101bc1070c8b15