This avoids the small overhead and potential for bugs from the previous
approach of assuming all `const char*` arguments passed to `nsITimer`
initializers are string literals, by instead requiring the argument to be a
`const nsACString&`. This involves changing all callsites to pass a `""_ns`
string literal down instead of a bare string literal.
It appears that while there were currently no buggy callers which
would've provided a dynamic string, there was at least one piece of code
(nsRepeatService::Start) which did pass down a raw char* which may be
dynamically allocated (all callers pass down `nsLiteralCString` so we're
actually OK here right now, but this was a footgun).
Differential Revision: https://phabricator.services.mozilla.com/D261032
This reverts commit 8c929cc018.
Revert "Bug 1979013 - Part 2: Require nsITimer API callers to provide a nsACString, r=xpcom-reviewers,media-playback-reviewers,webrtc-reviewers,profiler-reviewers,dom-storage-reviewers,toolkit-telemetry-reviewers,firefox-style-system-reviewers,mstange,emz,bwc,janv,emilio,padenot"
This reverts commit e01c0a6a32.
Revert "Bug 1979013 - Part 1: Eagerly fetch name for timer callbacks, r=xpcom-reviewers,mccr8"
This reverts commit 9f8e73c163.
This avoids the small overhead and potential for bugs from the previous
approach of assuming all `const char*` arguments passed to `nsITimer`
initializers are string literals, by instead requiring the argument to be a
`const nsACString&`. This involves changing all callsites to pass a `""_ns`
string literal down instead of a bare string literal.
It appears that while there were currently no buggy callers which
would've provided a dynamic string, there was at least one piece of code
(nsRepeatService::Start) which did pass down a raw char* which may be
dynamically allocated (all callers pass down `nsLiteralCString` so we're
actually OK here right now, but this was a footgun).
Differential Revision: https://phabricator.services.mozilla.com/D261032
I thought this was the root cause of bug 1925564, but turns out it's
not. Still, mousedown doesn't guarantee a mouseup if you move the mouse
out of the element, so seems wise not to use it. It only sorta works
because thumb dragging captures the scrollbar...
Use the hover state and the drag state instead, which simplifies the
code anyways.
Differential Revision: https://phabricator.services.mozilla.com/D226905
That's what we use for painting in all platforms except macOS with
overlay scrollbars, where we make it sticky. Make the stickiness more
explicit (this also fixes the sticky state getting cleaned up too
early).
Differential Revision: https://phabricator.services.mozilla.com/D222161
This is the actual fix. The way this code works, mousemove events
trigger zero-duration activity periods.
So checking IsActive is not the right thing to do, because that means we
bail out too early from HandleEvent once we've stopped scrolling.
Instead track the effective visibility of the scrollbar, which is what
the previous code did.
This allows mousemoves and so on to keep the scrollbar active on macOS.
Differential Revision: https://phabricator.services.mozilla.com/D195012
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
This rewrites scrollbar layout to work with regular reflow rather than
box layout.
Overall it's about the same amount of code (mostly because
nsScrollbarFrame::Reflow is sorta hand-rolled), but it cleans up a bit
and it is progress towards removing XUL layout altogether, without
getting into much deeper refactoring.
This also blocks some other performance improvements and refactorings I
want to make in this code.
We make some assumptions to simplify the code that to some extent were
made already before, both explicitly and by virtue of using XUL layout.
In particular, we assume that scrollbar / slider / thumb has no border or
padding and that the writing-mode is horizontal ltr.
Differential Revision: https://phabricator.services.mozilla.com/D173489
This rewrites scrollbar layout to work with regular reflow rather than
box layout.
Overall it's about the same amount of code (mostly because
nsScrollbarFrame::Reflow is sorta hand-rolled), but it cleans up a bit
and it is progress towards removing XUL layout altogether, without
getting into much deeper refactoring.
This also blocks some other performance improvements and refactorings I
want to make in this code.
We make some assumptions to simplify the code that to some extent were
made already before, both explicitly and by virtue of using XUL layout.
In particular, we assume that scrollbar / slider / thumb has no border or
padding and that the writing-mode is horizontal ltr.
Differential Revision: https://phabricator.services.mozilla.com/D173489
After the fixes in this patch, the REQUIRES_UNIFIED_BUILD declaration is no
longer needed, so I'm removing it here. This directory now builds successfully
with that removed and with ac_add_options --disable-unified-build in the
mozconfig.
Depends on D125610
Differential Revision: https://phabricator.services.mozilla.com/D125611
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
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
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
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
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
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
Daniel Holbert