The "has been exposed to CSSOM" thing is a much weaker test, which was meant to
stand for "has been modified or might be modified". We don't care about the
"might be modified" bit anymore, since we don't share rules in that case.
Differential Revision: https://phabricator.services.mozilla.com/D55717
--HG--
extra : moz-landing-system : lando
But note that this is a bit arbitrary, maybe we should just make it a threshold
and the PiP stuff could pass 0.5 or something.
Differential Revision: https://phabricator.services.mozilla.com/D55370
--HG--
extra : moz-landing-system : lando
We need to ensure we have a unique inner so that ruleLists and such have the
right pointer identity (we could do better, really, but it's harder).
But as long as the CSSOM hasn't modified them there should be no reason not to
use the cache. We can do a deep clone synchronously instead of refetching /
reparsing.
This is important because, as of right now, just using the inspector makes the
stylesheets unique, which is unfortunate.
We'll still have the modified rule bit for sheets with @import, because our
notification system for @import is silly, and on parents of imported sheets.
Fixing those are future improvements, but I see no reason not to land this.
Differential Revision: https://phabricator.services.mozilla.com/D55163
--HG--
extra : moz-landing-system : lando
Using an array is much better to reason about than a manually linked list, and
allows us to preserve @import order.
Added a test for a bug that we happened not to have, but that it's not covered
by existing WPT tests.
Differential Revision: https://phabricator.services.mozilla.com/D55565
--HG--
extra : moz-landing-system : lando
Test is hopefully self-explanatory. The children setup here is a bit bogus as
noted here and other comments, will file a followup to clean it up.
Differential Revision: https://phabricator.services.mozilla.com/D55550
--HG--
extra : moz-landing-system : lando
The testcase doesn't have a fragmentainer at all so we should
never set Incomplete status in this case. I added an assertion
that would have caught this. I also made the baseline methods
deal with a null inner frame for good measure.
Differential Revision: https://phabricator.services.mozilla.com/D55389
--HG--
extra : moz-landing-system : lando
Bug 1594937 comment 2 provides an analysis on why it is OK to remove
css-multicol reftests.
The manual modifications in this patch are:
- Remove `os.path.join("css-multicol")` in import-tests.py.
- Remove css-multicol lines in failures.list
- Migrate geckoview only failures annotations (bug 1558509) in failures.list
to wpt ini files.
- Add fuzzy-if annotation to dom/tests/reftest/bug453105.html for Android.
(bug 1600534)
Others parts are generated by running import-tests.py on a wpt
repository with commit 15f199c91a72b0d51bf0a12b3b77827ecb5051ff.
Differential Revision: https://phabricator.services.mozilla.com/D52928
--HG--
extra : moz-landing-system : lando
Snapping glyph positions are an internal detail to a primitive. As such,
any snapping required must be taken into account when calculating the
local rect. That ensures that when the clip is applied, it doesn't cut
off parts of the glyph that would have been retained after snapping.
Differential Revision: https://phabricator.services.mozilla.com/D55348
--HG--
extra : moz-landing-system : lando
Have their own notification for when the child sheet loads instead of
piggy-backing in the RuleAdded one, and make the callers check instead.
This prevents incorrectly marking as modified sheets which only have @import
rules.
Differential Revision: https://phabricator.services.mozilla.com/D55184
--HG--
extra : moz-landing-system : lando
Using Rect() will work properly when mDrawTarget does not have 0,0
origin. It also makes the code's intention more clear.
Differential Revision: https://phabricator.services.mozilla.com/D55337
--HG--
extra : moz-landing-system : lando
We add the SideBits to the data we store in the FixedPosScrollTargetTracker. nsDisplayCompositorHitTestInfo then passes the side bits when it sets hit test info. We then pack the side bits into the hit test info bits; luckily they were only using 12 of 16 bits. The wr HitTest api then extracts the side bits from the hit test info bits and passes them back.
Differential Revision: https://phabricator.services.mozilla.com/D54404
--HG--
extra : moz-landing-system : lando
The plumbing from there to the HitTestingTreeNode is already in place for the non-webrender case.
Differential Revision: https://phabricator.services.mozilla.com/D54402
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
I couldn't repro this with the STR in the bug, but I can repro by inspecting a
grid in print preview, where we don't properly honor the re-reflow request
because $reasons.
Differential Revision: https://phabricator.services.mozilla.com/D55264
--HG--
extra : moz-landing-system : lando
Relatedly: We only use this to determine priority. It seems we prioritize
<link rel=preload> over <link rel=stylesheet>, is that intended?
That seems a bit weird, as the preloads from the parser are likely to be used
very soon.
Differential Revision: https://phabricator.services.mozilla.com/D55225
--HG--
extra : moz-landing-system : lando
This small change seems to help us come out on the good side of a race
condition that this test is failing on our Ubuntu 18.04 test runner platform.
Differential Revision: https://phabricator.services.mozilla.com/D54974
--HG--
extra : moz-landing-system : lando
Guard against flaky results from the remote is_file and reduce adb traffic
by waiting once for the log file to be created rather than checking for it
throughout the test run.
(Minor ride-along change to reftest.jsm resolves javascript error introduced
by bug 1575266.)
Differential Revision: https://phabricator.services.mozilla.com/D55026
--HG--
extra : moz-landing-system : lando
Lets Wayland sessions run vsync off wayland surface frame callbacks by creating
an interface for widgets to return a local VsyncSource, if applicable.
This interface is currently used for the compositor, and for refresh drivers
in the parent process. It is not yet used for vsync in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D28430
--HG--
extra : moz-landing-system : lando
It's a better name, and will avoid confusion when I add other stylesheet caches
outside of the CSS loader.
Depends on D54556
Differential Revision: https://phabricator.services.mozilla.com/D54557
--HG--
rename : layout/style/nsLayoutStylesheetCache.cpp => layout/style/GlobalStyleSheetCache.cpp
rename : layout/style/nsLayoutStylesheetCache.h => layout/style/GlobalStyleSheetCache.h
extra : moz-landing-system : lando
For avoiding unnecessary copy of string buffer only for comparing setting
value and current value, especially with `nsAutoString`, this patch
creates `*Equals()` methods for every class.
And also this avoids to call `nsContentUtils::PlatformToDOMLineBreaks()` in
most paths.
Differential Revision: https://phabricator.services.mozilla.com/D54331
--HG--
extra : moz-landing-system : lando
Sub classes of `nsITextControlElement` are only `HTMLInputElement` and
`HTMLTextAreaElement`. And both base class is
`nsGenericHTMLFormElementWithState`. Therefore, we can make
`nsITextControlElement` inherit `nsGenericHTMLFormElementWithState` and
make `HTMLInputElement` and `HTMLTextAreaElement` inherit
`nsITextControlElement`. Then, we can get rid of a lot of QI between
`nsINode`/`nsIContent`/`Element` and `nsITextControlElement` (and note that
some of them in a hot path).
Additionally, this patch renames `nsITextControlElement` to
`mozilla::TextControlElement`.
Differential Revision: https://phabricator.services.mozilla.com/D54330
--HG--
rename : dom/html/nsITextControlElement.h => dom/html/TextControlElement.h
extra : moz-landing-system : lando
For avoiding unnecessary copy of string buffer only for comparing setting
value and current value, especially with `nsAutoString`, this patch
creates `*Equals()` methods for every class.
And also this avoids to call `nsContentUtils::PlatformToDOMLineBreaks()` in
most paths.
Differential Revision: https://phabricator.services.mozilla.com/D54331
--HG--
extra : moz-landing-system : lando
Sub classes of `nsITextControlElement` are only `HTMLInputElement` and
`HTMLTextAreaElement`. And both base class is
`nsGenericHTMLFormElementWithState`. Therefore, we can make
`nsITextControlElement` inherit `nsGenericHTMLFormElementWithState` and
make `HTMLInputElement` and `HTMLTextAreaElement` inherit
`nsITextControlElement`. Then, we can get rid of a lot of QI between
`nsINode`/`nsIContent`/`Element` and `nsITextControlElement` (and note that
some of them in a hot path).
Additionally, this patch renames `nsITextControlElement` to
`mozilla::TextControlElement`.
Differential Revision: https://phabricator.services.mozilla.com/D54330
--HG--
rename : dom/html/nsITextControlElement.h => dom/html/TextControlElement.h
extra : moz-landing-system : lando
This way we get the correct values for start-up prefs in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D51061
--HG--
extra : moz-landing-system : lando
Bug 1594937 comment 2 provides an analysis on why it is OK to remove
css-multicol reftests.
The manual modifications in this patch are:
- Remove `os.path.join("css-multicol")` in import-tests.py.
- Remove css-multicol lines in failures.list
- Migrate geckoview only failures annotations (bug 1558509) in failures.list
to wpt ini files.
Others parts are generated by running import-tests.py on a wpt
repository with commit 15f199c91a72b0d51bf0a12b3b77827ecb5051ff.
Differential Revision: https://phabricator.services.mozilla.com/D52928
--HG--
extra : moz-landing-system : lando
It can return the root widget if the menu popup frame doesn't have a widget. None of the callers want this.
Differential Revision: https://phabricator.services.mozilla.com/D54258
--HG--
extra : moz-landing-system : lando
This patch adds a new field to the `plugin-crashed` event that holds the list
of additional minidumps associated with a crash report. The test
infrastructure is modified to use it which also fixes a race when processing
the .extra file. The reftest machinery has also been modified to take the new
field into account.
Differential Revision: https://phabricator.services.mozilla.com/D54107
--HG--
extra : moz-landing-system : lando
On Chrome, visual viewport resize event is fired repeatedly during dynamic
toolbar transitions and visual viewport height obtained by the VisualViewport
API is also changed, but in terms of layout the height value is never used
until the dynamic toolbar height reaches to zero or is changed from zero.
The height used at the time is the height for vh units when the toolbar height
reaches to zero and the ICB height when the toolbar height is changed from zero.
To do so, we need to have another visual viewport size in parallel to the
original one and use them depending on situations.
Differential Revision: https://phabricator.services.mozilla.com/D52338
--HG--
extra : moz-landing-system : lando
The dynamic toolbar transition doesn't affect on background tabs since to
switch tabs the dynamic toolbar should be restored to its original state (i.e.,
completely visible state).
Differential Revision: https://phabricator.services.mozilla.com/D52336
--HG--
extra : moz-landing-system : lando
This attribute is not expected to change often, so it seems fine to restyle the
whole subtree.
Bug 1598094 tracks further optimizations, should they be needed.
Differential Revision: https://phabricator.services.mozilla.com/D54034
--HG--
extra : moz-landing-system : lando
Some of the stuff, in particular inside GeckoBindings stuff should be
refactored to be less ugly and duplicate a bit less code, but the rest of the
code should be landable as is.
Some invalidation changes are already needed because we weren't matching with
the right shadow host during invalidation (which made existing ::part() tests
fail).
Pending invalidation work:
* Making exportparts work right on the snapshots.
* Invalidating parts from descendant hosts.
They're not very hard but I need to think how to best implement it:
* Maybe get rid of ShadowRoot::mParts and just walk DOM descendants in the
Shadow DOM.
* Maybe implement a ElementHasExportPartsAttr much like HasPartAttr and use
that to keep the list of elements.
* Maybe invalidate :host and ::part() together in here[1]
* Maybe something else.
Opinions?
[1]: https://searchfox.org/mozilla-central/rev/131338e5017bc0283d86fb73844407b9a2155c98/servo/components/style/invalidation/element/invalidator.rs#561
Differential Revision: https://phabricator.services.mozilla.com/D53730
--HG--
extra : moz-landing-system : lando
So we do it while we're still handling re-entrant changes for SVG, since SVG can
post change hints from UpdateOverflow().
Differential Revision: https://phabricator.services.mozilla.com/D12102
--HG--
extra : moz-landing-system : lando
Right now we post updates and it "works" because we prevent the UpdateOverflow
call if we're during reflow.
If this happens during styling however this is not sound (and it is not sound
in general and has caused badness in the past, as noted by the other
workarounds).
Make it sound by preventing to observe ancestors, and do it everywhere, removing
various ad-hoc hacks that were spread around elsewhere.
This changes expectations of two tests:
* clip-path-recursion-002.svg: Now we consider the inner clip-path reference
invalid. This matches WebKit and Blink, and I don't see any spec text
explicitly asking for our old behavior, so I just changed the test.
* element-paint-recursion.html: Changes the expectations of elements
referencing themselves via -moz-element(). Now it is invalid, instead of
painting ourselves once inside ourselves, which was a bit wild on its own.
Differential Revision: https://phabricator.services.mozilla.com/D53890
--HG--
extra : moz-landing-system : lando
At first I thought this was going to enable simplifications in the selector
parser (to simplify the attribute selector setup), but I couldn't end up
shrinking the layout enough.
However this should help with bug 1559076, which returns Option<Atom>, and it
was easy to write.
Differential Revision: https://phabricator.services.mozilla.com/D53766
--HG--
extra : moz-landing-system : lando
:ntim was about to add another widget-affecting property (pointer-events) to
menupopups to replace the mousethrough attribute, see bug 1597120.
But pointer-events is inherited, and thus changing pointer-events on any element
would cause a change list of length == the number of descendants of the element,
which is not amazing.
So I suggested using DidSetComputedStyle instead, as this is fairly
popup-specific, but we may as well be consistent and do the same everywhere.
This removes the code to handle the -moz-window-* properties on the root frame,
as I haven't seen any usage of them (we always set them in panel or menupopup).
Differential Revision: https://phabricator.services.mozilla.com/D53377
--HG--
extra : moz-landing-system : lando
These were useful when implementing forwarding, and forgot to send them
earlier.
Differential Revision: https://phabricator.services.mozilla.com/D53767
--HG--
extra : moz-landing-system : lando
This facilitates disabling APZ "live", such as when moving a tab from an APZ
window into a non-APZ window.
Depends on D51468
Differential Revision: https://phabricator.services.mozilla.com/D51469
--HG--
extra : moz-landing-system : lando
The changes to make the test harness avoid busy waiting with setTimeout(0)'s made this test fail on Android 8.0 debug webrender. In order to get an active layer the test tweaks a transform slightly that has no visual effect every 74 ms. This is necessary to test the bug as far as I can tell (I wrote the test). The test times out because MakeProgress never makes any progress, there is always an afterpaint pending or an after paint has fired and we need to update the canvas for it. The painting and running through the settimeouts etc of the reftest harness take slightly too long. Before the changes to remove the busy waits we were just barely passing this test, it took 76 seconds in once instance that I checked and hundreds of iterations before we could make progress. Haven't debugged exactly why removing the busywaits makes this fail but it doesn't seem important.
Differential Revision: https://phabricator.services.mozilla.com/D52650
--HG--
extra : moz-landing-system : lando
With the fission changes everything is more async, meaning some tests can run longer. Some crashtests navigate to a new location meaning the original root element we have a variable for is no longer around, and chrome isn't allowed to keep content nodes alive, so we are left holding a dead wrapper that throws if we try to access anything on it.
So we check if contentRootElement has become a dead wrapper (and null it out) any time we try to access it and it could have become dead. Generally the existing code already handled a null contentRootElement.
Differential Revision: https://phabricator.services.mozilla.com/D52829
--HG--
extra : moz-landing-system : lando
I don't think this is strictly necessary but it lets us avoid a bunch of useless work, especially with webrender where these rects are always the full window size.
Differential Revision: https://phabricator.services.mozilla.com/D51346
--HG--
extra : moz-landing-system : lando
The code comment mostly explains the design. Basically, we force nothing to happen while we wait for the promises to finish and instead record what we need to do once the promise is finished, and do those pending tasks when it's finished.
Differential Revision: https://phabricator.services.mozilla.com/D51344
--HG--
extra : moz-landing-system : lando
This changes them to return a promise that resolves when the work is done, but we still need to change the callers to handle this new return type and do the right thing when these functions do their work async-ly.
To do this we add a JSWindowActor called ReftestFission. reftest-content.js communicates with this actor via reftest.jsm.
Differential Revision: https://phabricator.services.mozilla.com/D51343
--HG--
extra : moz-landing-system : lando
This means we no longer have any use for the frame state bit
"NS_STATE_FLEX_MEASUREMENTS_INTERRUPTED". Now, if a flex container
has N children and only the last child is interrupted, we'll only
purge the last child's measurement (and we'll do it promptly at the
end of the whole interrupted reflow).
Differential Revision: https://phabricator.services.mozilla.com/D53687
--HG--
extra : moz-landing-system : lando
We no longer have multiple kinds of anonymous subtrees, so we can get back one
node bit.
Differential Revision: https://phabricator.services.mozilla.com/D53344
--HG--
extra : moz-landing-system : lando
The changes to make the test harness avoid busy waiting with setTimeout(0)'s made this test fail on Android 8.0 debug webrender. In order to get an active layer the test tweaks a transform slightly that has no visual effect every 74 ms. This is necessary to test the bug as far as I can tell (I wrote the test). The test times out because MakeProgress never makes any progress, there is always an afterpaint pending or an after paint has fired and we need to update the canvas for it. The painting and running through the settimeouts etc of the reftest harness take slightly too long. Before the changes to remove the busy waits we were just barely passing this test, it took 76 seconds in once instance that I checked and hundreds of iterations before we could make progress. Haven't debugged exactly why removing the busywaits makes this fail but it doesn't seem important.
Differential Revision: https://phabricator.services.mozilla.com/D52650
--HG--
extra : moz-landing-system : lando
With the fission changes everything is more async, meaning some tests can run longer. Some crashtests navigate to a new location meaning the original root element we have a variable for is no longer around, and chrome isn't allowed to keep content nodes alive, so we are left holding a dead wrapper that throws if we try to access anything on it.
So we check if contentRootElement has become a dead wrapper (and null it out) any time we try to access it and it could have become dead. Generally the existing code already handled a null contentRootElement.
Differential Revision: https://phabricator.services.mozilla.com/D52829
--HG--
extra : moz-landing-system : lando
I don't think this is strictly necessary but it lets us avoid a bunch of useless work, especially with webrender where these rects are always the full window size.
Differential Revision: https://phabricator.services.mozilla.com/D51346
--HG--
extra : moz-landing-system : lando
The code comment mostly explains the design. Basically, we force nothing to happen while we wait for the promises to finish and instead record what we need to do once the promise is finished, and do those pending tasks when it's finished.
Differential Revision: https://phabricator.services.mozilla.com/D51344
--HG--
extra : moz-landing-system : lando
This changes them to return a promise that resolves when the work is done, but we still need to change the callers to handle this new return type and do the right thing when these functions do their work async-ly.
To do this we add a JSWindowActor called ReftestFission. reftest-content.js communicates with this actor via reftest.jsm.
Differential Revision: https://phabricator.services.mozilla.com/D51343
--HG--
extra : moz-landing-system : lando
It is a bit awkward to use raw MOZ_LOG directly, so I added FLEX_LOG()
to easily add `printf()` style logs.
"\n" is not need because MOZ_LOG() already appends one.
I hope it is OK to change the log module name to "FlexContainer". It's
shorter to type either by using
`MOZ_LOG=FlexContainer:debug ./mach run` or by setting
`logging.FlexContainer=debug` in [runprefs] section in `~/.mozbuild/machrc`
Differential Revision: https://phabricator.services.mozilla.com/D53299
--HG--
extra : moz-landing-system : lando
This is basically what we did in bug 1593171 (Protect against the same test from calling RecordResult more than once in the reftest harness) where we early exit in SendInitCanvasWithSnapshot.
But now we do it in SendUpdateCanvasForEvent too because SendUpdateCanvasForEvent calls SynchronizeForSnapshot which calls setupAsyncScrollOffsets and setupAsyncZoom, both of which get the documentElement of the current doc and operate on it. The problem is that this could be SendUpdateCanvasForEvent call from the previous test operating on the dom of the current test.
I haven't actually observed this, just noticed it while implementing checking of contentRootElement to make sure all cases are covered.
Differential Revision: https://phabricator.services.mozilla.com/D52827
--HG--
extra : moz-landing-system : lando
For the individual transform properties if they spec a value that can be
expressed as 2d we treat as 2d and serialize accordingly.
We drop Translate::Translate and Scale::Scale, and then rename
Translate::Translate3D as Translate::Translate, Scale::Scale3D as
Scale::Scale. So now we use Translate::Translate to represent 2d and 3d
translation, and Scale::Scale to represent 2d and 3d scale. There is no
difference between 2d and 3d translate/scale in Gecko because we always
convert them into 3d format to layers (on the compositor thread), so this
change makes things simpler.
Differential Revision: https://phabricator.services.mozilla.com/D52931
--HG--
extra : moz-landing-system : lando
This was a follow-up from the backplate stuff which I requested but didn't
happen.
Differential Revision: https://phabricator.services.mozilla.com/D53170
--HG--
extra : moz-landing-system : lando
It looked a bit weird after the XBL removal. Can be simpler and not use
GetBindingParent.
Differential Revision: https://phabricator.services.mozilla.com/D53062
--HG--
extra : moz-landing-system : lando
I'm not aware of any usage of LogicalPoint and LogicalPoint in frame
tree dump, but I still want to implement them for the sake of
completeness.
Differential Revision: https://phabricator.services.mozilla.com/D52965
--HG--
extra : moz-landing-system : lando
Note: The output format of BaseSize is "3 x 5", so a pair of parentheses
is added around %s in "logical-size=(%s)" to make it looks better.
Differential Revision: https://phabricator.services.mozilla.com/D52964
--HG--
extra : moz-landing-system : lando
This change uses parentheses, i.e. '(' and ')', to enclose the dimension
of LogicalRect. This match the output of BaseRect's operator<<.
Note: This introduces inconsistency in the frame tree dump because some
of the output format still use braces to enclose the data. But in later
patches, I'll gradually change the format to use parentheses.
Differential Revision: https://phabricator.services.mozilla.com/D52963
--HG--
extra : moz-landing-system : lando
WritingMode.h already depends on ostream header implicitly via
nsBidiUtils.h -> nsString.h. For completeness, I still add #include
<ostream>.
While I'm here, I make the format of debug prints in nsLineBox more
consistent with the counter-part in nsFrame. Some of them will be
revised in the later patches.
Differential Revision: https://phabricator.services.mozilla.com/D52962
--HG--
extra : moz-landing-system : lando
Though there is another call site of UpdateCompositionBoundsForRCDRSF in
nsLayoutUtils::CalculateRootCompositionSize, it's not clear to me whether it is
necessary or not since we early return from the function in the case where
|aIsRootContentDocRootScrollFrame| argument is true. We will audit it later
in bug 1562505.
Differential Revision: https://phabricator.services.mozilla.com/D53117
--HG--
extra : moz-landing-system : lando
Note that this FrameMetrics.mLayoutViewport doesn't represent exact size of
the layout viewport on the main thread, it means the maximum layout viewport
in future on the compositor thread once after the dynamic toolbar is completely
hidden. During the dynamic toolbar transition we don't update any information
on the main thread, which means it's possible that the visual viewport on the
compositor gets bigger than the layout viewport at the time when we send it
to the compositor thread, we have to avoid the situation.
Depends on D50419
Differential Revision: https://phabricator.services.mozilla.com/D50420
--HG--
extra : moz-landing-system : lando
Without this change, the junit test in this commit fail, the failure
rendered result is the area of the position:fixed element covered by
the dynamic toolbar before scrolling is rendered as blank.
Depends on D50418
Differential Revision: https://phabricator.services.mozilla.com/D50419
--HG--
extra : moz-landing-system : lando
Now
* nsPresContext::mVisibleArea is excluding the toolbar max height so that
ICB is now static regardless of the dynamic toolbar transition
* nsPresContext::mSizeForViewportUnits is introduced to resolve viewport units
which is including the toolbar max height
That means that with the dynamic toolbar max height;
mVisibleArea < mSizeForViewportUnits
See https://github.com/bokand/URLBarSizing for more detail backgrounds of this
change.
Depends on D50417
Differential Revision: https://phabricator.services.mozilla.com/D50418
--HG--
extra : moz-landing-system : lando
And deliver the value to the top content pres context, but it's not used in
this commit. The value will be used in the next commit.
One caveat is that areas covered by the dynamic toolbar will be outside
of the content area, which means implementers of GeckoView needs to call
setVerticalClipping with _negative_ values.
Depends on D50416
Differential Revision: https://phabricator.services.mozilla.com/D50417
--HG--
extra : moz-landing-system : lando
This adds two AUTO_PROFILER_LABEL_DYNAMIC_... macros and updates select
usages of the old macros to use the new ones. These new macros cause
the dynamic string of the label to be included in BHR stacks.
We don't want to do this all of the time, as in many cases we may not
be interested enough in the dynamic string or it may be sensitive
information, but it is rather important information for certain cases.
This uses the same buffer that we use for the strings for JS frames,
and if we fail to fit into that buffer we just append the raw label.
If the string is too long for our static buffer (128 bytes), we just
leave it truncated, as it should be stable and we may be able to infer
from the truncated form what the full form would be.
Differential Revision: https://phabricator.services.mozilla.com/D51665
--HG--
extra : moz-landing-system : lando
Other browsers don't, plus it blocks work I want to do to query multiple links
at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D52443
--HG--
extra : moz-landing-system : lando
Other browsers don't, plus it blocks work I want to do to query multiple links
at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D52443
--HG--
extra : moz-landing-system : lando
Per the spec, if multiple track sizes are given, the pattern is repeated as
necessary to find the size of the implicit tracks:
1. The first implicit grid track after the explicit grid receives the first
specified size, and so on forwards.
2. The last implicit grid track before the explicit grid receives the last
specified size, and so on backwards.
We use a positive index of the auto track sizes for (1) and a negative index
for (2), so we can apply the correct specified implicit size.
Differential Revision: https://phabricator.services.mozilla.com/D52265
--HG--
extra : moz-landing-system : lando
1. Use Nothing() for motion path in IncrementScaleResytleCountIfNeeded.
Since motion path only produces 2d translate and 2d rotate, so it
shouldn't have any impact on BaseMatrix::ScaleFactors(). We use
Nothing() to avoid any redundant calculation.
2. Drop SVGTextFrame::DidSetComputedStyle() because
nsFrame::DidSetComputedStyle() should have handled
ScheduleReflowSVGNonDisplayText well.
3. Let nsSVGForeignObjectFrame::DidSetComputedStyle() call
their parents' DidSetComputedStyle. This makes sure we update the frame
properly.
Differential Revision: https://phabricator.services.mozilla.com/D52290
--HG--
extra : moz-landing-system : lando
Other browsers don't, plus it blocks work I want to do to query multiple links
at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D52443
--HG--
extra : moz-landing-system : lando
Consider the following case:
<image style="list-style-image: url(foo.png)"></image>
image.style.MozAppearance = "something"
The early return was preventing us from clearing the image.
This is an ancient bug, but it has started happening in the browser chrome
because the lack of lazy frame construction for XUL elements makes us construct
elements with an outdated style, which means in this case that they wouldn't
have the -moz-appearance rule applied yet.
Differential Revision: https://phabricator.services.mozilla.com/D52112
--HG--
extra : moz-landing-system : lando
When browser.xhtml switches to an <html> root element, the frame structure
changed and caused performance regressions on talos for tart and tresize.
browser.xhtml doesn't need scrolling, so we can disable it and keep performance
on par with XUL <window>.
Differential Revision: https://phabricator.services.mozilla.com/D50675
--HG--
extra : moz-landing-system : lando
It's possible to have a fixed offset-path together with other animating
css transform properties or offset-* properties, so we have to update
this assertion.
Differential Revision: https://phabricator.services.mozilla.com/D52296
--HG--
extra : moz-landing-system : lando
Consider the following case:
<image style="list-style-image: url(foo.png)"></image>
image.style.MozAppearance = "something"
The early return was preventing us from clearing the image.
This is an ancient bug, but it has started happening in the browser chrome
because the lack of lazy frame construction for XUL elements makes us construct
elements with an outdated style, which means in this case that they wouldn't
have the -moz-appearance rule applied yet.
Differential Revision: https://phabricator.services.mozilla.com/D52112
--HG--
extra : moz-landing-system : lando
When browser.xhtml switches to an <html> root element, the frame structure
changed and caused performance regressions on talos for tart and tresize.
browser.xhtml doesn't need scrolling, so we can disable it and keep performance
on par with XUL <window>.
Differential Revision: https://phabricator.services.mozilla.com/D50675
--HG--
extra : moz-landing-system : lando
Seems less gnarly than the alternatives, and we'd only free it until shutdown so
not much worse, actually.
Differential Revision: https://phabricator.services.mozilla.com/D51871
--HG--
extra : moz-landing-system : lando
The existing code wasn't sound, as CSSOM objects also needed to go away before
the shared memory goes away (as they keep references to them).
This is sound assuming no presence of reference cycles introduced by CSSOM.
We may want to live with this and rely on chrome code not writing cycles like
this with UA stylesheet DOM objects.
We could explicitly drop all potentially-static objects... That seems pretty
error prone though.
Or we could also just leak the shared memory buffer, is there any reason why we
may not want to do that?
Differential Revision: https://phabricator.services.mozilla.com/D51870
--HG--
extra : moz-landing-system : lando
This turned out not to be the culprit, but it doesn't seem unreasonable for
DropAllRules -> DropRules -> cycle-collection-stuff that ends up reentering in
the parent rule list.
It seems safer to first remove from the array / move the array to the stack,
then free the pointer, than to leave dangling pointers while we iterate through
the array.
Differential Revision: https://phabricator.services.mozilla.com/D51869
--HG--
extra : moz-landing-system : lando
In most cases, we run an animation on an object by changing its
offset-distance/offset-rotate, but keep its offset-path the same.
Building and flattening the path is sometime expensive, especially for
large path, so caching it makes sense to us and have a significant
performance improvement. This is for the main thread motion path
animations.
Note: Even though we support compositor animations for motion path,
nsIFrame::GetTransformMatrix() is still called during the animations for
other usages, so we may still build the gfx::Path on the main thread
without this patch, so this improvement becomes necessary for most cases.
Differential Revision: https://phabricator.services.mozilla.com/D46667
--HG--
extra : moz-landing-system : lando
This was generated with:
```
rg -l -g '*.{cpp,h}' MOZ_XBL . | while read FILE ; do
echo $FILE
unifdef -m -UMOZ_XBL $FILE
done
```
After this, I manually removed the directive in nsContentUtils.cpp due to:
unifdef: ./dom/base/nsContentUtils.cpp: 4630: Unterminated string literal
unifdef: Output may be truncated
Differential Revision: https://phabricator.services.mozilla.com/D51337
--HG--
extra : moz-landing-system : lando
So, we don't create a stacking context for this case. Besides, we also
make sure FindAnimationsForCompositor() work properly for motion-path if
offset-path is not effective (i.e. none and no animations).
Differential Revision: https://phabricator.services.mozilla.com/D51895
--HG--
extra : moz-landing-system : lando
But don't hook it into style yet, that'll be a follow-up patch.
I had this patch in my local queue for a bit and there was no point in not
landing it I guess.
The value of this attribute could be stored only in the shadow root (as this
only applies to shadow hosts), but that would make invalidation harder, I think,
so do the obvious thing for now.
Differential Revision: https://phabricator.services.mozilla.com/D51963
--HG--
extra : moz-landing-system : lando
The previous code tried to do it, but it did it wrongly, as the overflow clip
comes from the parent, not the child.
Thus when we change a style that influences it, we weren't invalidating the
SIMPLE_DISPLAY_LIST bit, and such.
Make the reftest that caught this fail more reliable.
Differential Revision: https://phabricator.services.mozilla.com/D51805
--HG--
extra : moz-landing-system : lando
This fixes css/css-contain/contain-paint-{002,012,024}.html when not using the
fast path (i.e., with the following patch).
Also invert the check in IsStackingContext as IsFrameOfType is a virtual method,
and IsContain* is just a bitflag.
Differential Revision: https://phabricator.services.mozilla.com/D51804
--HG--
extra : moz-landing-system : lando
Update the comments, name, and fields to show it is agnostic of isize/bsize.
Differential Revision: https://phabricator.services.mozilla.com/D51739
--HG--
extra : moz-landing-system : lando
Now that there is no Gecko-contributed background color in the window any more,
there's nothing that needs to be cleared away. This simplifies things.
Differential Revision: https://phabricator.services.mozilla.com/D51464
--HG--
extra : moz-landing-system : lando
For regular elements, whenever -moz-appearance is used, the CSS background is
ignored. Root elements were behaving specially, and the background color also
needed to be adjusted.
For example, for Windows 7, we have the following CSS rule;
```
:root {
background-color: transparent;
-moz-appearance: -moz-win-borderless-glass;
}
```
This change makes the root element more consistent with other elements, so the
extra `background-color: transparent` declaration is no longer necessary.
This change does not let content documents opt out of forced opaqueness:
Root content documents still get an opaque background color from an existing
check further down in this method.
Differential Revision: https://phabricator.services.mozilla.com/D51459
--HG--
extra : moz-landing-system : lando
Accept assertions to avoid intermittent test failures due to assertion count mismatches.
Differential Revision: https://phabricator.services.mozilla.com/D50660
--HG--
extra : moz-landing-system : lando
This distinguishes better between the overloaded aspect of the PerFrameKey and the
actual mixed value.
Depends on D37803
Differential Revision: https://phabricator.services.mozilla.com/D37804
--HG--
extra : moz-landing-system : lando
This static method is assumed to have the same signature as the type's constructor,
and so we must have an implementation of ComputePerFrameKey for each constructor
a display item provides that is called by MakeDisplayItem. Notably this excludes
the MakeClone constructor for a lot of items.
There is a default varargs implementation on nsDisplayItem which everyone
inherits by default, so types which previously didn't overload this method
still don't need to.
Providing an implementation of ComputePerFrameKey on some display item type
shadows the varargs implementation, so one doesn't need to worry about overloading
one constructor but forgetting about another -- if you do, the compiler will only
see the overload and complain that the signature doesn't match.
One slightly annoying result of this is that display items which previously
inherited an overloaded implementation from a superclass now must provide
their own manual implementations. Although as far as I could tell, all of
those cases had a trivial implementation of key=0 (the super class supported
custom keys but the subclasses didn't make use of it).
In those cases I just hardcoded key=0, but it's possible that it would be
better to call into the superclass' implementation to be more robust to changes.
Differential Revision: https://phabricator.services.mozilla.com/D37803
--HG--
extra : moz-landing-system : lando
Add test annotations to the ReftestManifest and TestResolver. For example, a
test description from the TestResolver might now contain 'skip-if': 'skiaContent';
similar to the content provided for manifestparser tests; this will allow
'mach test-info report' to filter tests based on reftest manifest test
annotations.
Also add the referenced-test field which identifies the test file associated
with test entries for reference files; this will allow test-verify to
run the correct reftest when only the reference file has been modified.
Differential Revision: https://phabricator.services.mozilla.com/D51113
--HG--
extra : moz-landing-system : lando
The glyph pixel space in which we rasterized glyphs differed from how we
rendered the rasterized glyphs in the shader. They need to be in
agreement because the glyph subpixel offset selected during
rasterization depends on it. This patch should make the paths consistent
with each other.
Additionally, during animations, we now snap the reference frame
relative offset ignoring the impact of any animated transforms. This
helps with minimizing glyph wiggling during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D51305
--HG--
extra : moz-landing-system : lando
When blobs were lazily rasterized it was relatively cheap to create very large blob layers. Now that we move to pre-rasetrizing all blob tiles during scene building, large blob layers cause excessive memory allocation and CPU usage.
Differential Revision: https://phabricator.services.mozilla.com/D51576
--HG--
extra : moz-landing-system : lando
This way we get the correct values for start-up prefs in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D51061
--HG--
extra : moz-landing-system : lando
A speculative fix for intermittent android reftest failures in which the reftest log file
is incomplete but the missing logging is found in the logcat: I hope that closing the
log file explicitly will ensure logging is flushed before the application quits.
Differential Revision: https://phabricator.services.mozilla.com/D51695
--HG--
extra : moz-landing-system : lando
Some crashtests call window.location.reload one or more times. Each time the test document loads we call OnDocumentLoad, and each call of that function can lead to a RecordResult call, either directly or indirectly through WaitForTestEnd and its MakeProgress state machine.
Although the error when this happens ("program error managing timeouts") is confusing I found a couple intermittent instances of this happening in our bugzilla.
However with the fission changes to the reftest harness (which in general make things more async) this is much more common because we keep the tests alive longer before tearing down the test page, giving it more of a chance to happen.
To fix it we pass around the top level test url so it can make its way to RecordResult. This means we can ignore RecordResult calls for previous tests, and ignore the second or more RecordResult call for the current test. We reset the count when we start a new test.
Differential Revision: https://phabricator.services.mozilla.com/D51342
--HG--
extra : moz-landing-system : lando
nsPrintData::mBrandName never changes over the lifetime of a Firefox instance.
It is wasteful to have nsPrintData obtain and store it, since we can replace
an nsPrintJob's nsPrintData object multiple times over the lifetime of the
nsPrintJob and nsPrintJob is the only consumer.
Differential Revision: https://phabricator.services.mozilla.com/D51689
--HG--
extra : moz-landing-system : lando
The previous code tried to do it, but it did it wrongly, as the overflow clip
comes from the parent, not the child.
Thus when we change a style that influences it, we weren't invalidating the
SIMPLE_DISPLAY_LIST bit, and such.
Make the reftest that caught this fail more reliable.
Differential Revision: https://phabricator.services.mozilla.com/D51683
--HG--
extra : moz-landing-system : lando
Spoof dom/dom.properties, layout/xmlparser.properties,
layout/MediaDocument.properties to en-US if needed.
Differential Revision: https://phabricator.services.mozilla.com/D46034
--HG--
extra : moz-landing-system : lando
Spoof dom/dom.properties, layout/xmlparser.properties,
layout/MediaDocument.properties to en-US if needed.
Differential Revision: https://phabricator.services.mozilla.com/D46034
--HG--
extra : moz-landing-system : lando
Currently, "input" event is fired when the `AutoScriptBlocker` in `SetValue()`
is deleted. So, for keeping same behavior, the post processing after calling
`TextEditor` methods should be done before editor dispatches "input" event.
Fortunately, `TextInputListener::OnEditActionHandled()` is a good chance to
do that. Therefore, this patch makes it notify `TextControlState` and
`AutoTextControlHandlingState`.
Note that ideally, each method of `TextEditor` should return
`NS_ERROR_OUT_OF_MEMORY` coming from
`AutoTextControlHandlingState::OnEditActionHandled()`. However, it requires
a lot of changes in editor classes, and the case is really rare since editor
does not use fallible allocation. Therefore, it must be okay to crash in
editor if `OnEditActionHandled()` returns `NS_ERROR_OUT_OF_MEMORY`.
Depends on D51395
Differential Revision: https://phabricator.services.mozilla.com/D51396
--HG--
extra : moz-landing-system : lando
It should be in `mozilla` namespace and it manages not only `TextEditor`,
manages selection, selection controller and callback from editor. so that
I think it stores state of "text control widget". Therefore, I name it to
`TextControlState`.
And cleaning up the cpp file.
Differential Revision: https://phabricator.services.mozilla.com/D51391
--HG--
rename : dom/html/nsTextEditorState.cpp => dom/html/TextControlState.cpp
rename : dom/html/nsTextEditorState.h => dom/html/TextControlState.h
extra : moz-landing-system : lando
Previously, WR needed to update and track dependencies for all
allocated picture cache tiles in the virtual display port. This
means doing extra CPU work (dependency updates) and in some cases,
extra GPU work (larger off-screen child surfaces) than are strictly
required.
With this patch, each tile determines if it is currently visible in
pre_update. If the tile isn't visible, we skip doing dependency
updates until it is on screen again. More importantly, this is
used to reduce the world culling rect for primitive preparation,
which also means large child surfaces only require allocations
large enough to enclose the visible tiles, rather than the
display port.
Differential Revision: https://phabricator.services.mozilla.com/D51006
--HG--
extra : moz-landing-system : lando
Split off of Bug 1590894
Rename these to support unprefixed version
Also add alias to keep compatibility
Differential Revision: https://phabricator.services.mozilla.com/D50989
--HG--
extra : moz-landing-system : lando
In common cases where the caret is in a position:static frame subtree,
the caret's position (relative to canvas frame's custom content
container) should not be changed during scrolling.
However, when the caret is in a position:fixed or "stuck"
position:sticky frame subtree, the caret's position will change during
scrolling. We need to disable APZ to avoid jumpy carets.
Differential Revision: https://phabricator.services.mozilla.com/D51351
--HG--
extra : moz-landing-system : lando
This is the main patch to fix bug 1526268.
It is wrong to use the cached rects relative to the root
frame (ViewportFrame) to detect whether AccessibleCaret's position is
changed or not, because it doesn't account the root scroll frame's
scroll offset.
The effect is that we always produce "PositionChangedResult::Changed"
when scrolling on position:static elements, but
"PositionChangedResult::NotChanged" on position:fixed elements.
This patch fixes this by using the rect relative to custom content
container, which is the actually rect to set caret's position, to check
whether the position is changed or not.
Note that even with this patch, the caret on "position:fixed" element is
still jumpy during scrolling due to APZ. Part 3 will fixed this.
Differential Revision: https://phabricator.services.mozilla.com/D51350
--HG--
extra : moz-landing-system : lando
The #text-overlay and #image child divs were "position: absolute" under
the main AccessibleCaret div. However, they don't necessary need to be
position:absolute to achieve the desired layout. We can make them normal
in-flow elements to simplify the frame structure. There should not be
any perceivable change to the user.
Also, AccessibleCaret's position can made more accurate by using float
CSS pixels when converting it from app unit.
Differential Revision: https://phabricator.services.mozilla.com/D51349
--HG--
extra : moz-landing-system : lando
This is not an error in the same way as a download failure, and should not be reported as one.
An Info message is sufficient.
Also suppress "unknown" location in messages about @font-face rules, as it is not useful,
pending a proper fix (bug 1450903).
Differential Revision: https://phabricator.services.mozilla.com/D50346
--HG--
extra : moz-landing-system : lando
Lots of these callbacks have a non-`void*` final parameter, which UBSAN
complains about. This commit changes them to have a `void*` parameter.
This requires undoing the machinery added in the first two commits of bug
1473631: `TypePrefChangeFunc` and `PREF_CHANGE_METHOD`. The resulting code is
simpler (which is good) and more boilerplate-y (which is bad) but avoids the
undefined behaviour (which is good).
Differential Revision: https://phabricator.services.mozilla.com/D50901
--HG--
extra : moz-landing-system : lando
We cache the path in AnimationInfo for layers, and in
CompsoitorAnimationStorage for web-renderer.
Differential Revision: https://phabricator.services.mozilla.com/D50013
--HG--
extra : moz-landing-system : lando
This also includes the implementation of SetAnimatable, FromAnimatable,
and merge the final matrix with motion path.
Besides, we always use PathBuilderSkia for calculating the gfx::Path for
web-renderer.
Differential Revision: https://phabricator.services.mozilla.com/D50011
--HG--
extra : moz-landing-system : lando
We need to pass these two types into the compositor, so we need a better
way to serialize these rust types. We use serde and bincode to
serialize/deserialize them, and use ByteBuf to pass the &[u8] data
through IPC. We define StyleVecU8 for FFI usage only.
Differential Revision: https://phabricator.services.mozilla.com/D50688
--HG--
extra : moz-landing-system : lando