The DISPATCH_QUEUE_PRIORITY_DEFAULT queue currently in use starts tasks as they
arrive rather than running tasks sequentially. By using a dedicated serial queue,
frames will be encoded and delivered in the order in which they are added to the
queue. It also makes it possible to post a task to the queue when video capture
is stopped, which can guarantee that all frames have been delivered before stop
completes. This should fix a crash we're seeing in DeliverCapturedFrame which
appears to be caused by racing between the main thread in Stop() and the capture
thread in captureOutput. The new queue is set to target the
DISPATCH_QUEUE_PRIORITY_DEFAULT, so tasks will still run there. This should give
us serial execution without the overhead of starting a new thread to manage our
queue.
The new upstream implementation creates a serial queue rather than using
DISPATCH_QUEUE_PRIORITY_DEFAULT. It also raises the priority of the queue above
default, but I think that should wait for a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D82721
It removes some invisible leading and/or trailing white-spaces when it inserts
`<br>` element into the invisible white-space sequence. It currently checks
whether the insertion point is in invisible leading and trailing white-spaces
or not with `FindNearestFragment()`, but we can do same thing with
comparing the insertion point with the result of
`TextFragmentData::GetInvisibleLeadingWhiteSpaceRange()` and
`TextFragmentData::GetInvisibleLeadingWhiteSpaceRange()`. However, current
implementation does not make sense because:
- It checks trailing white-spaces with `!IsEndOfHardLine()` and
`IsStartOfHardLine()`, but this means that it does ignores invisible
white-spaces which are the only content in a line.
- It checks leading white-spaces with `!IsStartOfHardLine()` and
`IsEndOfHardLine()`, so, this also ignores invisible white-spaces which
are the only content in a line.
- The important thing of the logic is prevent that invisible leading and
trailing white-spaces become visible with new `<br>` element, but this
is done only for trailing white-spaces.
Differential Revision: https://phabricator.services.mozilla.com/D82283
The change itself isn't important for us, because we don't use ICU's make-files,
but avoids confusion why additional changes were applied when running the update
script.
Differential Revision: https://phabricator.services.mozilla.com/D82545
Currently we're converting the configuration url parameters to strings in makeEngineFromConfig via URLSearchParams. We then pass them through URLSearchParams again in _initEngineURLFromMetaData.
Depends on D82525
Differential Revision: https://phabricator.services.mozilla.com/D82583
The main aim here is to move the call to getEngineParams that currently happens before addEngineWithDetails. This is moved into addEngineWithDetails, so that it is next to where the search engine is actually created. This gets ready for the next step which will be to merge getEngineParams with the SearchEngine initWithMetadata and associated calls.
The side effects are that we need a specific function for policy engines to use, and that we now have only tests using addEngineWithDetails.
Differential Revision: https://phabricator.services.mozilla.com/D82348
The only common failure case that's not being warned about now is when the user
rejected the prompt, which I think is expected behavior.
Differential Revision: https://phabricator.services.mozilla.com/D79597
WrappedFunction only needs the JSFunction* for natives. This way we can still
optimize scripted calls to nursery-allocated functions.
Depends on D82670
Differential Revision: https://phabricator.services.mozilla.com/D82671
DynamicIA2Data can be built to be transmitted in two different ways:
1. As part of the payload included in the stream when an accessible is marshaled; or
2. As an out parameter returned by IGeckoBackChannel::Refresh().
DynamicIA2Data includes arrays for row/column header ids.
Normally, such arrays would be allocated by CoTaskMemAlloc and freed by CoTaskMemFree.
However, in the first case, the struct is actually marshaled by RPC encoding functions, not by COM itself.
This means we must use midl_user_allocate/free, lest we crash.
We previously used midl_user_allocate/free for the second case as well.
Unfortunately, it turns out that this too causes crashes.
To fix this, we now use different memory allocation functions depending on how the struct is transmitted.
This patch also cleans up the old DynamicIA2Data in the client before calling IGeckoBackChannel::Refresh.
Previously, we didn't do this, which would have resulted in a leak.
Differential Revision: https://phabricator.services.mozilla.com/D82823
Dimi Lee
Kershaw Chang
Dan Minor
Dão Gottwald
Tom Schuster
Masayuki Nakano
Sebastian Streich
André Bargull
pbz
Mark Banner
Andreea Pavel
Tooru Fujisawa
Nicolas Chevobbe
Mirko Brodesser
Johann Hofmann
Florin Strugariu
Razvan Maries
Jan de Mooij
James Teh
Daisuke Akatsuka