The nsCSSFrameConstructor bits are now handled in PresShell::Destroy along with
the other refresh driver observers.
I cleaned up the nsRefreshDriver methods because they were using infallible
append anyway, and that simplified the logic.
MozReview-Commit-ID: 1eDUUXjUUS9
PresShell only uses performane.now to track refresh times, and notify internal
observers. We can provide more accurate times by not clamping and jittering
these numbers.
MozReview-Commit-ID: FkDGJhrLeAy
--HG--
extra : rebase_source : 99c571d1e5df53f51b4be0304df3818c161d2972
This code was originally added to debug the frame visibility code.
However it wasn't architected correctly and makes the compositor use an
untrusted layers id from content. Instead of fixing this I'd rather just
delete it, since it's a big pile of code that is basically a debugging
tool that nobody owns anymore.
MozReview-Commit-ID: nPZqVeYsFp
Summary:
* Remove unnecessary virtual, since we also override.
* Remove unnecessary mozilla:: qualification, since we are in the mozilla
namespace already.
* Avoid inconsistently-followed member-variable indentation.
* Make the destructor not virtual, since it doesn't override anything and this
is a final class (the destructor is called from the virtual Release()).
Reviewers: dholbert
Bug #: 1443753
Differential Revision: https://phabricator.services.mozilla.com/D690
MozReview-Commit-ID: Hy2aKuhoOKd
Also, make them not rebuild the CascadeData synchronously, via the
FlushSkinSheets call, since that's broken. That fixes bug 1413119.
This is a little step in getting rid of XBL usage for Shadow DOM.
MozReview-Commit-ID: HJ7FeUZlRTW
--HG--
extra : rebase_source : 0fcd0ed461856c1e87e45ef63c9e1d2e81281469
The event targets of touch events are not necessarily to be the same as their corresponding pointer events. So we don't have to cache the event target of pointer events when they are generated from touch.
MozReview-Commit-ID: 9Gd6ion7NXf
This makes the pres shell be notified as the last observer unconditionally.
In practice this doesn't matter, and it may already be the case if an iframe
goes display: none and back. In practice, the only dependency that requires this
order is that the pres shell needs to be notified _after_ the content sink, so
we don't try to enter frame construction before beginning the shell update.
That may be worth looking into, but definitely not in the scope of this bug... :)
MozReview-Commit-ID: 9WeJ5kaUtBq
--HG--
extra : rebase_source : 6589df0aa8a875dc270894fabb6b4bc170d6b6fe
This also makes the rule map not process all the stylesheets for the document,
which would be a mess with shadow DOM.
Far from the final, ideal state, but hey, progress.
MozReview-Commit-ID: 7TrifME9VZ
This also makes the rule map not process all the stylesheets for the document,
which would be a mess with shadow DOM.
Far from the final, ideal state, but hey, progress.
MozReview-Commit-ID: 7TrifME9VZ
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
I'm drive-by removing the comment about the frame tree state because I looked
into it, and the answer is: we properly restore it.
The gotcha is that we retain it too much, indeed, we retain it enough that it
can leak. See bug 1397239.
MozReview-Commit-ID: LP6bXkduEZ4
--HG--
extra : rebase_source : f7e18fc35e48b75c07fcc84b939614d379926828
After the fix to bug 1294442 and bug 1324499, ResizeReflow began to be called
twice for each DOM update in webext popups, and we also artificially re-set the
scroll outside of ResizeReflow to counter the DidDoReflow callback in
nsHTMLScrollFrame setting scrolltop to zero due to the first reflow, which is
done with unconstrained height.
Because of the scrollport being reset we get spurious DOM scroll events.
Replacing the scrollport also interrupts smooth scrolling.
Move the double-reflow down one level into PresShell, doing it before
DidDoReflow is called. The scrollport is no longer reset (causing a spurious
scroll event), and we don't need to replace it (interrupting smooth scrolling).
Also partially fixes bug 1396034.
MozReview-Commit-ID: HzYITyH4UeW
--HG--
extra : rebase_source : 567056300bc81c9e4c197783f48636caf67cde34
extra : intermediate-source : ef7322dfd99d79a403bb0804638a46c70ece1b45
extra : source : 4f1761bb955473026b4deba76a5e76e93b7ede35
For parent process, users may expect the UI is interactable after they saw the
first tab has restored/shown.
So this patch added a new topic "sessionstore-one-or-no-tab-restored" which
represents the parent process has finished a tab restoring. If there is nothing
to restore, it is effectively equal to "sessionstore-windows-restored".
For centent processes, users may expect web content is interactable when the
top-level-content-document has finished loading, which is different from the
parent case.
MozReview-Commit-ID: AtEUW80Ea6n
--HG--
extra : rebase_source : d920975bf95545ea9e3127d3f570b814fe301be9
There's only one case of sync frame construction from ContentRemoved now, and
it's not on the element being removed, but on the whitespace siblings if needed,
and _only_ when they don't support lazy frame construction.
Basically, this switches all the RecreateFramesForContent calls to use
`aAsyncInsert` (which I changed to an enum class for readability), except when
we're already reframing.
Also, it switches ReframeTextIfNeeded to opt-in into lazy frame construction,
since it's used only when aFlags == CONTENT_REMOVED.
This allows to simplify the DestroyFramesFor API (which I'm happy to rename to
something more meaningful, since now it's something like
DestroyFramesForAndRecreateThemAsync), and do some other consistency cleanups.
A bunch of the ContentRemoved callsites were pretty random at passing
aAsyncInsert, and that was some kind of a mess. This patch ensures consistency,
and makes it impossible to do O(n^2) work when removing DOM nodes, which is
nice.
The underlying reason for this is explained in the description of bug 1377848,
and basically allows us to remove a bunch of Servo hacks on the longer term (a
few of them are going away already, yay!).
MozReview-Commit-ID: 2DrUTxGV8RX
--HG--
extra : rebase_source : f428d839a5482477dea22c0fea600d54f3e8799c
This patch does the following.
- Moves nsWindowSizes from nsWindowMemoryReporter.h to its own file,
nsWindowSizes.h, so it can be included more widely without exposing
nsWindowMemoryReporter.
- Merges nsArenaMemoryStats.h (which defines nsTabSizes and nsArenaMemoryStats)
into nsWindowSizes.h.
- Renames nsArenaMemoryStats as nsArenaSizes, and nsWindowSizes::mArenaStats as
nsWindowSizes::mArenaSizes. This is the more usual naming scheme for such
types.
- Renames FRAME_ID_STAT_FIELD as NS_ARENA_SIZES_FIELD.
- Passes nsWindowSizes to PresShell::AddSizeOfIncludingThis() and
nsPresArena::AddSizeOfExcludingThis(), instead of a bunch of smaller things.
One nice consequence is that the odd nsArenaMemoryStats::mOther field is no
longer necessary, because we can update nsWindowSizes::mLayoutPresShellSize
directly in nsPresArena::AddSizeOfExcludingThis().
- Adds |const| to a few methods.
MozReview-Commit-ID: EpgFWKFqy7Y
FocusTarget used to be needed in nsIPresShell, but it was moved to PresShell.
MozReview-Commit-ID: HQFpT9OJaUz
--HG--
extra : rebase_source : ddc29462fc71f8a71dd2419823ddf6f7e92a60ce
This commit also schedules empty transactions on input events that trigger a
focus sequence number update.
MozReview-Commit-ID: 1FWXfStLsGv
--HG--
extra : rebase_source : 02c6f07287b6909493f6f88345a3cca93ab3e45b
This commit begins the work needed for tracking focus by creating two new classes,
FocusTarget and FocusState. FocusState is created and used by APZCTreeManager to
track the global focus information, while FocusTarget is created per layer tree and
sent to APZ with local focus information. Between the two we are able to figure out
what the correct scrollable layer is to use in response to a keyboard scroll.
See the comment in `FocusState.h` for more details on the architecture and things
needed in future patches to complete this.
MozReview-Commit-ID: F75VZv3i9U2
--HG--
extra : rebase_source : 3d04bced8e13a9884f0c1b320bad8ba2205d7011
I plan to use it for now to force a full document restyle when a standalone rule
changes or something like that.
In practice, we can do better sometimes, and we may just want to propagate to
the StyleSet all the style change notifications in order to have access to the
rule that changed and all that...
But for now this seemed easier than adding other four or five functions to
StyleSetHandle.
MozReview-Commit-ID: 2BEIliGu4mO
--HG--
extra : rebase_source : 386a1b9fe5ffc5fefbf20678068573ea195043f0
I plan to use it for now to force a full document restyle when a standalone rule
changes or something like that.
In practice, we can do better sometimes, and we may just want to propagate to
the StyleSet all the style change notifications in order to have access to the
rule that changed and all that...
But for now this seemed easier than adding other four or five functions to
StyleSetHandle.
MozReview-Commit-ID: 2BEIliGu4mO
--HG--
extra : rebase_source : 926f8442fbd17c7ffa7f72b6b4a515a28b9aa18b
Say there's a single lag event, a GC or a busy loop, during which the user
types several characters.
Is this one (lag) event? Several (input) events?
We have INPUT_EVENT_RESPONSE_MS which will accumulate several lagged events in
this case. However, that is more of an indication of how users use Firefox than
how good we've been at eliminating sources of lag.
INPUT_EVENT_RESPONSE_COALESCED_MS records the coalesced time spend waiting for
responses to input events. So in this case it will record one value for the
entire duration of the lag.
MozReview-Commit-ID: H5rYnhwF0q3
--HG--
extra : rebase_source : b9be179dac6c6a007d2835b909ec4ce71a3f1c90
It's not only inefficient, but also prone to buggyness. Since styles may not be
up-to-date when it happens.
Post a reconstruct instead, which ensures a style flush happens before running
frame construction.
MozReview-Commit-ID: DrakHsJv5fY
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
--HG--
extra : rebase_source : 11900af908654336cc2391ab9480542c5474e38f
It is possible that events created before the OS goes to sleep will remain
unhandled until after the OS wakes. They will have long response times on
platforms where TimeStamp increments during sleep (like Windows) even though
they really shouldn't. (and the user likely doesn't care if they do).
So don't record those.
MozReview-Commit-ID: 4ybjF8gjkae
--HG--
extra : rebase_source : ff48923c6589d9cbac3284dd81f28598677ca449
