There was some mistake in patch of bug 694696 which incorrectly added
'skip-if' for some unrelated test. This patch reverts those mistakes in
addition to just moving the test back.
It also attaches the "fullscreen" tag to the test as it triggers that.
MozReview-Commit-ID: 2PMX6PFZWm2
--HG--
extra : source : f51c8dd75753ce5ef7d171b74f3f39fbd55ed38d
Firefox no longer supports DSA cipher suites, so this telemetry is dead code.
MozReview-Commit-ID: G3ipd0TADM
--HG--
extra : rebase_source : 6cd2b10727107c048010d39b24e328f5539a7220
This makes a function call in XRE_InitChildProcess for the child process that
currently exists in XREMain::XRE_mainStartup for the parent process.
This allows signals that jprof uses to be sent to a child process to
profile that child process.
MozReview-Commit-ID: CeWnYl4LJyA
Requesting review from mak for the changes to PlacesUtils.jsm.
Note that one of these changes (toPRTime) is also present in the patch for bug 1265836, but I anticipate that this patch may land before that bug.
MozReview-Commit-ID: Kg1XX40A4FW
--HG--
extra : transplant_source : %05%FAB%CENp%BE%A3%A1C%C3%B8%E6%3E%939%9E%E8%A1%5C
We have data showing that the Places SQLite database can consume
gigabytes of I/O during Firefox test automation jobs. This is
because a number of tests load pages as rapdily as possible,
effectively stress testing Places and SQLite. As the SQLite
database is committed to, we incur I/O for the WAL journal
and when flushing/synchronizing commits. This can add up to a
lot of overhead, especially on spinning disks.
It is important for Places to run during many tests. But it
isn't necessarily important to run with robust I/O guarantees:
SQLite itself has tests that ensure different journal and
synchronizing modes work as advertised.
This commit introduces a preference that changes the SQLite
journal and synchronization modes to be less robust. We use
an in-memory journal so no I/O is incurred for journal writing.
We disable synchronization during commit so no expensive
file(system) flushing is performed. Because setting this
preference would be dangerous for end users, we only honor the
pref if a scary sounding environment variable is set. Hopefully
that's enough of an obstacle to prevent people from footgunning
themselves.
A preliminary Try run reveals this has the potential to shave
hundreds of megabytes of I/O from various jobs. Although this
commit stops short of changing the configuration in automation
to use the new volatile storage preference.
MozReview-Commit-ID: KCoDVzwkSbg
--HG--
extra : rebase_source : 4e630f4341fc8c07e16383480356bd1bff4d4ba2
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
(I'm not particularly keen on "Performance" as the label, but I can't
think of anything better right now.)
MozReview-Commit-ID: JrTCFYksX30
--HG--
extra : transplant_source : %00E%9ER%B9%29%D9%D3%01%16%A0%E0%A2N%F9%83%01%E5R%B0
