The canvas prompt is extremely annoying. It happens everyone, automatically. And in
99.9% (not scientific) of cases it is not triggered by user input, but my automatic
tracking scripts.
This commit will automatically decline the canvas read if it was not triggered by
user input.
Just in case this breaks something irrepairably, we have a cutoff pref.
We don't intend to keep this pref forever, and have asked anyone who sets it to
tell us why.
MozReview-Commit-ID: CxNkuraRWpV
--HG--
extra : rebase_source : 12cfc94cecbd378c0859ae50066c6338bcaa6692
The only remaining instance of NS_IMPL_BOOL_ATTR macro was expanded by hand.
MozReview-Commit-ID: DQ8fGGNTl3y
--HG--
extra : rebase_source : 9ab13bd3e0702b518f8ec8418f2a7a9861ad5062
This is particularly useful for knowing when it's safe to query for style and
layout information for a window without causing a synchronous style or layout
flush.
Note that promiseDocumentFlushed was chosen over promiseDidRefresh or promiseRefreshed
to avoid potential confusion with the actual network-level refresh of browsers or
documents.
MozReview-Commit-ID: Am3G9yvSgdN
--HG--
extra : rebase_source : 20bdd2d6f624767d919d95a6601fc1c890aadf10
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
This is particularly useful for knowing when it's safe to query for style and
layout information for a window without causing a synchronous style or layout
flush.
Note that promiseDocumentFlushed was chosen over promiseDidRefresh or promiseRefreshed
to avoid potential confusion with the actual network-level refresh of browsers or
documents.
MozReview-Commit-ID: Am3G9yvSgdN
--HG--
extra : rebase_source : 20bdd2d6f624767d919d95a6601fc1c890aadf10
This is particularly useful for knowing when it's safe to query for style and
layout information for a window without causing a synchronous style or layout
flush.
Note that promiseDocumentFlushed was chosen over promiseDidRefresh or promiseRefreshed
to avoid potential confusion with the actual network-level refresh of browsers or
documents.
MozReview-Commit-ID: Am3G9yvSgdN
--HG--
extra : rebase_source : 5e502d5d077dd764ca1a43e7c3f06855858fe735
Poking at the frame tree has problems: If we poke in negative (using
eSkipNativeAnonymousContent), as we were doing, we mess up the case where we're
actually _not_ doc-level, and _not_ ::before or ::after. This can't happen for
content documents, but can happen for chrome (since nsDocElementBoxFrame
implements nsIAnonymousContentCreator).
If we poke in positive, as we used to, you get that right, but mess up the
root scrollbar case.
Instead, use a node property to mark doc level anon content. This is a case rare
enough that it seems worth to not steal a node bit.
To recap the failure:
* The initial value of -moz-control-character-visiblity is different on beta
and nightly.
* XUL has a global rule setting -moz-control-character-visibility on the root,
to a value so that it's the initial one on nightly, but the non-initial one
on beta.
* Changes to this property cause a reframe.
* Reframes of a nsIAnonymousContentCreator anon content reframe the container.
* We were failing to inherit correctly for the nsIAnonymousContentCreator
content for the root XUL element on the initial styling, inheriting from the
default computed values instead, since we failed to reach the root element's
primary frame from GetFlattenedTreeParentForDocumentElementNAC ->
AppendDocumentLevelNativeAnonymousContentTo, since the primary frame is set
_after_ processing children.
This seems somewhat risky to change, and inconsistent with any other stuff
the frame constructor does, see bug 973390.
* Given that, the next restyle of the root element, in this case caused due to
the customizable UI, we _found_ the actual correct parent, recomputed the
style, saw that -moz-control-character-visiblity had changed, and reframed.
But we were reframing the whole window, not just the NAC, because of the
fourth bullet point. Reframing the whole window caused us to lose the popup
state (that's bug 1440506).
Worse than that is the fact that given we reframe and reconstruct the
anonymous countent again, we go back to the initial bogus state, just
awaiting for the next restyle to reframe the whole window.
I wish there was a bullet-proof way to test it that isn't just counting reframes
and relying on which properties reframe or not, but due to the nature of
nsIAnonymousContentCreator's NAC, it's not possible in any easy way I can think
of.
MozReview-Commit-ID: IPYB5trsN8R
Also, change DocumentFragment to use RefPtr, since that's the usual style.
MozReview-Commit-ID: 4PQ19nbmhUh
--HG--
extra : rebase_source : 2afb214b764ba48a4a8718190a6853ae6d6ea80b
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : f2a17aee7bb66a7ba8652817d43b9aa7ec7ef710
During a frame swap (using the `swapFrameLoaders` API on a frame loader owner),
we dispatch `pagehide` events before swapping and `pageshow` events after
swapping.
For some consumers that watch these events (such as DevTools), it would be
helpful to filter out the ones that sent because of frame swapping. This change
adds a chrome-only `inFrameSwap` property to such events so that we can tell
them apart.
MozReview-Commit-ID: QzIDuaF2zC
--HG--
extra : rebase_source : 3ac15e34c18b648c4cb060e69587e39e4ebaab60
It would be convenient to get nsPresContext from nsIDocument.
MozReview-Commit-ID: Ei6V3UE8XGr
--HG--
extra : rebase_source : 8d2a917eb62cf341e4e1810451fd01c01dbc3bad
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : 592d13349a8c4627c7ce3146ec592f577b39f3cc
Most WebExtension APIs are async, and have fairly complicated error reporting
semantics. As a result, when we report an error, the current JS stack has very
little to do with the JS caller that triggered the error, which makes it
difficult to diagnose.
In order to improve the situation, we need to store the location of the caller
at the start of an async operation, so we can tie the error to some marginally
useful location. We don't have a reasonable way to do that now other than
proactively creating an error object when the API is called, or creating a
promise with a full async stack, both of which are too expensive.
This helper instead returns a single SavedStack frame with a given principal,
which should be considerably cheaper, and likely good enough to give a
starting point for debugging cryptic errors.
MozReview-Commit-ID: BTxhpZK9Fdz
--HG--
extra : rebase_source : 7f2c66b1dc18d4ce4c47bef2e3b9d5d3ade929aa
We used to do it this way effectively until I fixed it in bug 1400936.
Per the list of fuzz bugs that bug has in the "Depends on" field, some of those
without a super-clear fix, and others that aren't listed in there, and all the
complexity we had to deal with while receiving restyle requests mid-unbind, etc,
I think this is the right call.
This clears data on RestyleManager::ContentRemoved for non-anonymous nodes, and
on UnbindFromTree for subtrees rooted at anonymous nodes.
This will hopefully yield enforceable invariants.
MozReview-Commit-ID: IMwX5Uh1apv
Just expanding the assertion to cover shadow trees.
MozReview-Commit-ID: FLE0noGzaIF
--HG--
extra : rebase_source : fa68f04b8095bd48eab598415e1700620ecce092
Pretty much the same way as what we do on XBL insertion point changes, since the
data would be stale.
I think both of those are kind of a hack, btw, and that we could fix it doing
ClearServoDataFromSubtree properly before we start unbinding. That'd prevent all
these issues, and all the complexity that entails receiving restyle requests
mid-unbind (we'd guarantee the tree is always in a stable state).
That's a matter of a different bug though.
MozReview-Commit-ID: Ev6RvGuPGiv
--HG--
extra : rebase_source : 8ae0db799282bfb8ca2385d6997763f29a082c61
KeyframeEffect and KeyframeEffectReadOnly constructors can run in the caller
compartment, which is okay because the current compartment is used in the
following places and all of them are safe:
1. GlobalObject::CallerType(), that is ultimately passed to
nsDocument::IsWebAnimationsEnabled in KeyframeEffectParamsFromUnion,
to decide whether to copy mIterationComposite/mComposite to
KeyframeEffectParams.
GlobalObject::CallerType() can now be different than the target window's one,
if the caller has the system principal and the target is web content, and
in that case nsDocument::IsWebAnimationsEnabled there always returns true
while Web Animations can be disabled on web content.
honoring the mIterationComposite/mComposite properties is OK, since it just
changes the animation behavior, and this is disabled by default until
remaining spec issues are resolved.
2. GlobalObject::Context(), that is ultimately passed to
KeyframeUtils::GetKeyframesFromObject and used while extracting information
from passed-in keyframe object, with iterable/iterator protocols.
Performing that operation in the caller side is okay, since the same thing
can be done on caller, and the operation doesn't perform any GCThing
allocation on the target window global.
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
KeyframeEffect and KeyframeEffectReadOnly constructors can run in the caller
compartment, which is okay because of the following reasons:
1. The target window global is used for most operation:
* KeyframeEffectReadOnly::ConstructKeyframeEffect uses the target window
global instead of current global.
* KeyframeEffectParamsFromUnion which receives `aGlobal.CallerType()`
In Xray case, Web Animations API can be disabled on web content
(currently disabled on beta/release by default), and in that case some API
won't work even it's triggered from WebExtensions, but it should be fine.
2. GetKeyframesFromObject is executed in the caller's compartment to access
the passed-in JSObject that is keyframe, with iterable/iterator protocols.
This operation doesn't perform any GCThing allocation on the target window
global.
This change prevents URLs with wyciwyg schemes to be set as mDocumentURI.
Otherwise, in JS, document.URL returns a wyciwyg://* URL and a subsequent
call to document.write makes wycywyg URL visible in the address bar.
MozReview-Commit-ID: BaKpDkkIYbM
--HG--
extra : rebase_source : cc14c247e4aaa43645481cbc520040eacbba6e21
When the window is destroyed in unload event callbacks for the previous
document, we haven't started loading, i.e. we haven't called BlockOnload()
for the new document in nsContentSink::WillBuildModelImpl, so if we called
nsDocument::StopDocumentLoad() in such cases, UnblockOnload calls will mismatch
BlockOnload calls.
MozReview-Commit-ID: HjLtmGGvXKS
--HG--
extra : rebase_source : 8d81afd5cd7988cb165d9fee5dcfbf5fbf702331
Remove redundant check already implied by earlier condition: If the focus
manager's focused content is in our document, all parent windows including the
root window must have their focused node set to non-null.
MozReview-Commit-ID: CryGb6mfczK
--HG--
extra : rebase_source : ed5c452f68b76a656512026b5d162d8782083c2c
The autofocus attribute on form elements forces layout in CheckIfFocusable.
To avoid unpleasant FOUCs, defer autofocus processing until frames are
constructed in PresShell::Initialize.
Resolve the race between nsAutoFocusEvent running and page load by checking the
readystate at time of event posting. Skip autofocus if the element moved to a
different window in the meantime.
MozReview-Commit-ID: 90jiJYJWmRg
--HG--
extra : rebase_source : f94b479075df3e37ec1a658d71596c03930bab92
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
Replace the one use of it with element.focus().
MozReview-Commit-ID: 5qK6yfyuRoY
--HG--
extra : rebase_source : f6f9a738c6ebf2201dbd6a2ac5fe476797e0adb5
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : df8a03e76eaf9cdc9524dbb3eb9035af237e534b
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
--HG--
extra : rebase_source : e9b117f5b9afec76e63d57ab8cd86dafb5873789
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
--HG--
extra : rebase_source : 1e3ed6fa36028f2883cc37b0f2f1ff1f0eb23fd4
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This is due to incomplete specification, see discussion on Chromium bug
https://bugs.chromium.org/p/chromium/issues/detail?id=418531
Behavior is now in line with Edge and Chromium.
MozReview-Commit-ID: AxIRtIj5j8r
--HG--
extra : rebase_source : 45c8016537259c7d7a2af6e8b8a9f5a25521e4c5
Since we are dealing with the element (nodeInfo->LocalName() and NameAtom() are the same value),
we could use nodeInfo->NameAtom() instead.
MozReview-Commit-ID: 4vIBDEM1Nwv
--HG--
extra : rebase_source : 150d5ea982363eb2ef4c5039fae67be1e08884ba
Everything that needs them up-to-date will call flush appropriately, there
should be no need to do it manually.
This way we coalesce all the stylist updates until the next style flush in the
best case, or until one of the consumers actually needs them.
MozReview-Commit-ID: BVsxXxhtcKL
--HG--
extra : rebase_source : a41c14689fdcdb30935e16bdb0e757e7140e88e7