* partially-out-of-view-animation.html
This test is a normal test case (i.e. a trivial one). An animation on an
element which is partially out of the view. If ofscreen optimization
is totally broken, this test will fail.
* in-visibility-hidden-animation-pseudo-element.html
This test checks animation on visible pseudo element which is attached to
invisible element is not throttled.
* in-visibility-hidden-animation.html
This test checks animation on visible element which is inherited from
invisible parent element is not throttled.
This can be used in the implementation of shape-outside.
MozReview-Commit-ID: C7bd4D2Kwpm
--HG--
extra : rebase_source : fefdd869b1ede3c518e496d8b25ffa5953a7145d
This patch also removes the earlier workaround added in bug 1272525.
MozReview-Commit-ID: HR2wF2BGsKl
--HG--
extra : rebase_source : b561f8721d91c930bced7664f11a331552b97a5e
extra : histedit_source : d57e430f76851ce252416aa77fdaad0897d03756
Note that we do this here instead of when we suspend timeouts, because it makes
it simpler to handle situations in which a window's document changes while
things are suspended/blocked.
The nsDocumentViewer.cpp is not strictly needed, but avoids some extraneous
calls to SuppressEventHandling with a 0 suppression count.
In nsIFrame::BuildDisplayListForChild for certain types of frames we create wrap list items to wrap the constructed display list to make those items inseperable.
We were using the current scroll clip by default when creating these items, but that scroll clip may not contain all the content in the display list if we traversed into an out of flow frame whose containing block is an ancestor of the current frame. The CurrentAncestorScrollClipForStackingContextContents keeps track of exactly this. (Its name might be a little misleading as we may not be dealing with a true stacking context here. Nevertheless it does contain the correct clip.)
Maybe<nscolor> ensures that correct value is returned and also makes the
error checking clearer than using a out param.
MozReview-Commit-ID: 39uHIFCZzqn
--HG--
extra : rebase_source : 1885906646ebc9739c86aecb2b8e4bd0ee02e97f
layout/svg/SVGTextFrame.cpp:4198:28 [-Wshadow] declaration shadows a local variable
layout/svg/nsSVGClipPathFrame.cpp:388:18 [-Wshadow] declaration shadows a local variable
layout/svg/nsSVGIntegrationUtils.cpp:562:15 [-Wshadow] declaration shadows a local variable
layout/svg/nsSVGIntegrationUtils.cpp:586:26 [-Wshadow] declaration shadows a local variable
layout/svg/nsSVGIntegrationUtils.cpp:620:15 [-Wshadow] declaration shadows a local variable
--HG--
extra : rebase_source : d8652b0c6bc2532119f351d7b0dc860987b32677
This part removes the 'stretch' logic in AlignJustifySelf and implements
it in nsLayoutUtils::ComputeSizeWithIntrinsicDimensions /
nsFrame::ComputeSize instead.
And mCharCode shouldn't be compared with NS_VK_*, nsIDOMKeyEvent::DOM_VK_*. Additionally, when it's compared with a character constant, cast isn't necessary.
MozReview-Commit-ID: JMT614copjG
--HG--
extra : rebase_source : 69ee3c589e5a71c814ec9a40ac3aab39c789c11d
And also WidgetKeyboardEvent::mKeyCode should be compared with NS_VK_* rather than nsIDOMKeyEvent::DOM_VK_*.
MozReview-Commit-ID: IKjQ1nr8XYe
--HG--
extra : rebase_source : 83125cd2523f6b70759f621470aad23b00aae8ae
This patch was generated by the command:
find * -type f -exec sed -i -f ../mozpropsub {} \;
in the root of the repository, with the file ../mozpropsub containing:
s/-moz-padding-end\>/padding-inline-end/g
s/-moz-padding-start\>/padding-inline-start/g
s/-moz-margin-end\>/margin-inline-end/g
s/-moz-margin-start\>/margin-inline-start/g
s/-moz-border-end\>/border-inline-end/g
s/-moz-border-end-color\>/border-inline-end-color/g
s/-moz-border-end-style\>/border-inline-end-style/g
s/-moz-border-end-width\>/border-inline-end-width/g
s/-moz-border-start\>/border-inline-start/g
s/-moz-border-start-color\>/border-inline-start-color/g
s/-moz-border-start-style\>/border-inline-start-style/g
s/-moz-border-start-width\>/border-inline-start-width/g
s/\<MozPaddingEnd\>/paddingInlineEnd/g
s/\<MozPaddingStart\>/paddingInlineStart/g
s/\<MozMarginEnd\>/marginInlineEnd/g
s/\<MozMarginStart\>/marginInlineStart/g
s/\<MozBorderEnd\>/borderInlineEnd/g
s/\<MozBorderEndColor\>/borderInlineEndColor/g
s/\<MozBorderEndStyle\>/borderInlineEndStyle/g
s/\<MozBorderEndWidth\>/borderInlineEndWidth/g
s/\<MozBorderStart\>/borderInlineStart/g
s/\<MozBorderStartColor\>/borderInlineStartColor/g
s/\<MozBorderStartStyle\>/borderInlineStartStyle/g
s/\<MozBorderStartWidth\>/borderInlineStartWidth/g
The diffs for the following files:
layout/style/nsCSSPropAliasList.h
layout/style/test/property_database.js
layout/style/test/test_value_computation.html
were then manually removed from the patch.
MozReview-Commit-ID: 8fbYnlZcn9U
This patch was generated by the command:
find . -name "*.css" -exec sed -i -f mozpropsub {} \;
in the root of a mozilla-central tree, with the file mozpropsub
containing the contents:
s/-moz-padding-end\>/padding-inline-end/g
s/-moz-padding-start\>/padding-inline-start/g
s/-moz-margin-end\>/margin-inline-end/g
s/-moz-margin-start\>/margin-inline-start/g
s/-moz-border-end\>/border-inline-end/g
s/-moz-border-end-color\>/border-inline-end-color/g
s/-moz-border-end-style\>/border-inline-end-style/g
s/-moz-border-end-width\>/border-inline-end-width/g
s/-moz-border-start\>/border-inline-start/g
s/-moz-border-start-color\>/border-inline-start-color/g
s/-moz-border-start-style\>/border-inline-start-style/g
s/-moz-border-start-width\>/border-inline-start-width/g
While I didn't manually review all the changes, I did review the list of
files, and manually reviewed the changes in the files that I thought
were more interesting.
Note that there are a few tests that should be fixed up as well, but
I'll do that in a later patch.
MozReview-Commit-ID: EiQTuuV0MNQ
What we have right now is not very usable, because you can only enable/disable
on the scriptable top of the window, but it's not at all obvious that this is
the case when using the API.
This adds a few basic tests for expectations of when we do and don't
restyle, construct frames, and reflow in response to changes of media
queries. They don't give us a lot of coverage, but often the tiny bits
of coverage at the beginning are the most useful.
In general, I'd like us to have more tests for specific optimizations,
i.e., for specific things that we expect not to happen in certain cases.
The elementsRestyled, framesConstructed, and framesReflowed getters on
DOMWindowUtils are a good way to make such measurements for a number of
things in layout; that's why I added them.
(Inspired a bit by bug 1259641.)
MozReview-Commit-ID: JFtlPO1eyoD
This is useful for writing tests that test particular optimizations,
such as that a particular operation doesn't cause restyles. It sits
next to similar counters for frames constructed and frames reflowed.
I also snuck in a preference for the less-expensive mPresContext over
the more expensive mFrame->PresContext() (which dereferences multiple
pointers).
(Originally written for work I planned to be part of bug 1189598.)
MozReview-Commit-ID: 8PN7nwLJG9r
This adds support for #rgba and #rrggbbaa colors to CSS. This feature
is specified in https://drafts.csswg.org/css-color-4/#hex-notation .
This adds new types to nsCSSValue so that we can serialize the syntax
that was specified, as we do for other distinctions in how colors are
specified.
It does not change the behavior of the hashless color quirk, which
continues to support only 3 and 6 digit colors as specified in
https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk (step 4).
This changes property_database.js to remove various uses of 4 and 8
digit colors as invalid values. It then adds them in slightly fewer
places as valid values, but more thoroughly testing both initial and
non-initial values on 'color'.
It marks two canvas tests explicitly testing this feature as no longer
known to fail by removing their .ini files.
Finally, it adjusts the web platform test testing the hashless color
quirk to no longer treat 4 and 8 digit colors with hashes as invalid
values. Removing the relevant test items seems like the right thing
since they're in a section where 3 and 6 digit colors were skipped but
other lengths were tested. Modifying this imported test is OK since:
<jgraham> dbaron: Commit the change you want to m-c, it is
(semi-)automatically upstreamed every so often (typically
about once a week)
MozReview-Commit-ID: IFq4HxaRkil
This patch tells all callers to use the existing behavior, so it is
intended not to change behavior. Callers that will be modified in later
patches are marked with "FIXME" comments that will be removed in those
later patches (patches 3 and 4).
MozReview-Commit-ID: FaLryfxaeHv
It was a cold Friday night in San Francisco. Earlier in the day, I
informed Chris AtLee that I was going to start focusing on improving
the efficiency of Firefox automation and asked him where the biggest
capacity issues were. He said "we're hurting most on Windows tests."
As I was casually drinking a barleywine (note to reader: barleywines
are serious beers - there's nothing casual about them), I found myself
tediously clicking through Treeherder looking at logs for Windows jobs,
looking for patterns and other oddities. As I was clicking through,
something stood out to me: the sheer number of reftest jobs. I
recalled a random project I started a few years ago. Its aim was to
analyze buildbot job metadata so we could better understand where time
was spent in automation. I had mostly written off the side project as
a failure and a near complete waste of my time. Not even a stray
random thought of this project had entered my mind in the past year.
But clicking through Treeherder after a few glasses of barleywine
somehow reminded me of one of the few useful findings of that project:
reftest jobs consumed a seemingly disproportiate amount of machine time,
something like 35 or 40% IIRC of the time spent on all jobs.
Now, this finding was several years ago and almost certainly no longer
relevant. But, again, I had a few glasses of barleywine in me and was
bothered by the amount of reftest jobs and their duration, so I thought
"hey, why don't I run reftests and see why they take so long." So I
built Firefox on Windows - the platform Chris AtLee said we're "hurting
most on."
I decided to start my very casual profiling session by recording a
`mach reftest` run using Sysinternals Process Monitor. To my surprise,
it yielded a very obvious and unexpected result: the Places SQLite
database was incurring a lot of I/O. On my i7-6700K Windows 10 desktop
with a high performance SSD, `mach reftest` yielded the following:
File Time #Events #Reads #Writes RBytes WBytes Path
198s 980,872 243,270 669,231 7,971,471,360 20,667,084,080 places.sqlite-wal
165s 645,853 222,407 367,775 7,287,701,820 14.071,529,472 places.sqlite
2s 377,121 1 0 32,768 0 places.sqlite-shm
The Places SQLite database accounts for 2,003,846 of the total of
3,547,527 system calls (56.49%) recorded by procmon during `mach
reftest` execution. This represents a staggering 49,997,786,732 of the
50,307,660,589 (99.38%) bytes of I/O recorded! Yes, that's 50 GB.
I reckon the reason the Places database accumulates so much I/O load
during reftests is because the reftest suite essentially loads thousands
of pages as quickly as possible. This effectively performs a stress
test against the Places history recording service.
As effective as reftests are at stress-testing Places, it adds no value
to reftests because reftests are testing the layout features, not the
performance of history recording. So these 2M system calls and 50 GB
of I/O are overhead.
This commit disables Places when executing reftests and prevents
the overhead.
After this commit, `mach reftest` has significantly reduced interaction
with the Places SQLite database:
File Time #Events #Reads #Writes RBytes WBytes Path
0.09s 502 138 302 4,521,984 8,961,528 places.sqlite-wal
0.07s 254 20 140 524,604 8,126,464 places.sqlite
0.01s 3,289 1 0 32,768 0 places.sqlite-shm
Of the 948,033 system calls recorded with this change (26.7% of
original), 691,322 were related to I/O. The Places SQLite database
only consumed ~22MB of I/O, <0.01% of original. It's worth noting that
~half of the remaining I/O system calls are related to reftest.log,
which now accounts for the largest percentage of write I/O (only
~53 MB, however). It's worth noting that reftest.log appears to be
using unbuffered writes and is requiring an excessive amount of
system calls for writing. But that's for another bug and commit.
In terms of wall time, the drastic I/O reduction during `mach reftest`
appears to have minimal impact on my machine: maybe 30s shaved from a
~900s execution, or ~3%. But my machine with its modern SSD doesn't
struggle with I/O.
In automation, it is a different story.
I pushed this change to Try along with the base revision and triggered
4 runs of most reftest jobs. The runtime improvements in automation
are impressive. Here are the fastest reported times for various jobs:
Job Before After Delta
Linux Opt R1 31m 34m +3m
Linux Opt R2 43m 35m -8m
Linux Opt Ru1 40m 34m -6m
Linux Opt Ru2 43m 37m -6m
Linux Opt R E10s 89m 72m -17m
Linux Debug R1 52m 40m -12m
Linux Debug R2 49m 42m -7m
Linux Debug R3 60m 51m -9m
Linux Debug R4 42m 37m -5m
Linux Debug R1 E10s 84m 72m -12m
Linux Debug R2 E10s 97m 85m -12m
Linux64 Opt R1 35m 24m -11m
Linux64 Opt R2 37m 26m -11m
Linux64 Opt Ru1 32m 29m -3m
Linux64 Opt Ru2 37m 26m -12m
Linux64 Opt TC R1 12m 10m -2m
Linux64 Opt TC R2 10m 7m -3m
Linux64 Opt TC R3 11m 9m -2m
Linux64 Opt TC R4 11m 9m -2m
Linux64 Opt TC R5 13m 11m -2m
Linux64 Opt TC R6 11m 9m -2m
Linux64 Opt TC R7 9m 8m -1m
Linux64 Opt TC R8 11m 10m -1m
Linux64 Opt TC Ru1 30m 25m -5m
Linux64 Opt TC Ru2 36m 27m -11m
OS X 10.10 Opt 31m 27m -4m
OS X 10.10 Opt E10s 26m 25m -1m
OS X 10.10 Debug 68m 55m -13m
Win7 Opt R 30m 28m -2m
Win7 Opt Ru 28m 26m -2m
Win7 Opt R E10S 29m 27m -2m
Win7 Debug R 85m 76m -9m
Win7 Debug R E10S 75m 65m -10m
Win8 x64 Opt R 29m 26m -3m
Win8 x64 Opt Ru 27m 25m -2m
Win8 x64 Debug R 90m 71m -19m
Android 4.3 API15 Opt R1 89m 71m -18m
Android 4.3 API15 Opt R2 78m 64m -14m
Android 4.3 API15 Opt R3 75m 64m -11m
Android 4.3 API15 Opt R4 74m 68m -6m
Android 4.3 API15 Opt R5 75m 69m -6m
Android 4.3 API15 Opt R6 91m 86m -5m
Android 4.3 API15 Opt R7 87m 66m -21m
Android 4.3 API15 Opt R8 87m 82m -5m
Android 4.3 API15 Opt R9 80m 66m -14m
Android 4.3 API15 Opt R10 80m 67m -13m
Android 4.3 API15 Opt R11 73m 66m -7m
Android 4.3 API15 Opt R12 105m 91m -14m
Android 4.3 API15 Opt R13 72m 59m -13m
Android 4.3 API15 Opt R14 82m 61m -21m
Android 4.3 API15 Opt R15 73m 62m -11m
Android 4.3 API15 Opt R16 79m 78m -1m
The savings total 6+ *hours* or ~15% when running all reftests. I'd
say this isn't bad for a one-line code change!
MozReview-Commit-ID: H1LkACgSpVn
--HG--
extra : rebase_source : 891a5ce8e1f6c3d70fc646f116c2f49f897ad735
We need to do this because the entire draw region will be added to the layer's
valid region after drawing. If there are parts in the valid region that are not
in the visible region, we still need those parts to have valid content, because
in a later frame the visible region may grow to include those parts.
MozReview-Commit-ID: 6zESYbPAmrx
--HG--
extra : rebase_source : 24078d1ff802e53a2eb8895d2c5ffd1fe9507f04
In the upcoming patch to disable logging, we're going to conditionally
turn MOZ_LOG_TEST into a constant false. But for this instance of
MOZ_LOG_TEST in nsPresContext, turning it into a constant means that
|log| becomes unused. Since |log| isn't used after this point, let's
move the |gfxPlatform::GetLog| call into the MOZ_LOG_TEST call, removing
the temporary variable, and making the compiler happy.
During shutdown, mozilla::services::GetObserverServie will return nullptr. So we should check it. Add another nullptr check
MozReview-Commit-ID: 9xBbltRatJF
--HG--
extra : rebase_source : a859de09f30eeba344c317aec4cf4ed2cce8da2b
extra : histedit_source : 325aba902eff367d046807e9be3a73ad3100ee67
I'm acting under the assumption that this is what's closest to what the
code does now, except without asserting in ~ErrorResult. It also seems
closest to what event listeners will do, both based on examining code
(EventListenerManager::HandleEventSubType, which I'm hoping is the right
code to look at, calls StealNSResult, and then stores it in a member
that's ignored by most callers) and based on testing (for both click
events, and for media query listeners with this patch, the exception
gets reported to the console as an unhandled exception). That said, I'm
not particularly well versed in the current error handling rules so I
may well be off here.
This code should presumably go away when we change this code to use
EventListeners in bug 1265622, so I don't think there's any spec that
covers this.
Without the patch, the mochitest hits the fatal assertion (after
reporting hitting the expected uncaught exception). With the
patch the test passes. (Tested locally.)
MozReview-Commit-ID: 5kxp6jzGzX8
--HG--
extra : transplant_source : n%B4%AE%99D%FB%B9NM%C0%A2%F0%D4%B7%8C%E7%DE4E%60
We use _pretty_path when specifying the targets of generated files, so
we need to use _pretty_path for the inputs as well. Otherwise make won't
know that they refer to the same file, and result in "No rule to make
target" errors.
MozReview-Commit-ID: JTdLFbkX1J0
Fieldsets break up their border so we need to disable the willPaintBorder optimization for them.
MozReview-Commit-ID: 2zmlxVRLIqe
***
--HG--
extra : rebase_source : 0735ea7651803769721d109d52ca83cddad65aa7
This has multiple benefits:
- It makes DLBI detection of background-position changes work for buttons.
- It makes background-attachment: fixed work for button backgrounds.
- It allows the willPaintBorder optimization to be used for button background
drawing, which reduces the background clip to not overlap with opaque borders.
The willPaintBorder optimization requires a change to the reftest 611574-2.html.
This reftest compares backgrounds to inset box shadows. Box shadows those don't
have a willPaintBorder optimization, so we'd get different results due to the
borders - inset box shadows will bleed through the rounded corner anti-aliasing
of the border, backgrounds won't any more. So we just turn off button borders
and cover the outer edges of the borders with an outline in that reftest.
MozReview-Commit-ID: Lvx2p5szjw7
***
Cover the antialiasing in 611574-2.html with a black outline.
MozReview-Commit-ID: IHC3B7Eq72j
--HG--
extra : rebase_source : 71ae376f482d14e55820879f28b37056e1b857bf
Theoretically we should do the same for nsTreeBodyFrame, but that frame type is
harder to detect and I'm not sure it's worth adding code to support updating
background-position on XUL trees.
MozReview-Commit-ID: 8HPT53MX6bO
--HG--
extra : rebase_source : 1e84e83616832debe8f6da394630a5a2e014e7df
