This patch has two goals:
- In RTCStatsIdGenerator::RewriteIds avoid having to write a lambda for each
stat dict member that can be an id
- Have a single place in C++-land that explicitly lists public and internal
RTCStatsCollection members, to reduce the number of locations that need
updating when adding new stats.
Differential Revision: https://phabricator.services.mozilla.com/D136154
This patch contains the plumbing work for taking all coalesced codec stats
for a peer connection and mapping them to rtp stream stats and their codecIds.
It depends on two skeleton methods; one for populating and coalescing all codec
stats to transport level, and one for filtering out only the codec stats
referred to by rtp stream stats.
Differential Revision: https://phabricator.services.mozilla.com/D135865
This test is based on the general structure of
js/src/tests/non262/ReadableStream/readable-stream-globals.js, however the
expectations have been commented and updated to match what we believe is
the correct WebIDL behaviour.
Not all the features of that test case have been ported over, as there's
some stuff around the handling of Symbol.species that we can test elsewhere,
and it attempts to test BYOB streams, which we have yet to implement.
Note: I tried to initially write this as an xpcshell test case using
Cu.sandbox; but I found that I wasn't geting global behaviour that matched
my expectations from testing on the web.
Differential Revision: https://phabricator.services.mozilla.com/D137492
For msix pushes, set the payload's publishMode to Immediate for the
Beta channel, and Manual for all other channels (no other channels
are currently enabled, and Manual publishing is desired on Release).
Differential Revision: https://phabricator.services.mozilla.com/D137575
This revision is intended to work with two others in order to fully implement
the best match MVP. The three revisions are the following:
1. This revision sets `result.isBestMatch` to true if `is_best_match` is true in
the quick suggest suggestion.
2. In D137097, results with `isBestMatch` are shown in the view as best matches.
3. We haven't finalized the logic for deciding which suggestions should be best
matches -- in other words, which suggestions should get `is_best_match`.
Once we finalize that, I'll make a third revision that implements it and sets
`is_best_match` appropriately on suggestion objects. Merino will need to
include `is_best_match` in its suggestion objects too as appropriate.
In order to test this revision, I added support for a temporary
`_test_is_best_match` on suggestion objects that the test can use.
Depends on D137097
Differential Revision: https://phabricator.services.mozilla.com/D137250
This creates a new type of `bestmatch` row in the view. The UX spec is here:
https://www.figma.com/file/seJ2ZA4v3FgoV7jCxUR74B/Firefox-Suggest?node-id=5235%3A1284
(See: “Best match” proposal
for Firefox 99)
Best match rows look similar to standard rows except they have a large 52x52
icon with the title and URL vertically centered next to it. Best match rows that
are sponsored also have the usual "Sponsored" label.
We're targeting 99 for the initial MVP version of this feature. For the MVP,
best matches will always be quick suggest results. Long term, there's been
discussion about incorporating history and bookmarks too.
Since 99 is coming up soon and we don't have much time, I did what I think is
the most straightforward thing and added another new row type, `bestmatch`. I
considered using the usual row DOM, but it's tricky because for best match we
need to show both the URL and sponsored label, and the sponsored label needs to
be shown below the title. The way we show the sponsored label for typical quick
suggest rows is by putting it in the action text and wrapping it below the
title, but that doesn't work for best match since it must show the URL.
However, best match rows do look similar enough to the usual rows that I think
it would be worth modifying the usual row DOM so that it uses this new best
match DOM. That would simplify the JS and CSS. It's also a much larger, riskier
change and there might be disagreement about it, and I don't want to block this
feature on that, so I'd like to come back to it. I have a WIP in D137095 that
also includes some general refactoring and simplification.
I could have implemented this as a dynamic result type like the onboarding
tab-to-search, but that would couple best match to a particular provider --
quick suggest -- and as I mentioned we may end up expanding best match to all
types of results. I don't want to add a new type and all of that code if we know
we may remove it later.
This revision relies on a new `result.isBestMatch` property that will be set for
quick suggest best matches in D137250.
The best match DOM looks like this:
```lang=html
<span class="urlbarView-row">
<span class="urlbarView-row-inner">
<img class="urlbarView-favicon">
<span class="urlbarView-row-body">
<div class="urlbarView-row-body-top">
<div class="urlbarView-row-body-top-no-wrap">
<span class="urlbarView-title"></span>
<span class="urlbarView-title-separator"></span>
</div>
<span class="urlbarView-url"></span>
</div>
<div class="urlbarView-row-body-bottom">Sponsored</div>
</span>
</span>
</span>
```
Finally, this also adds a "Best Match" group label in the view. A few notes on
this:
* The string isn't finalized yet but we can easily update it once it is.
* Since right now best match will be en-US only and is related to Firefox
Suggest, I added the string to firefoxSuggest.ftl, which is not localized.
* In D137250 I'm adding a `browser.urlbar.bestMatch.enabled` pref and moving the
caching of this string behind that pref.
Differential Revision: https://phabricator.services.mozilla.com/D137097
Requested index handling is very fragile. We should try to figure out a way to remove it altogether.
(But unfortunately some behavior similar to it is needed in certain cases).
The patch is a stop-gap solution.
Differential Revision: https://phabricator.services.mozilla.com/D137479
This allows for faster playback rates of EME media. This should allow up to ~5
times speed. Users in the wild have reported this value working without bustage,
so we have some evidence this is a safe value.
Differential Revision: https://phabricator.services.mozilla.com/D137563
This makes it clearer that the field in a `ClipChainInstance` refers
to the total coverage of the picture by this primitive + clip-chain,
rather than referring to it being a clip rect itself.
Differential Revision: https://phabricator.services.mozilla.com/D137506
The previous version had two issues:
It revealed an issue in the old implementation which causes an assertion to fire.
There was also a problem with mDocumentRequest, so the new approach tries to be less clever
and just adds a new boolean member variable mCheckingSessionHistory,
which GetIsAttemptingToNavigate() then uses.
Differential Revision: https://phabricator.services.mozilla.com/D136041
mPrintTarget can be nulled out and the caller needs to deal with null
returns already, so this should address the crash.
Differential Revision: https://phabricator.services.mozilla.com/D137473
Right now we hold clipboard data in nsRetrievalContext and we don't allow any
clipboard operation until ReleaseClipboardData call.
That also lock nsRetrievalContext on Wayland untill ReleaseClipboardData call.
It may lead to clipboard failures when we're holding clipboard data but we want to read clipboard targets.
In this patch we:
- Transfer data ownership in GetClipboardData/GetClipboardText/GetTargets and don't store the data in nsRetrievalContext.
- On Wayland lock nsRetrievalContext only for GetClipboardData/GetClipboardText/GetTargets calls.
- Check mClipboardRequestNumber before assert due to unreleased mClipboardData.
Differential Revision: https://phabricator.services.mozilla.com/D137537
Previously mozcrash would just create an empty temp dir and pass that in as a symbols_path.
The comment suggests this would be used as a --symbols-cache/--symbols-tmp, but that's
certainly not how the new minidump-stackwalk handles positional symbols-path arguments?
minidump-stackwalk is perfectly capable of automatically creating its own tempdirs,
so nothing actually needs to be done. Instead I emit a warning and remove the guards
against the value being missing.
Differential Revision: https://phabricator.services.mozilla.com/D135940
Jan-Ivar Bruaroey
Andreas Pehrson
Matthew Gaudet
Geoff Brown
Jintao Hu
Drew Willcoxon
Jonathan Kew
Scott
Valentin Gosu
Olli Pettay
Bryce Seager van Dyk
Randell Jesup
Butkovits Atila
Andreea Pavel
Glenn Watson
Kagami Sascha Rosylight
Joel Maher
stransky
Mozilla Releng Treescript
Emilio Cobos Álvarez
Alexis Beingessner
Marian-Vasile Laza
Julian Descottes