After fixing the absolute path issue in codespell, I noticed that the stylish
formatter doesn't indent lint issues that don't have a column properly. This
was never noticed before since most other linters have a column attribute.
Depends on D4012
Differential Revision: https://phabricator.services.mozilla.com/D4013
--HG--
extra : moz-landing-system : lando
Prior to this patch, getHSTSPreloadList.js would queue an XHR for every preload
list candidate site. This meant that there would be ~50,000 requests in flight
simultaneously. Simply processing these requests caused them to all time out,
and no useful work was done. This patch resolves them in batches of 250 to
avoid this issue.
Differential Revision: https://phabricator.services.mozilla.com/D3622
--HG--
extra : source : e0f0d5824dd8aaaaf1395e569cec1806b028b12e
extra : amend_source : 62f1cd6fc49cbae39c7691c5712906f775862887
Prior to this patch, getHSTSPreloadList.js would queue an XHR for every preload
list candidate site. This meant that there would be ~50,000 requests in flight
simultaneously. Simply processing these requests caused them to all time out,
and no useful work was done. This patch resolves them in batches of 250 to
avoid this issue.
Differential Revision: https://phabricator.services.mozilla.com/D3622
--HG--
extra : moz-landing-system : lando
Filed bug 1487036 for a fix that would avoid triggering events for the
placeholder when it's not showing, though realistically I'm not going to have
cycles to fix it.
Probably moving the <input> to Shadow DOM would allow such a solution, but it's
not clear we want to do that just yet at least.
Differential Revision: https://phabricator.services.mozilla.com/D4525
--HG--
extra : moz-landing-system : lando
The completion node was wrongly positioned as soon as the input overflowed.
We fix this by setting the completionNode height in resizeInput,
like we do for the inputNode.
The inputNode takes the whole remaining vertical space
when starting the console. But when typing, the height
is computed and set according to what's in the input.
Which means the input wasn't taking the remaining space
anymore, which could be weird (e.g. if the user wants
to select some text by starting dragging below the actual
input, although the UI would indicate it is possible).
The autocompletionPopup was a bit off due to 2 things:
- in the function that was returning the chevronWidth, we
were subtracting the autocomplete popup padding. But the
autocomplete popup already handles that itself.
- in the function that was computing the character width,
we were using offsetWidth which returned a rounded value.
This means that the further the autocompletion was displayed
at, the more the popup would be off. We use getBoundingClientRect().width
instead which gives us a decimal value.
And we also make sure to not alter the scrolling position in the inputNode
when accepting an autocompletion result (a test is added).
Differential Revision: https://phabricator.services.mozilla.com/D4207
--HG--
extra : moz-landing-system : lando
In Bug 1478435 a selector was removed causing the background
of the SearchBox autocomplete to be transparent and without
box-shadow.
This patch add the needed rule in the CSS. We take this as an
opportunity to fix a small positioning issue by making sure
the element stick to the left.
Differential Revision: https://phabricator.services.mozilla.com/D4421
--HG--
extra : moz-landing-system : lando
When `document.blockParsing()` is called, the nsIParser is suspended
until the document is unblocked. For about:blank documents, this is a
nsParser.
When a document is unblocked, nsParser::ContinueInterruptedParsingAsync
is invoked, which delegates its implementation to nsIContentSink, which
is a nsHTMLContentSink for about:blank documents. Due to a missing
implementation of nsHTMLContentSink::ContinueInterruptedParsingAsync,
the parser was never resumed, causing bug 1465388 and bug 1407501.
This patch fixes the problem, by implementing the required method (and
using a load blocker to ensure that the (about:blank) document does not
finish before the parser finishes).
This patch is tested through extension tests: Currently document_start
stylesheets always activate the parser blocker, and document_start
scripts trigger the parser blocker when the script has not been
preloaded yet (e.g. at the first run).
Before this patch, the test failed due to the assertion failure as
reported in the linked bugs. After this patch, the tests pass.
Differential Revision: https://phabricator.services.mozilla.com/D4352
--HG--
extra : moz-landing-system : lando
That attribute is set async, _inOverflow should work equally well, and work if
there's a mousemove before the next promiseDocumentFlush callback runs.
Differential Revision: https://phabricator.services.mozilla.com/D4520
--HG--
extra : moz-landing-system : lando
In the MinGW browser build job, we're going to use -fms-extensions,
which will tell clang to start processing these comments. Clang
cannot process them correctly (it's an upstream bug) but it doesn't
need to, because we include the libs we need in moz.build files.
So we exclude them for MinGW builds. mingw-clang gets them wrong and
mingw-gcc (which doesn't even work anymore on -central) ignored them.
In the future, with a llvm fix, we could clean up the moz.build
files and re-enable these comments.
Differential Revision: https://phabricator.services.mozilla.com/D3527
--HG--
extra : moz-landing-system : lando
This restores the old allocation semantics for "append" operations between
Latin1 and UTF-16 while keeping the buffer re-use optimization for the
"assign" cases.
MozReview-Commit-ID: 8JCw3AaCNLN
Differential Revision: https://phabricator.services.mozilla.com/D3582
--HG--
extra : moz-landing-system : lando
Adjust sunspider raptor test to make lower_is_better=true and treat it as 'ms' and not a 'score'
Differential Revision: https://phabricator.services.mozilla.com/D4454
--HG--
extra : moz-landing-system : lando
These were used when we were working on the HTML version of the frontend, but now
we don't even ship the XUL version, and these properties got missed during removal.
Differential Revision: https://phabricator.services.mozilla.com/D4463
--HG--
extra : moz-landing-system : lando
Currently there are 3 things that can impact the result of a lint run:
1. The list of lint issues found
2. The set of failures that happened during the setup phase
3. The set of failures that happened during the execution phase
All three of these things are stored as instance variables on the LintRoller
object, and then passed into a formatter when it comes time to print the
results. I'd like to add even more things that can impact the result, and it
became clear that the current scenario does not scale well.
This patch moves all data that could impact the end result of a lint run off of
the LintRoller object and onto a new 'result.ResultSummary' class. To avoid
confusion, this patch also renames the 'result.ResultContainer' class to
'result.Issue'.
With this new nomenclature:
result -> overall state of an entire lint run (can comprise multiple linters)
issue -> one specific lint infraction (at either 'warning' or 'error' level)
failure -> a non-recoverable error in the linter implementation itself
A "result" is comprised of 0 or more "issues" and 0 or more "failures".
Differential Revision: https://phabricator.services.mozilla.com/D3819
--HG--
extra : moz-landing-system : lando
We were previously using the original test url as the lhs for each
comparison after the top level, rather than the previous rhs url as
expected.
Differential Revision: https://phabricator.services.mozilla.com/D4081
--HG--
extra : moz-landing-system : lando
