This patch eliminates the race that bug 1809672 points out, and as a bonus it
significantly reduces the number of main thread hops.
Differential Revision: https://phabricator.services.mozilla.com/D174298
This patch creates the desktop capture thread only once needed, and then passes
it to the TabCapturerWebrtc ctor so its threading members can be const.
Differential Revision: https://phabricator.services.mozilla.com/D174297
Since we now know FocusOnSelectedSource will only be called after StartCapture()
there is no need for it to be able to create a capturer. This means
EnsureCapturer() has only one caller and can be inlined into StartCapture().
Note that this patch breaks the (verbose) capturer creation logic out to a
static function, but mCapturer and mCaptureThread assignment happens exclusively
in StartCapture().
Differential Revision: https://phabricator.services.mozilla.com/D174293
This will not only benefit the assumptions that can be made on the backend
side. It also means we will not shift focus to an external window in case a
window capture fails to start, of if an audio device that is part of the same
request fails to start.
Differential Revision: https://phabricator.services.mozilla.com/D174292
Upstream commit: https://webrtc.googlesource.com/src/+/301e546a689020320f919a660591759e993ef051
Remove SequenceCheckerImpl::valid_system_queue_
As pointed out in issue webrtc:15146 this Mac/iOS specific variable,
makes the SequenceChecker behave incorrectly on those platforms.
The variable was introduced in a CL that merged the previous checker
classes, ThreadChecker and SequencedTaskChecker, but curiously neither
one of them had such a variable. So I'm not exactly sure what problem
was being solved. Hence I'm wondering if we actually need it.
Reference: https://webrtc-review.googlesource.com/c/src/+/129721
Bug: webrtc:15146
Change-Id: Ia7a9eb17b993c4f8a1e8204c658bf0b3dbdaa1e0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304401
Reviewed-by: Peter Hanspers <peterhanspers@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40019}
Differential Revision: https://phabricator.services.mozilla.com/D177875
Upstream commit: https://webrtc.googlesource.com/src/+/3da04a93cd18dc7b65c6756910cc8a9cbf20fb8c
Allow SequenceChecker to be initialized detached.
The motivation for this is to not have to implement this pattern:
foo.h:
class Foo {
public:
Foo();
private:
SequenceChecker checker_;
};
foo.cc:
Foo::Foo() {
checker_.Detach();
}
And instead be able to do this inline in the .h file:
class Foo {
public:
Foo();
private:
SequenceChecker checker_{SequenceChecker::kDetached};
};
Bug: none
Change-Id: Idd7ca82d15c2f77f3aaccf26f1943a49f4b40661
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/298445
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39616}
Differential Revision: https://phabricator.services.mozilla.com/D177874
When `WSRunScanner::ScanNextVisibleNodeOrBlockBoundary` reaches a block
boundary, it may return `WSScanResult` without valid position value from
this path:
https://searchfox.org/mozilla-central/rev/11a4d97a7b5cdfa133f4bda4525649f651703018/editor/libeditor/WSRunObject.cpp#1777-1782
That happens if the reason is `WSType::CurrentBlockBoundary` or
`WSType::OtherBlockBoundary` even in usual cases.
If it's `WSType::CurrentBlockBoundary`, `TextFragmentDataAtStartRef().EndRef()`
may point in a text node in the block, but its `GetEndReasonContent()` returns
the block. I'm not sure whether this is intentional result. (I guess t's a
bug.)
If it's `WSType::OtherBlockBoundary`, `TextFragmentDataAtStartRef().EndRef()`
may point in the list item, but `GetEndReasonContent()` returns a child block.
Those scan result change needs to understand `TextFragmentData` behavior again,
but it's difficult as you know. Therefore, this fixes the caller side not to
use `WSScanResult::Point()` if it meets a block boundary since start of the
block boundary is a good place to put caret.
Differential Revision: https://phabricator.services.mozilla.com/D178281
Added NaN/inf serialization of <number> and changed calc() code to not
remove NaN/infinity in code using it.
This change is unfortunately imperfect as some things using <number>
still refuse to serialize NaN/infinity for some reason (scale()?), but
this bug/patch is just for <number> so leaving that out of scope for this.
Also added new WPT test file for number NaN/inf serialization based
on existing serialization tests (all pass already!).
5 other WPT subtests now newly pass.
Differential Revision: https://phabricator.services.mozilla.com/D178587
Adds functionality to the following menuitems:
always-translate language will immediately translate
the page if not already translated.
never-translate language will hide the translations
button and restore the page if translated.
never-translate site will hide the translations
button and restore the page if translated.
Depends on D177860
Differential Revision: https://phabricator.services.mozilla.com/D178512
Adds tests for all of the menuitems in the Translations
panel settings menu, including always-translate-language,
never-translate-language, and never-translate-site.
Depends on D177859
Differential Revision: https://phabricator.services.mozilla.com/D177860
Adds functionality for the never-translate-site
menuitem in the Translations panel settings menu.
When active, translations will not be offered for
this website.
Depends on D177858
Differential Revision: https://phabricator.services.mozilla.com/D177859
Adds functionality for the never-translate-language
menuitem in the Translations panel settings menu.
When active, translations will not be offered for
websites in this language.
Depends on D177857
Differential Revision: https://phabricator.services.mozilla.com/D177858
Adds functionality for the always-translate-language
menuitem in the Translations panel settings menu.
When active, websites will auto-translate for that
language.
Depends on D177856
Differential Revision: https://phabricator.services.mozilla.com/D177857
Adds new menuitems to the Translations panel settings
menu for always translate language, never translate
language, and never translate site.
Depends on D177855
Differential Revision: https://phabricator.services.mozilla.com/D177856
Adds a new button and panel for managing Translations
settings to the about:preferences panel.
Manages always-translate languages, never-translate
languages, and never-translate sites.
Depends on D178228
Differential Revision: https://phabricator.services.mozilla.com/D177854
Copies the code for Translation exceptions in about:preferences
to new files to preserve the git-blame history so that they can be
modified in a subsequent patch
Differential Revision: https://phabricator.services.mozilla.com/D178228
Skips a test that is causing intermittent failures in CI, which
tests functionality that is not part of the Translations MVP.
See Bug 1821461
Differential Revision: https://phabricator.services.mozilla.com/D178723
https://drafts.csswg.org/mediaqueries-5/#mq-boolean-context is pretty
clear:
> If the feature would be true for any value other than the number 0, a
> <dimension> with the value 0, the keyword none, or a value explicitly
> defined by that media feature to evaluate as false in a boolean
> context, the media feature evaluates to true.
> Otherwise, it evaluates to false.
These hit the "otherwise". The unknown behavior might make sense, but if
someone wants it the spec needs to change (for all media features
consistently).
Differential Revision: https://phabricator.services.mozilla.com/D178712
Andreas Pehrson
Michael Froman
Ryan VanderMeulen
Norisz Fay
Mike Hommey
Masayuki Nakano
Butkovits Atila
Nicklas Boman
Andrew Sutherland
Glenn Watson
CanadaHonk
Kagami Sascha Rosylight
Erik Nordin
Dan Baker
Emilio Cobos Álvarez