For reasions which are unclear, MSVC does not recognize the declaration and
definition of ThenWithCycleCollectedArts as matching in their previous form.
Changing both to use the same template `using` declaration for the entire
return type fixes this.
MSVC also has problems with the previous use of std::forward, which is fixed
by explicitly coercing smart pointers to their equivalent pointer types, and
moving any other type.
Differential Revision: https://phabricator.services.mozilla.com/D4397
--HG--
extra : rebase_source : 483fc7c33a0b10227b11862d176299813466ac95
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
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
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
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
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
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
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.
Nathan Froyd
Dorel Luca
Ashley Hauck
Ekanan Ketunuti
Jan Beich
Jorg K
omersid
Narcis Beleuzu
Kris Maglione
Henrik Skupin
Steve Fink
Bas Schouten
Boris Zbarsky
Gurzau Raul
Gabriel Luong
Andrea Marchesini
Kai Engert
Emilio Cobos Álvarez