Although this test doesn't run on our CI since CI uses Android 7.0, I would
like to add this for the future.
Image keyboard support requires content:// uri for image, so we need content
provider for testing this feature.
Differential Revision: https://phabricator.services.mozilla.com/D157714
Before bug 1792730, we didn't look at style.minWidth, even though this
dialog used it (but contents can be larger).
Using scrollWidth is the right thing to do here. Also fix some other
hard-coded widths I found while at it.
Differential Revision: https://phabricator.services.mozilla.com/D158462
This involves some changes to IPC::Channel::ChannelImpl on all platforms in
order to ensure that they are threadsafe.
1. The ChannelImpl is now internally refcounted, making the correctness
of parts of its lifecycle more clear.
2. Members of the channel are all annotated with `MOZ_GUARDED_BY` for either
the `io_thread_` or `mutex_` depending on if they are required in order to
send a message. This gives us some static checks that we won't deadlock.
3. The `closed_` field is removed, as thanks to the mutex, `pipe_` can now be
checked directly from any thread instead. This reduces the risk of
forgetting to update `closed_`.
4. `NodeChannel` now calls `Send()` without dispatching, which also required
updating some other members to also be accessible from any thread, including
changes to allow asynchronously reporting a channel error when `Send()`
fails.
5. The Windows handling for `Connect()` was made more thread-safe to queue
calls to `Send()` performed before `Connect()` returns. The posix
`Connect()` handler already did this.
Differential Revision: https://phabricator.services.mozilla.com/D158162
Previously the channel used by the ForkServer would be created using
IPC::Channel, and then stolen after the launch was successful. Unfortunately,
this required invoking IPC::Channel methods (such as `Close()`) from the wrong
thread, and so would be racy and hit assertions with the new checks being
added. This patch instead skips creating the IPC::Channel for the fork server,
and allows it to create and configure its own pipe as needed.
This may be used in the future to change out the IPC strategy for the fork
server to something more appropriate, which supports features like async
replies as forked processes die.
Differential Revision: https://phabricator.services.mozilla.com/D158161
The type will be used to explicitly track which members of
IPC::Channel::ChannelImpl can only be accessed on the I/O thread vs. using the
mutex.
Differential Revision: https://phabricator.services.mozilla.com/D158159
After this patch, we still need nsFrameList::Enumerator to iterate
nsFrameList::Slice. We might enhance nsFrameList::Iterator to support Slice, but
I'll leave this for another day.
Differential Revision: https://phabricator.services.mozilla.com/D158809
RemoveFramesAfter and ExtractTail have similar purpose, so we really should keep
one of them to avoid confusion.
They have the following minor differences:
1. RemoveFramesAfter() keeps aFrame in the list, while ExtractTail() returns it.
2. If aFrame is empty, RemoveFramesAfter() returns the entire list, while
ExtractTail returns an empty list.
It's more convenient for the existing callers to use the RemoveFramesAfter(), so
ExtractTail is unneeded.
After this patch, both RemoveFramesAfter() and RemoveFramesBefore() return the
entire list if aFrame is nullptr.
Rename RemoveFramesAfter() to TakeFramesAfter() for symmetry with
TakeFramesBefore().
This change shouldn't change the behavior.
Differential Revision: https://phabricator.services.mozilla.com/D158807
I feel it's hard to understand the purpose of ExtractHead(), especially where
aFrame is going after the call. Therefore, I rename it to TakeFramesBefore(),
and have it complement the existing RemoveFramesAfter(), which will be rename
later. No behavioral change intended.
Also, slightly reword the method's documentation to reflect the its new
name. (Remove the "sibling" wording from the comment since it's an
implementation details that frames are actually a doubly linked list.)
Differential Revision: https://phabricator.services.mozilla.com/D158806
1. When constructing a TextLeafPoint and searching for a leaf, do not descend inside an OuterDoc (iframe/browser).
Otherwise, we end up inside another document.
Other TextLeafPoint code avoids crossing document boundaries, so the constructor must do this too.
2. When searching for a leaf, include an OuterDoc, but don't walk inside it.
Previously, we skipped OuterDocs altogether.
This meant that if you started on an OuterDoc, walking backward and then forward by character would never return you to your origin.
Also, clients walking the document text shouldn't just skip iframes altogether, so exposing them as a single character makes more sense.
This fixes infinite loops in OffsetAtPoint when querying a container with an iframe at the end.
Differential Revision: https://phabricator.services.mozilla.com/D158740
This fixes some tests with flex emulation enabled in the browser
toolbox (which I plan to enable soon enough in bug 1790616).
Differential Revision: https://phabricator.services.mozilla.com/D158629
Previously most 'reasons' could only be seen if using a debugger, which
was not helpful when there was a problem in CI.
Depends on D158703
Differential Revision: https://phabricator.services.mozilla.com/D158704
This will resolve issues of drive letter uppercase/lowercase mismatch
causing the venv/site to be considered 'out-of'date'.
Differential Revision: https://phabricator.services.mozilla.com/D158703
This patch change the behavior of the following two cases:
1. Before this patch, if a form contains a cc-name field and a cc-exp
field that are both identified by regex-based heuristic, we consider
it a valid cc section in Nighty build.
After this patch, the above case only consider a valud cc section when the cc-name field is
identified by fathom. This applys to all builds.
2. Before this patch, a form contains only a cc-name field without
autocomplete attribute is never considered a valid cc section.
After this patch, a form contains only a cc-name field is considered
a valid cc section when fathom is confident
Differential Revision: https://phabricator.services.mozilla.com/D158648
