Result of running the update script and updating gecko's
integration crate for the layout change.
MozReview-Commit-ID: GaIMFKmPmtf
--HG--
extra : rebase_source : 0d3a2f1d211840879e562cb56afcc9ef7e38c730
This release splits the capi into a separate crate and adds
mp4parse_is_fragmented() for vp9 support.
MozReview-Commit-ID: JkwylmdfPa9
--HG--
extra : rebase_source : b74b7e20aaf49fe1b2b7121562352c755db3aff3
The same URL could be picked as highlight from history and from bookmarks.
MozReview-Commit-ID: 5vBHluZKfAN
--HG--
extra : rebase_source : 1fee3b2532670d0b9d472518f3648ee5b5bebb8e
This query resembles how the Activity Stream add-on for desktop Firefox selectes highlights[1].
The desktop version uses the 'rev_host' (reversed host) column to filter the results based
on a blacklist and group results by hostname. This has been omitted here (See bug 1298785 and
bug 1298786).
Additionally the desktop version uses a block list to filter "highlights" that have been removed
manually by the user. This is not added here until needed from the UI side (see bug 1298783).
[1] 9eb9f451b5/addon/PlacesProvider.js (L578)
MozReview-Commit-ID: 9TyIaK21MNJ
--HG--
extra : rebase_source : d6debec1c16b1a1667b0c10fe49e4fcc1dc11bfd
Cubeb can be in three states: Uninitialized, initialized (or in
error), or shutdown.
This will ensure that we only initialized cubeb once, and that
we don't attempt to re-initialize it after shutdown.
MozReview-Commit-ID: 8LhRe7bvS4K
--HG--
extra : rebase_source : 3b58d94ad1e578c9316455893deb2d826aefe0dc
There are 2 bugs and this patch fixes them once.
First, NativeKey::WillDispatchKeyboardEvent() is used to setting alternative charCode values for every eKeyPress event. However, for supporting "reserved" shortcut keys, now, it sets alternative charCode values to eKeyDown too. However, they are really different. eKeyPress events are fired for every character to be inputted by a key press sequence. On the other hand, eKeyDown event is fired only once for a key sequence. Therefore, now, NativeKey::WillDispatchKeyboardEvent() needs to set alternative charCode values for all characters inputted by the key sequence to eKeyDown event.
The other is not a new bug. NativeKey::WillDispatchKeyboardEvent() sets the last eKeyPress event's special alternative charCode values, such as unshifted Latin character, shifted Latin character and some character which can be computed from virtual keycode. This is performed when given index is the last index of the longest input string of the key. However, the value includes different shift key state. I.e., when different shift key causes longer text input, NativeKey::WillDispatchKeyboardEvent() won't set the special alternative charCode values to any eKeyPress events. For example, when Ctrl+T is pressed with Arabic keyboard layout, its unshifted input string length is 1 but shifted input string length is 2. Then, eKeyPress event is fired only once, but NativeKey::WillDispatchKeyboardEvent() waits second eKeyPress event.
Therefore, this patch makes the method append alternative charCodes for all remaining characters and detect the last event correctly with mCommittedCharsAndModifiers (it's used for KeyboardEvent.key value of eKeyDown event and the count of eKeyPress events is same as the value's length).
MozReview-Commit-ID: 6adUnmi5KYy
--HG--
extra : rebase_source : 8c04a3a155f2fcb9a5a8b3e9e0a176c678dc6265
This patch introduces helper for the embedding of a webextension (and new related tests).
The new exported helpers are going to be integrated in the XPIProvider
to provide the Embedded WebExtension to the Legacy Extensions which
have enabled it in their install.rdf
MozReview-Commit-ID: 7M1DRkXjGat
--HG--
extra : rebase_source : 3226a83652b97601d9d4d34693761cfc720735a0
- this new module contains helpers to be able to receive connections
originated from a webextension context from a legacy extension context
(implemented by the `LegacyExtensionContext` class exported from
this new jsm module)
- two new test files (an xpcshell-test and a mochitest-browser) ensures that the LegacyExtensionContext can receive a Port
object and exchange messages with a background page and a content script (the content script test
is in a different test file because it doesn't currently work on android, because it needs
the browser.tabs API and the TabManager internal helper)
MozReview-Commit-ID: DS1NTXk0fB6
--HG--
extra : rebase_source : 462d6a461167e317297d204e72c2f6773bc5c770
DiscardRemaning was needed to prevent debug-time assertion that the buffer was
read completely or explicitly discarded.
However this required extra work in cases where buffer didn't need to be read
to the end.
And also it could cause crashes (in debug versions) if a buffer was not fully
read, be it because the parser was incorrect or because the media file itself
was wrong (though possibly still readable despite that).
Finding parser issues is still possible by manually instrumenting ByteReader
during development.
And reading media file with small recoverable errors is a bonus.
MozReview-Commit-ID: 2RUYzaYAeRW
--HG--
extra : rebase_source : 26c41758b1b2c87542bf4e41d08e361198ca5b13
I came across these while working on a different bug that changed the grouping
in the unified build. Adding these as a separate step will hopefully remove a
little noise from the next patch in the series.
MozReview-Commit-ID: Km7wTcVWG9n
--HG--
extra : rebase_source : 0610add67482c1a5aa7c4f576e151ed9437698c0
This mirrors the location of Servo_Init. This is important because xpcshell runs
don't use nsAppRunner, and so we end up with an unpaired call to Servo_Shutdown,
which crashes.