This lifts a bunch of string conversions higher up the stack, but allows
us to make the servo code use utf-8 unconditionally, and seemed faster
in my benchmarking (see comment 0).
It should also make a bunch of attribute setters faster too (like
setting .cssText), now that we use UTF8String for them (we couldn't
because we couldn't specify different string types for the getter and
setters).
Differential Revision: https://phabricator.services.mozilla.com/D99590
The editor modules does QI too many times when it sets or removes some style
with `execCommand` or XPCOM API. Therefore, there should be an API to
retrieve `nsStyledElement` pointer from `nsINode*`.
Differential Revision: https://phabricator.services.mozilla.com/D87990
Converts `layout.testing.overlay-scrollbars.always-visible` to a static pref.
Differential Revision: https://phabricator.services.mozilla.com/D69611
--HG--
extra : moz-landing-system : lando
In particular, the ones where we transcode unconditionally atm (property names
and such).
There are others like cssText getters and setters which are a bit harder,
because I either need to rewrite all our serialization code to work with UTF8
(which is fine, but a lot of work), or teach webidl to have a setter that takes
UTF8String as input but returns DOMString as output (which is at best hacky).
Differential Revision: https://phabricator.services.mozilla.com/D58631
--HG--
extra : moz-landing-system : lando
Initially this was going to be a simple cleanup: Remove some useless namespaces
here and there and so on, remove `using` statements from the header and so on.
But unfortunately, DOMIntersectionObserver.h (which is included in Element.h,
unnecessarily) ended up exposing `Element` unnamespaced to a lot of code, so I
had to fix that.
Differential Revision: https://phabricator.services.mozilla.com/D55316
--HG--
extra : moz-landing-system : lando
At
https://searchfox.org/mozilla-central/rev/2f29d53865cb895bf16c91336cc575aecd996a17/layout/generic/nsGfxScrollFrame.cpp#3166
we sort the scrollbar parts based on hovered state so that the hovered scrollbar is on top of a non-hovered scrollbar. This means that changing the hover state of a scrollbar can change the ordering of the scrollbar display items in the display list. So when the hover state changes we need to mark the frames modified.
I'm guessing the reason this didn't come up before is because we needed a combination of scrollbars that don't have any style changes on hover and a platform that has hover events. I'm guessing GeckoView scrollbars don't have a style change on hover, and we don't commonly have a mouse or mouse like cursor device hooked up to GeckoView devies to have hover events. Except Firefox Reality has a cursor thingy so we see the problem there.
Differential Revision: https://phabricator.services.mozilla.com/D48234
--HG--
extra : moz-landing-system : lando
At
https://searchfox.org/mozilla-central/rev/2f29d53865cb895bf16c91336cc575aecd996a17/layout/generic/nsGfxScrollFrame.cpp#3166
we sort the scrollbar parts based on hovered state so that the hovered scrollbar is on top of a non-hovered scrollbar. This means that changing the hover state of a scrollbar can change the ordering of the scrollbar display items in the display list. So when the hover state changes we need to mark the frames modified.
I'm guessing the reason this didn't come up before is because we needed a combination of scrollbars that don't have any style changes on hover and a platform that has hover events. I'm guessing GeckoView scrollbars don't have a style change on hover, and we don't commonly have a mouse or mouse like cursor device hooked up to GeckoView devies to have hover events. Except Firefox Reality has a cursor thingy so we see the problem there.
Differential Revision: https://phabricator.services.mozilla.com/D48234
--HG--
extra : moz-landing-system : lando
Also switch the XPCOM-y version of EventTarget::AddEventListner to a
Nullable<bool> for aWantsUntrusted.
The three-arg overload of AddEventListener in ContentFrameMessageManager was
never called, so all the AddEventListener overloads there are not needed.
MozReview-Commit-ID: 4IhqHmPVWzE
We can't have a null content in
ScrollbarActivity::StopListeningForScrollAreaEvents, because only viewport
frames have a null GetContent().
MozReview-Commit-ID: 9iAg0ivVqqG
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
