`mozAutoDocUpdate` does not make it in a document change when container node
of `insertBefore` has already been removed from the tree. Therefore, once
`IMEContentObserver::mRootElement` is removed from the DOM tree without a
focus move, `IMEContentObserver` is notified mutations not in a document change.
Similar situations are handled in `IMEStateManager::OnRemoveContent` with
emulating a focus change and that will destroy the active `IMEContentObserver`.
Therefore, if `IMEContentObserver::mRootElement` is removed, we should emulate
a focus move when `IMEStateManager` does not have focused element but there
is active `IMEContentObserver` (that means it is/was in the design mode).
However, checking whether the removed node contains the observing node of the
active `IMEContentObserver` may be expensive. So, doing expensive things in
`IMEStateManager::OnRemoveContent` may make mutations slower. Therefore, this
patch makes `IMEContentObserver` observe `ParentChainChanged` and it let
`IMEStateManager` know that with calling its
`OnParentChainChangedOfObservingElement`. Finally, it calls
`IMEStateManager::OnRemoveContent` to emulate "blur" (and refocus if it's
required).
Differential Revision: https://phabricator.services.mozilla.com/D218696
The log statement in ComputeIntrinsicScale() was quite noisy because one
of its callers was called on every paint. The patch moves it to the
non-noisy call sites, and details whether the intrinsic scale is being
computed based on the viewport size or content size.
Also add a couple of new log statements.
Differential Revision: https://phabricator.services.mozilla.com/D216902
This is a temporary measure. We would like to destroy the native window
here, but we want to see the effect of removal on crash volume.
This patch also moves the call to BaseWindow::OnDestroy() to the end of
::Destroy(). This is necessary to get tests to pass. It may also be the
real fix for this Bug.
Differential Revision: https://phabricator.services.mozilla.com/D216066
Process.kill already waits, which means if there's a timeout and the
process doesn't die within that timeout, we can end up waiting twice the
timeout currently because of the extra wait call.
Initially, I tried to remove the extra wait entirely, but there are two
things that it does that are expected from callers:
- it sets self.returncode. This could be done in kill itself, but the next
expectation makes it irrelevant.
- it calls self.reader.join under some conditions.
Because of these expectations, we "just" keep the wait call, but reduce
its timeout to avoid doubling the timeout in the worst case.
Differential Revision: https://phabricator.services.mozilla.com/D218911
First and foremost, this undoes the patch for bug 1845125, which causes
other problems (e.g. output being dropped past a certain point).
The rest of the patch addresses bug 1845125 at the root: Ultimately, this
is a similar problem to bug 1863675.
wait is blocked on joining the stream reader thread, but the stream
reader thread is blocked on readline because the process is finished but
hasn't been waited on yet.
So joining the stream reader thread after the process is known to have
been finished is expected to work more reliably... except when a child
has been spun up that keeps it alive. In this case, we just keep the
reader thread working in the background, which is a similar strategy to
what was done in bug 1863675.
Differential Revision: https://phabricator.services.mozilla.com/D218389
When multiple threads call wait, they may all end up in _custom_wait,
waiting for an event on the process event queue. But there's only ever
going to be one of those events emitted by the IO completion port
manager.
Of course, because before, we were always timing-out doing that,
eventually, that would work out, albeit after multiple minutes.
So we re-emit the event for other threads calling wait not to wait
forever.
And because now we have multiple threads that might return for wait
concurrently, they may end up calling _cleanup concurrently too, which
can fail because of race conditions, so add some locking.
It's also not a theoretical problem: test_process_timeout_no_kill
triggers it by calling kill from a timeout handler (which runs on the
reader thread) while waiting on the main thread. ProcessHandlerMixin
does it too, but that could be changed to use send_signal, while
external uses can do what the hell they want. This is another reason to
want to avoid kill implying wait.
This change, however, does not address all the possible race conditions.
More work would be needed.
Differential Revision: https://phabricator.services.mozilla.com/D218910
Cleanup closes various handles, with consequences on the IO port
completion manager, the stream reader, etc. That means further
operations after a wait() after which the process was still running
(which is a valid state) could fail to work properly.
So only cleanup when we know the process has died either a natural or
forced death.
Differential Revision: https://phabricator.services.mozilla.com/D218909
wait(None) is supposed to wait for a process terminating indefinitely.
But we currently cap it to 3 minutes and a half, which seems more of a
workaround than something really wanted.
When we always have a timeout, we don't distinguish between the case
where wait was called with an explicit timeout, and the case where it's
meant to wait until the process actually dies.
And because not getting an event on the queue within the timeout throws
an Empty exception, that exception is caught and is handled as an error,
while it's supposed to be normal behavior.
The expectation we should have is that either there's an event on the
process event queue within the timeout requested for the wait, and go on
normally, or the queue is still empty at the end of the timeout,
throwing an exception, in which case we'd want wait to return normally
indicating that the process is still running.
Similarly, in the no-IO port completion manager case, we shouldn't kill
a process because we waited the amount requested. wait(n) is not "kill
after n seconds".
Differential Revision: https://phabricator.services.mozilla.com/D218908
The only reason custom_wait is checking whether the current thread is
the IO completion port manager is because there is a case where it might
call Process.kill, which does an automatic wait. However, for the
purpose of the IO completion port manager, the only interesting thing
is for the process to be killed, not to wait for that to finish in the
thread itself.
So we introduce a method that does kill without wait. It could be argued
that kill shouldn't wait in the first place, like subprocess.Popen does,
but that's a bigger API change.
Differential Revision: https://phabricator.services.mozilla.com/D218907
If the current thread is the IO completion port manager thread, then
obviously it's alive. If the current thread is any other thread, and we
were using IO completion ports, there could be pending events in the
process events queue regardless of the state of the IO completion port
manager thread: after putting an event on the queue the thread would
terminate, so there was a race condition where the queue would not be
used when it should have been.
There is a case, though, where there might not be an event on the queue:
if the thread fails in an unexpected exception. In that case, we put
something on the queue that will make _custom_wait fail.
Differential Revision: https://phabricator.services.mozilla.com/D218906
That value might be returned to callers of other methods that return
Process.returncode, and might mislead them because they would be
expecting None in that situation.
Differential Revision: https://phabricator.services.mozilla.com/D218905
This is an extra-double-sure clipping of the scissor rect to the valid
rect. This shouldn't matter since the dirty rect is clipped before the
creation of either of the other two rects, but will ensure that rounding
issues from the application of the transform in `get_surface_rect` won't
leave us with an out-of-bounds scissor rect.
Differential Revision: https://phabricator.services.mozilla.com/D219916
This patch does a sweep over the wasm JS API to return BigInt for
relevant memory64 params and results. More precisely, it brings the JS
API in line with the new IndexValue stuff in the JS API spec.
It also fixes validation of table types to allow the larger maximum size
of tables allowed by table64. This changes the limits type of tables to
use uint64_t instead of uint32_t, but does not change any actual
behavior and does not change the internal storage of tables.
Differential Revision: https://phabricator.services.mozilla.com/D219530
This patches allows
1. when the selection is shadow-crossing, dragging it will have the
correct the drag image correctly displayed. It's hard to test, so
no tests for this.
2. The selection can now be serialized and dropped.
`test_drag_drop_shadow_crossing_selection.html` is the test for
this.
Differential Revision: https://phabricator.services.mozilla.com/D217318
In Bug 1886847, there was a discussion on how best to separate chrome from content
from chrome whilst remaining true to the new look. We landed on usiong both a box
shadow and border.
Differential Revision: https://phabricator.services.mozilla.com/D218126
Masayuki Nakano
Botond Ballo
Mozilla Releng Treescript
Brad Werth
Mike Hommey
Robert Holdsworth
James Teh
Stanca Serban
kpatenio
Ryan VanderMeulen
Ben Visness
Nipun Shukla
Florian Quèze
Roger Yang
Byron Campen [:bwc]
Kelly Cochrane
longsonr
Sean Feng
Nikki Sharpley
Jonathan Sudiaman
Leander Schwarz
Benjamin VanderSloot
Nicholas Poon