As the H264 SanityTest uses a 132x132 videos to determine if the hardware decoder is working, we always use the software decoder for smaller videos.
MozReview-Commit-ID: 8VbZTiJO9mA
--HG--
extra : rebase_source : 20cf3ae8bf62709711ac0e76e348c6e28d678025
AMD incorrectly decode videos with a resolution that is less than 128x128, as such with the test failing we disable hardware decoding on those machines, even though other resolutions work well.
So we use a 132x132 video instead.
MozReview-Commit-ID: 80mk11CNsil
--HG--
extra : rebase_source : 3cdffbc30334e2704375d8da878fd79124fe2a05
We would like to be able to see if a given hang in BHR occurred
under high CPU load, as this is an indication that the hang is
of less use to us, since it's likely that the external CPU use
is more responsible for it.
The way this works is fairly simple. We get the system CPU usage
on a scale from 0 to 1, and we get the current process's CPU
usage, also on a scale from 0 to 1, and we subtract the latter
from the former. We then compare this value to a threshold, which
is 1 - (1 / p), where p is the number of (virtual) cores on the
machine. This threshold might need to be tuned, so that we
require an entire physical core in order to not annotate the hang,
but for now it seemed the most reasonable line in the sand.
I should note that this considers CPU usage in child or parent
processes as external. While we are responsible for that CPU usage,
it still indicates that the stack we receive from BHR is of little
value to us, since the source of the actual hang is external to
that stack.
MozReview-Commit-ID: JkG53zq1MdY
--HG--
extra : rebase_source : 16553a9b5eac0a73cd1619c6ee01fa177ca60e58
In bug 1356705, we switched scrollbox to use CSS smooth scroll when
the scrollbox is configured to scroll smoothly. This caused the tab
strip to scroll with a "pulse" when using the arrow scrollbuttons.
This is because we scroll by a single tab each time, as opposed to
scrolling by pixels.
This reverts part of bug 1356705 so that we use instant scrolling
instead of smooth scrolling in the scrollbuttons case, which returns
the original behaviour of the strip without the pulse.
MozReview-Commit-ID: D8QQ8kQ7AjM
--HG--
extra : rebase_source : 400f0085b4b914003bfb2a235d2c62bc0f53ab66
Adds index to moz_bookmarks.dateAdded for use by Highlights query for recent bookmarks.
MozReview-Commit-ID: 7Gs8H0kUij2
--HG--
extra : rebase_source : 23498bcde4faeeb116c534dc9e124429a86d3e14
Add helpers for shared adjusting limit, bookmarkGuid sub-SELECT, WHERE and params. More efficiently select https and correctly select bookmarks. Remove _addETLD, getHistorySize and getBookmarksSize. Allow for activity stream caller to customize more options.
MozReview-Commit-ID: Lj9AhoFJar
--HG--
extra : rebase_source : fb4bb13969b47c28c1a137075304efb23c254182
The issue occurs when nsITimer is fired earlier than the backoff time. In that
case, the update doesn't proceed and we never make another attempt because the
backoff update timer was oneshot.
We fix the issue in two ways:
- Add a tolerance of 1 second in case the timer fires too early.
- Set another oneshot timer whenever we are prevented from updating due to
backoff.
MozReview-Commit-ID: E2ogNRsHJVK
--HG--
extra : rebase_source : c81fa77934f6c39e1c5d07b19785a01546e02542
Acceptably-structured pings should render fine in about:telemetry and not
trigger the panic mode of "Just show them the JSON!" that happens when an
exception is thrown.
Two things caught here:
1: Environment section without addon subsection
2: subsection searches
MozReview-Commit-ID: 3Z0hud23XuD
--HG--
extra : rebase_source : 1ac8e8f0cc0c9fa77c9ad2adcd89e3ed31fc124c
This introduces an implementation of the clipboard.setImageData API.
I did not find any complete documentation about how copying and
pasting images is supposed to work in Firefox, so I added many lines
of documentation based on experimenting and reading the source code.
The implementation is very similar to the Add-on SDK's implementation,
save for one difference: The third parameter to setTransferData is 0
instead of -1. Its significance is elaborated in ext-clipboard.js.
The newly added tests serve the following purposes:
- Verification that clipboard.setImageData is working as expected.
There is no way to test that pasting in an external application
really works, so we just check whether Firefox recognizes the
special image data by pasting in a contentEditable area.
- Test coverage for reading clipboard data via the "paste" event and
using event.clipboardData to access the pasted data, because this is
the only way to read non-text data in a WebExtension extension.
MozReview-Commit-ID: Ldrx7LCIta2
--HG--
extra : rebase_source : f76fe85e5c9a525c159255c29698f4bdbdede8bc
The extension policy services uses atoms internally for permission names, so
using them directly rather than strings is considerably cheaper.
MozReview-Commit-ID: Io8EuOXHKVy
--HG--
extra : rebase_source : 577b4bdf7f899729e4cf92961a8e9e25bf886a72
Going through the extension policy service rather than using
WebExtensionPolicy objects directly adds a lot of unnecessary overhead to
common operations on extension principals, and also makes the code more
complicated than it needs to be.
We also use weak references to policy objects here, since principals should
ideally lose as much of their elevated privileges as possible once the
extension instance that created them has been destroyed (which is something we
couldn't handle easily when we simply tracked ID strings).
MozReview-Commit-ID: KDNvVdvLkIt
--HG--
extra : rebase_source : 1b567919d2461bd0315d1a7d89f330cbd585f579
The issue occurs when nsITimer is fired earlier than the backoff time. In that
case, the update doesn't proceed and we never make another attempt because the
backoff update timer was oneshot.
We fix the issue in two ways:
- Add a tolerance of 1 second in case the timer fires too early.
- Set another oneshot timer whenever we are prevented from updating due to
backoff.
MozReview-Commit-ID: E2ogNRsHJVK
--HG--
extra : rebase_source : 17aa70d8583cc84e28e57410de66eaac63bd18bb
This API is only used by WebExtensions, which previously wanted to exclude separators,
but now we want the WebExtensions APIs to be able to return separators.
MozReview-Commit-ID: 7PApWDwWMr1
--HG--
extra : rebase_source : c5e816900cb0288f1cdba86ec07f6565a1c79880
This allows promiseBookmarksTree to return nodes that describe their type in both string (i.e., PlacesUtils.TYPE_X_*)
format and numeric (i.e., PlacesUtils.bookmarks.TYPE_*) formats. ext-bookmarks.js would prefer to be able to
use the numeric format as that is what is used throughout the rest of the file.
MozReview-Commit-ID: 7DpqAb3zVio
--HG--
extra : rebase_source : d6a9ead83e3de14bb8f52d9e19083a0f6ae609ee
Also, use |run-if| instead of |skip-if| to filter the test.
MozReview-Commit-ID: 5NUoSoRzqMC
--HG--
extra : rebase_source : c50eb0cf377d02456089382108a49658ea6930b7
