Bug 1486732 - Remove useless nsXBLBinding::mIsShadowRootBinding. r=smaug Differential Revision: https://phabricator.services.mozilla.com/D4434

Bug 1486536 - Crashtest. r=heycam Differential Revision: https://phabricator.services.mozilla.com/D4362

Bug 1486536 - Explicitly flush the StyleSet from FlushPendingNotifications. r=heycam When CSS rules change, we usually do this implicitly from FlushUserFontSet & co. However there's a code path that dirties the stylist but not the CSS rules, and that's when the compat mode changes and we're an SVG document. I don't think that can get hit (easily, at least?), but it's pretty easy to do so and I think this is cleaner too. This fixes that case so the stylist can't assert in that case either, and so that we still rebuild the cascade data so that the hash maps use the right keys for a given quirks-mode. Differential Revision: https://phabricator.services.mozilla.com/D4361

Bug 1486536 - Make nsPresContext::CompatibilityModeChanged() properly call PresShell::ApplicableStylesChanged. r=heycam We usually rely on this call happening soon enough that it doesn't matter, but from document.write it can matter actually. This is the call that makes this work the same way as other sheet addition / removals. This would fix cases where counter styles / @font-face rules in quirk.css wouldn't get properly updated in some cases. Hopefully we don't have any of those. Differential Revision: https://phabricator.services.mozilla.com/D4360

Bug 1486166 - Set the tooltip text on the parent of the urlbar input. r=dao The reason bug 1440682 broke this was because I moved all the code to nsXULElement. However, there was a way for non-XUL elements to get XUL tooltips before that, which was via the RestyleManager mechanism to handle attribute mutations. So the behavior before that patch was that non-XUL elements that got the attribute dynamically added or removed before that patch got their tooltips, like the HTML input in the toolbar, but if you specified the attributes statically in the markup, or while the element was somehow outside of the document or what not, it would never work. Given that, this looks completely unintentional, and the fact that this ever worked was a bit lucky. Chances are we eventually want tooltip support for HTML elements in chrome documents, but it is pretty likely that we want to use the HTML tooltip infrastructure instead of nsXULTooltipListener, which is kind of an odd thing. Thus, for now patch the code so that it sets it on the container of the <input>, which is a XUL box that takes the same space as the <input>, instead of moving all the XUL tooltip support to work on non-XUL elements. Also, while at it, remove references to inputtooltiptext, since I didn't find a single reference in the code that would set this attribute ever. Differential Revision: https://phabricator.services.mozilla.com/D4294

Bug 1425700 - Make the counters non-atomic counters and merge afterwards. r=bholley This was consistently faster in the benchmark (even when counters were disabled, which was slightly suspicious, but...). Anyway, it's not really much code, most of it is FFI copy-pasta. Differential Revision: https://phabricator.services.mozilla.com/D3874

Bug 1425700 - Add a parsing benchmarks with use counters. r=bholley That way we have a simple baseline to measure overhead. Differential Revision: https://phabricator.services.mozilla.com/D3839

Bug 1425700 - Add a test for the use counters. r=heycam Mostly testing that they work, and that they record what we expect them to record, that is, the actual property that was parsed, and not the properties that it'd resolve or expand to. That may be another tricky part for CSSOM, I think style setters would fail an alias test if implemented with the current setup (we do the property lookup in C++). Differential Revision: https://phabricator.services.mozilla.com/D3829

Bug 1425700 - Hook the use counters into StyleSheet parsing. r=heycam Still not hooked into telemetry, I talked with :janerik and :gfritzsche about that, but test incoming! This intentionally doesn't handle CSSOM and such for now, will file followups for those, though should be trivial. I want to unify / clean up how we do the use counters and the error reporting stuff for CSSOM, since the current function call still shows up in profiles, but that should be a follow-up. Differential Revision: https://phabricator.services.mozilla.com/D3828

Bug 1425700 - Add a very simple use counter implementation. r=heycam As simple as I could make it, for now. We can improve on this. Differential Revision: https://phabricator.services.mozilla.com/D3827

Bug 1486456 - [wdspec] Add basic tests for "Get Element rect". r=ato

Bug 1485485 - make bootstrap accept rustc/cargo in known-good locations; r=chmanchester moz.configure looks for rustc/cargo on PATH and in ~/.cargo/bin. Bootstrap only looks on PATH and not in ~/.cargo/bin, though it is smart enough to complain if rustc/cargo can't be found on PATH and you have them in ~/.cargo/bin. Bootstrap should look in both places by default, and be content if it finds them wherever they are, so long as moz.configure can find them.

Bug 1485701 - make the interceptor code compilable, if not functional, on aarch64 windows; r=aklotz

Bug 1486040 - make WindowsDllBlocklist.h functional for aarch64 windows; r=aklotz

Bug 1486039 - use a more-portable idiom for pausing in SpinEvent::Wait; r=aklotz YieldProcessor is apparently defined to do the same thing on x86 as our custom macros, but includes implementations for non-x86 processors.

Bug 1486020 - eliminate warning spam about ICU RTTI with MSVC; r=chmanchester

Bug 1485347 - Part 2: Remove CheckScriptDataIntegrity. r=jandem This diagnostic did not provide value and should be removed to allow further cleanup. MozReview-Commit-ID: 49XJM0G7NAP

Bug 1485347 - Part 1: Remove nTypeSets argument from JSScript::partiallyInit. r=jandem MozReview-Commit-ID: I6xBHG8FLlq

Bug 1486528 - Remove some unnecessary nsIMemory imports. r=njn

Bug 1486495 - [wdspec] Create basic tests for "Get Element CSS Value" command.