This will allow us to enumerate active threads in order to report their
memory.
MozReview-Commit-ID: IExELSkFdwB
--HG--
extra : rebase_source : 94b63857357639b201b85bdd7bfc4fbe1d4b7f62
The IterableIterator helper currently only supports iterator methods which
return types which are supported by ToJSValue, but do not need a JSContext* to
construct them. That means that getters which need to return native JS objects
or values can't do so safely, or without resorting to hacks.
This patch adds templated helpers which will call a JSContext-accepting,
JS::Value-returning version of the getter methods if they exist, and fall back
to the simpler versions if they don't.
MozReview-Commit-ID: hedZOc3lqR
--HG--
extra : rebase_source : b92cdc3900b3c9bee41836af4d4b9f4e65f3d5f6
Added C++/glue code for the dtls-message attribute.
Enabled the C++ unit test CheckDtlsMessage.
Added a branch in the rust parsing that discardes dtls-messages on media level.
MozReview-Commit-ID: 9tcWOtH8GbV
--HG--
extra : rebase_source : 4853e51e1cc6734760c243da8e27dc714c89d219
Added dtls-message parsing in rust.
Added a rust testcase for the dtls-message parsing.
MozReview-Commit-ID: G8boBkxlJmX
--HG--
extra : rebase_source : 40ee205294adf099f51321ec7bde8cbff5db6297
This change has WrClipId contain the ClipId type (except for clip
chains, which are handled separately) in the least significant bit of
the size_t. On 32-bit systems this limits the number of clip and spatial
nodes to 2,147,483,648 which is likely more than what WebRender can
handle.
MozReview-Commit-ID: 1cpZCBt1wL7
--HG--
extra : rebase_source : 8183570e37bf6da69a3e7335d63fc47cad191fe9
Since fixed position elements are now scrollable, we need to ensure that they're
drawn using the layout viewport size instead of only the SPC-SPS, since
otherwise they'd be inaccurately clipped when scrolled.
MozReview-Commit-ID: 4p3pWnwluvz
--HG--
extra : rebase_source : f5bc1eae9bf2c8f4b9f78675e9da071de012160e
This patch applies the following changes to the storage.local data migration behaviors:
- An about:config preference is set when an extension has been migrated successfully to the
storage.local IndexedDB backend (cleared automatically if the addon is uninstalled).
- If the above about:config preference is set, the storage.local IndexedDB backend is enabled
without attempting to open an IndexedDB connection for the new backend.
- While migrating an extension, if we fail to open the IndexedDB connection, the data migration
is cancelled and the storage.local API is going to fallback to the storage.local JSONFile backend
(until the next extension startup, when a new data migration is going to be tried).
- When a migration is completed successfully, the old JSONFile is renamed (by appending ".migrated"
to its original file name) instead of being removed.
MozReview-Commit-ID: LPM0fQUagTd
--HG--
extra : rebase_source : 11c3e291ac8323a679c2bb29efc7df3700023591
The identity popup will now show that there's an exception on the site instead of being confused.
We previously didn't handle this state because I assumed it wouldn't be possible to enter.
Turns out if you open the same (tracking) site in two tabs and then add an exception in one tab,
the other tab will be in this state until reload.
MozReview-Commit-ID: GVVdNpsAm6h
--HG--
extra : rebase_source : 3ace3cd4f99094edf3c678c56a39adebdc37d1f3
Adapt inspector test to the new order of the search results.
This was an easy task since we were already flipping the
expected results to make the test more readable (which makes
me think that this is the "natural" order).
MozReview-Commit-ID: DpxW2O1eOi4
--HG--
extra : rebase_source : 8d579c94bdaaee396a29b4674d4f9764bcadbb5d
extra : source : 96c82bb5fa591470483263aea55fa33a10192afc
For some reason, we were flipping the search result, which
was not ideal in the inspector. This patch changes this to
show results in the same order the server return them.
MozReview-Commit-ID: Ak9FnrrW8z5
--HG--
extra : rebase_source : 0846cda90ac45c70a9ee5cd49f64f1894863ec5c
Some tests needed to be adapted to the new alpa-sorted
autocomplete popup.
MozReview-Commit-ID: 3GOAJqH0CvD
--HG--
extra : rebase_source : ca9bafa6e78f2a1609618e5c258db0358a006300
The autocompletion results were flipped in order to have them in reverse
order since the popup was displayed at the top of the input.
We do not want to do that anymore because of two reasons:
- I couldn't find any example in the wild doing the same thing, thus
we were making the user switch their habit to use it
- Bug 1136299 will make it so that the popup could be displayed either
at the top or at the bottom of the caret. We shouldn't have different
sorting for those different cases as it would make the popup even
harder to use.
MozReview-Commit-ID: CAzsKIaeKgV
--HG--
extra : rebase_source : 967e43e5d86f7f35945ba5742c1a25823a2d0064
Previously, we were trying to select the item the closest
to the input used for the autocompletion. It was causing
some weird behaviour when the popup wasn't displayed at
the expected position.
Always selection the top-most item seems will avoid those
cases, bring us consistency across the toolbox as well as
with other tool having autocompletion (code editors, Chrome, …).
The autocomplete-popup test is modified to assert the new behavior.
MozReview-Commit-ID: DhNovX51KRO
--HG--
extra : rebase_source : cfb2ebaaed23ce5c51ef9d8f447f3fabe0a04a49