This patch goes through and changes a bunch of places in our tree which mention
this bug to use the new feature, making the methods more strongly typed.
There are probably more places in tree which could be changed, but I didn't try
to find them.
As suggested during the review of the original patch, we actually need to
distinguish between very recent user input (< 1 ms) and no known user input
whatsoever. Otherwise, our logic to detect URL loads via the URL bar won't work
if the user never interacted with Gecko content and only touched the native
Android UI since starting the app.
MozReview-Commit-ID: CbZNigwKcjN
updateLayerTree() is called from the callback of MozAfterPaint in
reftest-content.js all the time except when we specify reftest-no-sync-layers
or reftest-no-flush. If there is a throttled animation,
FlushPendingNotifications flushes the animation, thus it will fire another
MozAfterPaint event. It means we will end up waiting for the throttled
animation to finish. This reiteration MozAfterPaint events can be easily
observed in WebRender since WebRender fires MozAfterPaint event without
checking invalidation change. Whereas current Gecko fires MozAfterPaint only
if invalidation change happens and reftests for such throttled animations
specify the same value for 'from' and 'to' value, so it hasn't been a problem
there.
The FlushPendingNotifications in updateLayerTree() was introduced in bug
1083635 <https://hg.mozilla.org/mozilla-central/rev/5bebfbefb3c2> to
sync-decode images so it shouldn't matter if there are still throttled
animations.
MozReview-Commit-ID: B9KgNCX0kWq
Channel layout is derived by the content being played. The concept of preferred layout is meaningless. Either we have a layout defined, or we don't. There's no in-between.
So we remove it.
MozReview-Commit-ID: CSCAInNmzMS
Currently we can only have one type of WebRenderUserData on an Item. We already
have a hash table of WebRenderUserData so it's not hard to include type in the
hash to support one per type.
MozReview-Commit-ID: geJ0BeWv8b
Most of them just want GetRootFrame(), and there's no need to explicitly go
through the frame manager for that, we have a handy alias in the shell.
MozReview-Commit-ID: GriEqkasidY
Everyone calls them with the shell of the current composed document, and this
allows the multi-presShell stuff to just be in UpdateCurrentStyleSources /
DoGetStyleContextNoFlush.
The only reason we need to use OwnerDoc()->GetShell() instead of the composed
doc in GetStyleContext / GetStyleContextNoFlush is Element::GetBindingURL, which
does expect to get the binding URL for stuff outside of the composed doc (and
changing that gave me a useless browser).
That's technically a behavior change on the cases that used to pass nullptr, but
I think all callers are fine with that. I could also just add a special function
for that particular case, it may be worth it.
MozReview-Commit-ID: 2XlnkgdgDCK
nsIDOMWindowUtils::sendKeyEvent() is already replaced with nsITextInputProcessor
for making callers set any attributes of KeyboardEvent and guaranteeing
consistency behavior with keyboard events caused by native key events. E.g.,
whether keypress event should be dispatched or not is automatically decided.
nsIFrameLoader::sendCrossProcessKeyEvent() is similart to
nsIDOMWindowUtils::sendKeyEvent() but it dispatches keyboard events in
child process directly. Currently, nsITextInputProcessor doesn't have this
feature but nobody wants/uses this feature. So, for removing actual
implementation of nsIDOMWindowUtils::sendKeyEvent(), i.e.,
nsContentUtils::SendKeyEvent(), which is shared by both
nsDOMWindowUtils::SendKeyEvent() and nsFrameLoader::SendCrossProcessKeyEvent(),
we should remove this unused API too. (FYI: it's implemented for old Fennec,
by bug 553149.)
MozReview-Commit-ID: 9n0UVo8Me8k
nsIDOMWindowUtils.focusedInputType is necessary to check if IMEStateManager
sets InputContext of widget properly. So, let's keep it but make its type
AString (nsAString&) rather than string (char**).
MozReview-Commit-ID: 1RHhmAsPY5a
In this patch, we remove 3 tests:
1. test for blocked domain
2. test for blocked sub-domain
3. test for non-blocked domain
Two nsIDOMWindowUtils APIs were added for adding/removing a mock domain to the
existing blocklist. They are only used in the Stylo blocklist tests, so we
remove them as well.
MozReview-Commit-ID: A0ETWlqwbpN
