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
Rename PostTask methods into Dispatch to be more in-line with the current naming convention as PostTask pretty much always referred to the MessageLoop's method.
Differential Revision: https://phabricator.services.mozilla.com/D82159
On Windows the CubebDeviceEnumerator needs to run on an MTA thread; to achieve that goal we use the EnsureMTA utility.
EnsureMTA relies on a MTA thread to exist which will be destroyed when XPCOM shuts down ; as such we must shutdown the CubebDeviceEnumerator during the same shutdown phase.
ClearOnShutdown registrars are processed in LIFO order, so as the CubebDeviceEnumerator constructor uses EnsureMTA we are guaranteed that the CubebDeviceEnumerator clearOnShutdown will be processed before the EnsureMTA thread shutdown.
The CubebDeviceEnumerator needs to be shutdown before cubeb; which is also guaranteed as the cubeb instance is destroyed during the final XPCOM shutdown stage.
Fix GetSafety() thread-safety.
CubebDeviceEnumerator should be a static non-refcounted singleton on the stack really which would made the code much simpler, unfortunately its gtests rely on having the Shutdown method present to force re-scanning the devices and work with the mock cubeb.
Differential Revision: https://phabricator.services.mozilla.com/D82158
Ths helps not having to worry about how to create the thread; which could be probablematic when running off a thread pool.
Differential Revision: https://phabricator.services.mozilla.com/D82142