So what's going on here is that there are pseudo-elements that contain
stuff like content: "Note" or content: "Example".
So when you're searching for "entry", we find the `e`, and then all the
text nodes afterwards are of course in a different subtree... So we end
up ignoring them, but after having iterated through all the DOM first.
To avoid this, change a bit the code so that we check for different
blocks _before_ checking for different subtrees. There's no point to
keep matching once you're done with a block.
Differential Revision: https://phabricator.services.mozilla.com/D89365
Not really a fan of this, but I can't think of a better alternative
really... Ideas welcome :)
The main issue is that in bug 1662975 we made window.print() not return
until the user has closed the print / print preview dialog (as it is
needed for some use cases). This matches other browsers, too.
We use an nsAutoSyncOperation here, in order not to violate the
run-to-completion invariants, which turns off micro-tasks, timers,
etc... However we'd still want promises inside mozPrintCallback to
resolve and such, which is a bit contradictory. It is really awkward to
have this behavior change based on whether we have a print callback...
Differential Revision: https://phabricator.services.mozilla.com/D89298
Restrict to "loadable" URLs. Also exclude blob URLs.
Edgar,
This includes Marcos' fix. Apparently I can push revisions without commandeering it, so the last few are mine alone. What appears to have happened is that the fix bounced due to Windows builders not being configured to support sharing (I ran these locally and they pass). Including these as expected failures on Windows seems to work (I ran this on try, and missed a test, as you can see from history).
Try run here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3ebecf71d5732d4dc0438f4d7b714f94b881353a (I since added wss to the expected failures).
Differential Revision: https://phabricator.services.mozilla.com/D88371
Not really a fan of this, but I can't think of a better alternative
really... Ideas welcome :)
The main issue is that in bug 1662975 we made window.print() not return
until the user has closed the print / print preview dialog (as it is
needed for some use cases). This matches other browsers, too.
We use an nsAutoSyncOperation here, in order not to violate the
run-to-completion invariants, which turns off micro-tasks, timers,
etc... However we'd still want promises inside mozPrintCallback to
resolve and such, which is a bit contradictory. It is really awkward to
have this behavior change based on whether we have a print callback...
Differential Revision: https://phabricator.services.mozilla.com/D89298
As much as I hate nested event loops, I think we need to do it for this
case :)
Hopefully print() already assumes nested event loops can happen because
of the native dialog so it's already properly set up for this.
Differential Revision: https://phabricator.services.mozilla.com/D89254
As much as I hate nested event loops, I think we need to do it for this
case :)
Hopefully print() already assumes nested event loops can happen because
of the native dialog so it's already properly set up for this.
Differential Revision: https://phabricator.services.mozilla.com/D89254
CLOSED TREE
Backed out changeset d3d67293f115 (bug 1623413)
Backed out changeset 75ed1b8a5c67 (bug 1623413)
Backed out changeset 0eef32d6a454 (bug 1623413)
This patch was generated by running:
```
perl -p -i \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF8toUTF16\((.*)\);/\1CopyUTF8toUTF16(\3, \2);/;' \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF16toUTF8\((.*)\);/\1CopyUTF16toUTF8(\3, \2);/;' \
$FILE
```
against every .cpp and .h in mozilla-central, and then fixing up the
inevitable errors that happen as a result of matching C++ expressions with
regexes. The errors fell into three categories:
1. Calling the convert functions with `std::string::c_str()`; these were
changed to simply pass the string instead, relying on implicit conversion
to `mozilla::Span`.
2. Calling the convert functions with raw pointers, which is not permitted
with the copy functions; these were changed to invoke `MakeStringSpan` first.
3. Other miscellaneous errors resulting from over-eager regexes and/or the
replacement not being type-aware. These changes were reverted.
Differential Revision: https://phabricator.services.mozilla.com/D88903
This is a guess fix based on possible reason for the crash.
Use of AutoScriptBlocker would be one option too, but better to return as early as possible.
Differential Revision: https://phabricator.services.mozilla.com/D88808
This lets us include some extra flags in the MIME type that's used by the bytecode
cache. It also simplifies the XDR code a bit.
The approach is similar to Wasm's GetOptimizedEncodingBuildId.
Differential Revision: https://phabricator.services.mozilla.com/D88726
Before bug 1636728 this couldn't happen because print documents weren't
hosted in an <browser>. The presentation of documents that are being
printed should be managed by the print job.
We should, in fact, probably just make mDocument->IsStaticDocument() the
condition, or such.
Differential Revision: https://phabricator.services.mozilla.com/D88901
There are three cases,
- Move to inner OOP frame.
- Move to outer OOP frame.
- Move to an OOP frame that is in different sub-tree.
We could use common BrowserParent ancestor to determine which case is and
dispatch MouseExitFromWidget event with proper ExitFrom type.
Depends on D84748
Differential Revision: https://phabricator.services.mozilla.com/D84761
eTopLevel is reused in content process to indicates that the mouse leaves
the puppet widget rendering area, now we add a separated type, ePuppet, for it.
Differential Revision: https://phabricator.services.mozilla.com/D84748
The race occurs when the parent changes the owner process for a BC, but the
child does not know about it and proceeds to call SetCurrentInnerWindowId on a
BC it no longer owns. To fix this, in child process, whenever we call
SetCurrentInnerWindowId on a BC, check that the BC is in process and that the
docshell has not been notified about an upcoming process change.
Differential Revision: https://phabricator.services.mozilla.com/D87934
In process selection logic, ensure that we don't use the original URI for
about:blank and instead use the result principal. If the about:blank load has a
null principal, then revert to using the original URI.
Also, remove an extra about:blank load when an nsFrameLoaderOwner is changing
remoteness to prevent races.
Differential Revision: https://phabricator.services.mozilla.com/D85081
This patch enables sandboxed srcdoc loads to take place via DocumentChannel,
and adds mechanisms for enabling unsandboxed ones.
Both unsandboxed srcdoc, and in subsequent patches, about:blank, loads require
that the triggering principal and the principal to inherit point to the same
instance if the load takes place in the same process as where we are inheriting
those principals from. We save those principals on a target browsing context before
we load the URI, and later, when we are deserializing LoadInfoArgs into
LoadInfo in the content process, we retrieve the saved principals if the
current load identifier of the target BC matches the load identifier saved
along with the principals.
We also need to make sure that during a process switch for about:srcdoc load,
we don't use the original URI for about:srcdoc to determine the remote type and
instead we use channel's result principal.
Differential Revision: https://phabricator.services.mozilla.com/D85079
Even though the outer comes from the inner, and the inner always checks
HasActiveDocument(), that seems to be a bit of a lie, insofar
HasActiveDocument() only checks IsCurrentActiveWindow(), and that can
return true for an already-discarded page.
Throwing in this case seems acceptable.
Differential Revision: https://phabricator.services.mozilla.com/D88586
When destroying the DocGroup, it will most certainly have no documents
attached to it, which makes labelling them a strange thing to do. And
the event target in DocGroup would most certainly dispatch to release
on the main thread anyway, so switch to do that right away.
Differential Revision: https://phabricator.services.mozilla.com/D88538
Before applying this patch, `ContentMediaController` is per process, it might contains `ContentMediaControlKeyReceiver` coming from different browsing context, and we are not able to treat those receivers differently based on the browsing context they exist in.
The goal to change `ContentMediaController` per inner window is to allow us to have an ability to treat receivers in different browsing context with different operations without interering each other.
As the `ContentMediaController` control the media playback in web context, which life cycle is tight to the inner window, that is why I choose to create `ContentMediaController` on the inner window.
In addition, update the comment to make its up-to-date.
Differential Revision: https://phabricator.services.mozilla.com/D87142
There are three cases,
- Move to inner OOP frame.
- Move to outer OOP frame.
- Move to an OOP frame that is in different sub-tree.
We could use common BrowserParent ancestor to determine which case is and
dispatch MouseExitFromWidget event with proper ExitFrom type.
Differential Revision: https://phabricator.services.mozilla.com/D84761
eTopLevel is reused in content process to indicates that the mouse leaves
the puppet widget rendering area, now we add a separated type, ePuppet, for it.
Differential Revision: https://phabricator.services.mozilla.com/D84748
Previously, IsFocusable returned true on elements in print preview documents, but the element wouldn't accept focus.
This meant that when you tried to tab, focus would get stuck on the document.
Now, IsFocusable returns false.
Thus, tab doesn't try to stop on these elements and can move out of the document.
Differential Revision: https://phabricator.services.mozilla.com/D88000
Previously, IsFocusable returned true on elements in print preview documents, but the element wouldn't accept focus.
This meant that when you tried to tab, focus would get stuck on the document.
Now, IsFocusable returns false.
Thus, tab doesn't try to stop on these elements and can move out of the document.
Differential Revision: https://phabricator.services.mozilla.com/D88000
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
Previously, IsFocusable returned true on elements in print preview documents, but the element wouldn't accept focus.
This meant that when you tried to tab, focus would get stuck on the document.
Now, IsFocusable returns false.
Thus, tab doesn't try to stop on these elements and can move out of the document.
Differential Revision: https://phabricator.services.mozilla.com/D88000
Other engines also do this, but with my previous patch breaks it
(because we only hit print() on the print-content-viewer _after_ doing
the clone).
So move it before triggering all the machinery, and only for
window.print(). Given we didn't check this for print preview etc, I
think it's fine to carry on for user-triggered loads.
Trivial test-case (which I'm not quite sure how to turn into an
automated test...)
<!doctype html>
<h1>I do get printed but...</h1>
<script>
window.print();
</script>
<h2>Do I?</h2>
Note that this is broken with the new print preview UI already, this
fixes it.
Differential Revision: https://phabricator.services.mozilla.com/D87898
This centralizes our print and preview setup in nsGlobalWindowOuter so
that we never re-clone a clone, and so that we reuse the window.open()
codepath to create the browsing context to clone into.
For window.print, for both old print dialog / silent printing and new
print preview UI, we now create a hidden browser (as in with visibility:
collapse, which takes no space but still gets a layout box).
* In the modern UI case, this browser is swapped with the actual print
preview clone, and the UI takes care of removing the browser.
* In the print dialog / silent printing case, the printing code calls
window.close() from nsDocumentViewer::OnDonePrinting().
* We don't need to care about the old print preview UI for this case
because it can't be open from window.print().
We need to fall back to an actual window when there's no
nsIBrowserDOMWindow around for WPT print tests and the like, which don't
have one. That seems fine, we could special-case this code path more if
needed but it doesn't seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D87063
Do this by spinning the event loop until we've done the clone for
preview as appropriate.
This should be much less risky than finishing the previous patches
which would still be nice, but realistically landing them for 81 is not
going to happen.
This just returns without doing nothing in a couple cases, like when
there's already another modal dialog or such. That seems acceptable to
me, it's not clear what better way to do would be.
Differential Revision: https://phabricator.services.mozilla.com/D87484
With these changes, there are still a number of test failures when remote
object/embed is enabled, due to svg sizing and resource timing tests. In order
to land these changes before those features are fixed, it will be placed behind
a pref.
Differential Revision: https://phabricator.services.mozilla.com/D86582
By passing a weak reference back to the DocumentChannelParent into
DocumentLoadListener for object loads, we are able to handle process switching
loads by asking the content process to create a BrowsingContext, and delaying
the real process switch until it becomes available.
The load then completes as it would before, acting as a normal process-switching
subframe load.
Differential Revision: https://phabricator.services.mozilla.com/D86580
This adds a thread count for GC parallel tasks calculated from GC parameters
for a helper thread ratio and max helper thread count. It also adds one to
report the number of helper threads used for GC.
This is slightly complicated by the fact that the helper thread system is
per-process and there are potentially many JS runtimes in a process. I
disallowed setting these parameters from workers (i.e. child JS runtimes), but
there may be more than one non-worker JS runtime so this isn't perfect.
I had to swap the mutex order for the GC and helper thread locks. Whatever
reason they were the other way round seems to have gone and this order makes
more sense to me (I see the GC lock as being 'coarser' than the helper thread
lock).
Differential Revision: https://phabricator.services.mozilla.com/D86725
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
The assertion crash found by fuzzing is fixed after moving useraction state from
BrowsingContext to WindowContext, see bug 1611961.
Differential Revision: https://phabricator.services.mozilla.com/D85752
Instead of getting/setting the size on the view manager on a fullscreen
change, this updates the code to get/set the size on the content viewer, which
internally sets the size on the view manager. Doing this ensures that the
content viewer size is updated prior to the reflow, which is required for
the MobileViewportManager to update its internal notions of size and to update
the visual viewport properly.
Differential Revision: https://phabricator.services.mozilla.com/D87161
We run the widget initialization code regardless on bind, and some of it
doesn't deal with shadow roots being already populated.
Differential Revision: https://phabricator.services.mozilla.com/D86952
CLOSED TREE
Backed out changeset 17df14f0b129 (bug 1200896)
Backed out changeset 5d9e9bd12cd2 (bug 1200896)
Backed out changeset 7f016de8d52f (bug 1200896)
Create a new namespace `MediaControlService` to use those helper functions which is used to get the main controller related status.
Then, move those functions from `ChromeUtils` to `MediaControlService`, which give us two benefit. The first is that we can remove redudant test-only enum `MediaSessionPlaybackTestState`, the second is a pref-required work for bug1656398, to fix the build order error when exposing `MediaSessionPlaybackState` in the media controller's webidl.
Differential Revision: https://phabricator.services.mozilla.com/D86620
Calling `NotifyMediaFullScreenState()` is related with updating state on media controller, which is only used for media element. So it'd be better to move that into media element.
Differential Revision: https://phabricator.services.mozilla.com/D85513
This adds a thread count for GC parallel tasks calculated from GC parameters
for a helper thread ratio and max helper thread count. It also adds one to
report the number of helper threads used for GC.
This is slightly complicated by the fact that the helper thread system is
per-process and there are potentially many JS runtimes in a process. I
disallowed setting these parameters from workers (i.e. child JS runtimes), but
there may be more than one non-worker JS runtime so this isn't perfect.
I had to swap the mutex order for the GC and helper thread locks. Whatever
reason they were the other way round seems to have gone and this order makes
more sense to me (I see the GC lock as being 'coarser' than the helper thread
lock).
Differential Revision: https://phabricator.services.mozilla.com/D86725
Popup permissions initialized with the result of checking if the
constructing WindowContext's principal is allowed to open a popup. The
field is updated for all WindowContexts sharing a principal whenever
the popup permission for that nsIPrincipal changes.
Differential Revision: https://phabricator.services.mozilla.com/D86378
A new `BrowsingContext` field, `isActiveBrowserWindow`, has been added
to track the active browser window for the `:-moz-window-inactive`
pseudoclass. This field takes the place of
`nsPIDOMWindowOuter::mIsActive`.
With this change `:-moz-window-inactive` is now fission compatible.
Differential Revision: https://phabricator.services.mozilla.com/D86422
Right now they start with a FullyHidden() effect info, but with a
"visible" widget, and thus active docshell and so on.
That's no good :)
Differential Revision: https://phabricator.services.mozilla.com/D86364
Right now they start with a FullyHidden() effect info, but with a
"visible" widget, and thus active docshell and so on.
That's no good :)
Differential Revision: https://phabricator.services.mozilla.com/D86364
Starting a load from a link click, to a link with the 'download' attribute
doesn't cancel any existing loads (since it's known to be just a download, not a
navigation, so doesn't need to replace the existing one). But then we have two
DocumentChannels alive at the same time, on the same loadgroup, the loadgroup
copies flags from the old one to the download one, since they're different, and
triggers the assert about setting LoadFlags.
The download one shouldn't really be added to the loadgroup; the progress of the
download should NOT block the 'load' event of the existing navigation.
Differential Revision: https://phabricator.services.mozilla.com/D85964
Also, for changes in CSS declarations, like changing
cssRules[i].style.color or something, we end up avoiding a lot of the
work we were doing.
This page still trips us in the sense that they add a stylesheet, then
call getBoundingClientRect(), then insert more rules in the stylesheet,
which causes us to rebuild a lot of the cascade data.
We could try to detect appends to the last stylesheet on the list or
something I guess, and avoid rebuilding the cascade data in some cases.
Depends on D85615
Differential Revision: https://phabricator.services.mozilla.com/D85616
This should help catch and/or prevent any cases where we're creating a new
subframe at an unfortunate time during `BrowsingContext` or `WindowContext`
teardown.
Differential Revision: https://phabricator.services.mozilla.com/D85896
Right now they start with a FullyHidden() effect info, but with a
"visible" widget, and thus active docshell and so on.
That's no good :)
Differential Revision: https://phabricator.services.mozilla.com/D86364
The main point of this change is to not use TYPE_OTHER in `TryCacheLoadAndCompileScript()`,
for extra clarity, we're not using a catch-all TYPE_INTERNAL_SCRIPT.
This is why the changeset introduces a new type TYPE_INTERNAL_FRAME_MESSAGEMANAGER_SCRIPT
which in itself adds lots of changes to various files.
Differential Revision: https://phabricator.services.mozilla.com/D85977
AFAICT the spec says that these layout scrollbars that take up no layout space that scroll the visual viewport do affect the size of the visual viewport. (Double check this)
Most other users don't care about the size of these special scrollbars.
I left nsIDOMWindowUtils::getScrollbarSize unchanged (NB different from nsIDOMWindowUtils::getScrollbarSizes which is modified by this patch) because I'm less sure. I will file a followup about it.
Differential Revision: https://phabricator.services.mozilla.com/D85708
AFAICT the spec says that these layout scrollbars that take up no layout space that scroll the visual viewport do affect the size of the visual viewport. (Double check this)
Most other users don't care about the size of these special scrollbars.
I left nsIDOMWindowUtils::getScrollbarSize unchanged (NB different from nsIDOMWindowUtils::getScrollbarSizes which is modified by this patch) because I'm less sure. I will file a followup about it.
Differential Revision: https://phabricator.services.mozilla.com/D85708
The functionality has been fully subsumed by the new
initialBrowsingContextGroupId attribute, so it is no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D85653
This attribute will subsume the existing sameProcessAsFrameLoader attribute. It
works by specifying the BrowsingContextGroup which the initial BrowsingContext
in a <browser> should be created within.
Due to bug 1652144, all documents within the same BrowsingContextGroup with the
same remote type will be loaded in the same process, meaning that specifying
both "initialBrowsingContextGroupId" and "remoteType" will cause the initial
about:blank document to be loaded in a specific content process.
Differential Revision: https://phabricator.services.mozilla.com/D85650
I realized this was broken because feature policy was not accounting for
it (I fixed that in 79), but I _thought_ we weren't shipping
feature policy. It turns out we've been shipping it for a while (since 74),
so I'd rather remove support for it officially.
Differential Revision: https://phabricator.services.mozilla.com/D86191
The assertion crash found by fuzzing is fixed after moving useraction state from
BrowsingContext to WindowContext, see bug 1611961.
Differential Revision: https://phabricator.services.mozilla.com/D85752
In process selection logic, ensure that we don't use the original URI for
about:blank and instead use the result principal. If the about:blank load has a
null principal, then revert to using the original URI.
Also, remove an extra about:blank load when an nsFrameLoaderOwner is changing
remoteness to prevent races.
Differential Revision: https://phabricator.services.mozilla.com/D85081
This patch enables sandboxed srcdoc loads to take place via DocumentChannel,
and adds mechanisms for enabling unsandboxed ones.
Both unsandboxed srcdoc, and in subsequent patches, about:blank, loads require
that the triggering principal and the principal to inherit point to the same
instance if the load takes place in the same process as where we are inheriting
those principals from. We save those principals on a target browsing context before
we load the URI, and later, when we are deserializing LoadInfoArgs into
LoadInfo in the content process, we retrieve the saved principals if the
current load identifier of the target BC matches the load identifier saved
along with the principals.
We also need to make sure that during a process switch for about:srcdoc load,
we don't use the original URI for about:srcdoc to determine the remote type and
instead we use channel's result principal.
Differential Revision: https://phabricator.services.mozilla.com/D85079
Unlike other engine vendors, we process meta elements
at parser, instead of when they are inserted. This
leads some web compact issues.
This patch aligns us with other vendors.
Differential Revision: https://phabricator.services.mozilla.com/D84545
The abstract observer base classes are moved to a separate header file
nsRefreshObservers.h and the includes are adjusted accordingly.
Some method implementations are moved to the corresponding implementation files
to avoid the need to include the nsRefreshDriver.h file in the header.
Differential Revision: https://phabricator.services.mozilla.com/D85764
This should make it easier to get an XPCOM interface from a JSProcessActorChild
in the current process, when combined with the do_QueryActor overloads from p2.
Differential Revision: https://phabricator.services.mozilla.com/D84069
This changes the set of types which can be passed as the second argument to
do_QueryActor to ones which can be unambiguously converted to a JSActorManager,
and combines nsCOMPtr_helper implementations.
Differential Revision: https://phabricator.services.mozilla.com/D84067
This will let people get information about the process more easily.
remoteType can't be infallible because it is a ACString.
Differential Revision: https://phabricator.services.mozilla.com/D85776
We're going to stop supporting Flash plugin soon, and we won't update the related code anymore. So we can remove those related tests which blocks Fission.
Differential Revision: https://phabricator.services.mozilla.com/D85312
Safari returns an "Intel" User-Agent string (and "MacIntel" navigator.platform) on ARM64 macOS (presumably for web compat) and on iPadOS (so sites serve desktop page layouts). We should follow Safari's lead for Firefox on ARM64 macOS.
Note that I do not have an Apple Silicon DTK so I have not personally tested this change on ARM64 macOS. Based on visual inspection of our User-Agent string code, I expect Firefox's current User-Agent string on ARM64 macOS is "Mozilla/5.0 (Macintosh; Mac OS X 10.16; rv:80.0) Gecko/20100101 Firefox/80.0" (and navigator.oscpu is " Mac OS X 10.16"). Note the missing "Intel" and extra space before "Mac OS X".
Example webcompat breakage even in mozilla-central: the Octane JS benchmark assumes Firefox's macOS navigator.platform will never return any values other than "MacIntel" or "MacPPC":
https://searchfox.org/mozilla-central/rev/dcd9c2d2bc19d96d487825eb70c2333a4d60994e/js/src/octane/gbemu-part1.js#659-669
Differential Revision: https://phabricator.services.mozilla.com/D84912
This does the same thing that getBoundingClientRect() does, which is
what the spec asks for, and thus fixes the intersection ratio for split
inlines where the first continuation is empty for example.
Differential Revision: https://phabricator.services.mozilla.com/D85385
We now use the cached value of the shortcuts permission from
`WindowContext` if we cannot get a `Browser`. This will now work
when calling from a child where the top-level document is OOP.
Differential Revision: https://phabricator.services.mozilla.com/D84183
We now cache the shortcuts permission in a synced field on
`WindowContext`. This will allow checking the permission quickly and
without IPC when Fission is enabled and the top-level document is
in another process.
Differential Revision: https://phabricator.services.mozilla.com/D84182
CLOSED TREE
We don't need these macros anymore, for two reasons:
1. We have static analysis to provide the same sort of checks via `MOZ_RAII`
and friends.
2. clang now warns for the "temporary that should have been a declaration" case.
The extra requirements on class construction also show up during debug tests
as performance problems.
This change was automated by using the following sed script:
```
# Remove declarations in classes.
/MOZ_DECL_USE_GUARD_OBJECT_NOTIFIER/d
/MOZ_GUARD_OBJECT_NOTIFIER_INIT/d
# Remove individual macros, carefully.
{
# We don't have to worry about substrings here because the closing
# parenthesis "anchors" the match.
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_TO_PARENT)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_IN_IMPL)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_IN_IMPL)/)/g;
# Remove the longer identifier first.
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_TO_PARENT//g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM//g;
}
# Remove the actual include.
\@# *include "mozilla/GuardObjects.h"@d
```
and running:
```
find . -name \*.cpp -o -name \*.h | grep -v 'GuardObjects.h' |xargs sed -i -f script 2>/dev/null
mach clang-format
```
Differential Revision: https://phabricator.services.mozilla.com/D85168
We don't need these macros anymore, for two reasons:
1. We have static analysis to provide the same sort of checks via `MOZ_RAII`
and friends.
2. clang now warns for the "temporary that should have been a declaration" case.
The extra requirements on class construction also show up during debug tests
as performance problems.
This change was automated by using the following sed script:
```
# Remove declarations in classes.
/MOZ_DECL_USE_GUARD_OBJECT_NOTIFIER/d
/MOZ_GUARD_OBJECT_NOTIFIER_INIT/d
# Remove individual macros, carefully.
{
# We don't have to worry about substrings here because the closing
# parenthesis "anchors" the match.
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_TO_PARENT)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_IN_IMPL)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_IN_IMPL)/)/g;
# Remove the longer identifier first.
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_TO_PARENT//g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM//g;
}
# Remove the actual include.
\@# *include "mozilla/GuardObjects.h"@d
```
and running:
```
find . -name \*.cpp -o -name \*.h | grep -v 'GuardObjects.h' |xargs sed -i -f script 2>/dev/null
mach clang-format
```
Differential Revision: https://phabricator.services.mozilla.com/D85168
There's no correctness issue here, but the assertion is just wrong. For
the scrolling element we may get the root scrollable frame even though
the primary frame is null.
Differential Revision: https://phabricator.services.mozilla.com/D85160
When we create a static document for printing, we clone all elements,
including <link rel=localization>. This means that
LocalizationLinkAdded/Removed etc do run for these documents.
However these documents don't come from the parser, which means that
we do block layout, but TriggerInitialTranslation and such do not run.
So we leave a stray onload blocker that we wait for as of bug 1648064,
so we wait forever and that is obviously not good.
Prevent these documents from using l10n, so as to avoid the problematic
situation.
Differential Revision: https://phabricator.services.mozilla.com/D85038
We're returning offsets relative to the scroll target frame, which for
inputs and such is not the primary frame, and thus they never have
border or padding or what not.
Offsets should be relative to the primary frame however, so move the
rect appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D84919
This changes the UA widget setup (again). What is going on in this
test-case is that we have a marquee inside a video, two things that have
their own UA widget. Given how the code is currently written, the
runnable to attach and set up the marquee's widget is posted before than
the video one (which is potentially reasonable).
However that means that the marquee one runs before and flushes layout,
and catches the video in an inconsistent state (in the composed doc, but
without a shadow root). That in turn messes up reflow because
nsVideoFrame assumes stuff.
Rather than putting the attach / detach logic in script runners, just
run that bit synchronously, and post only the event async. I audited the
consumers of those events and it seems fine to me, they either already
deal with the possibility of the shadow root being already detached or
they don't care.
For teardown, none of the destructors of the UA widgets rely on the
shadow root being still attached to the element.
Differential Revision: https://phabricator.services.mozilla.com/D84487
I just tested it on Fenix nightly and it works great. It better do
actually, as most of the code is shared with find-in-page.
See bug 750051 for when this was blocked. I don't think that was
properly understood at the time, but at this point the divergence from
desktop seems gratuitous.
This has caused compat issues in the past.
Differential Revision: https://phabricator.services.mozilla.com/D84758
The NoValidContent type was added to detect cases where we needed to apply
default width the viewport. That approach is no longer needed, and this
enum can be removed, as well as the code that sets and checks that enum.
Differential Revision: https://phabricator.services.mozilla.com/D84447
Emilio Cobos Álvarez
David Teller
Dorel Luca
Bogdan Tara
Marcos Cáceres
Narcis Beleuzu
Andreea Pavel
Kagami Sascha Rosylight
Mihai Alexandru Michis
Nathan Froyd
Mirko Brodesser
Henri Sivonen
Bob Owen
Olli Pettay
Jonathan Watt
Edgar Chen
Jan de Mooij
Alphan Chen
Kris Maglione
Sylvestre Ledru
Anny Gakhokidze
Andreas Farre
Cosmin Sabou
alwu
James Teh
Hiroyuki Ikezoe
Masayuki Nakano
Joel Maher
Peter Van der Beken
Simon Giesecke
Stephen A Pohl
Kashav Madan
Honza Bambas
Razvan Maries
Sonia Singla
Nika Layzell
Jon Coppeard
Sean Feng
Kartikaya Gupta
longsonr
Farooq AR
Csoregi Natalia
Andrea Marchesini
Steven MacLeod
Frederik Braun
Dan Glastonbury
Timothy Nikkel
Butkovits Atila
John Dai
Cameron McCormack
Andrew McCreight
Sebastian Streich
Noemi Erli
Chris Peterson
Jeff Walden
Alexey Izbyshev
Brad Werth
Gijs Kruitbosch