Virtual thread references are used for IsOnCurrentThread(), which would
spuriously return true when the dangling pointer happened to match that of a
new PRThread.
Differential Revision: https://phabricator.services.mozilla.com/D55765
--HG--
extra : moz-landing-system : lando
We need to ensure the rules that override all properties for scrollbar
part elements only apply to those that are NAC (and so will be eligible
for NAC style sharing). We have some uses of non-NAC <scrollbar>
elements that should continue to inherit properties from their parents.
To avoid any changes in rule matching order that come with changing specificity,
we add a new :-moz-native-anonymous-no-specificity pseudo-class.
While we're here, we note :-moz-native-anonymous-no-specificity (and the
regular :-moz-native-anonymous pseudo-class) as not needing style
sharing cache revalidation, as we never share NAC styles.
Differential Revision: https://phabricator.services.mozilla.com/D56154
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55444
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
This patch make changes of Gecko infrastrutures to run a fork server
process.
- ForkServerLauncher is a component, which creates a fork server
process at XPCOM startup.
- nsBrowserApp.cpp and related files have been chagned to start a
fork server in a process.
- Logging and nsTraceRefcnt were changed to make it work with the
fork server.
Depends on D46883
Differential Revision: https://phabricator.services.mozilla.com/D46884
--HG--
extra : moz-landing-system : lando
This patch make changes of Gecko infrastrutures to run a fork server
process.
- ForkServerLauncher is a component, which creates a fork server
process at XPCOM startup.
- nsBrowserApp.cpp and related files have been chagned to start a
fork server in a process.
- Logging and nsTraceRefcnt were changed to make it work with the
fork server.
Depends on D46883
Differential Revision: https://phabricator.services.mozilla.com/D46884
--HG--
extra : moz-landing-system : lando
I also removed the unused forward declaration of GMPLoader. It used to
be needed for the declaration of XRE_InitChildProcess.
Differential Revision: https://phabricator.services.mozilla.com/D54819
--HG--
extra : moz-landing-system : lando
Add static CopyFrom method which is to be used in a follow-up patch. The static method takes a nsIWritablePropertyBag so that we don't need to cast to the concrete class.
Differential Revision: https://phabricator.services.mozilla.com/D53923
--HG--
extra : moz-landing-system : lando
For now, there is no flag to actually allow it, but this is the
code-side changes to allow the linker being disabled.
Differential Revision: https://phabricator.services.mozilla.com/D54074
--HG--
extra : moz-landing-system : lando
For processes besides the main process, the leak log is derived from
the value of XPCOM_MEM_BLOAT_LOG, but for the main process, it is
simply whatever XPCOM_MEM_BLOAT_LOG is. This patch adds code to handle
the latter case.
It would be nice to share this code with nsTraceRefcnt.cpp, but
NoteIntentionalCrash() is used in the test plugins so I don't think it
can actually call into libxul. The logic isn't all that complex.
Differential Revision: https://phabricator.services.mozilla.com/D54374
--HG--
extra : moz-landing-system : lando
This function works on all GeckoProcessTypes, not just those for child
processes.
Differential Revision: https://phabricator.services.mozilla.com/D54375
--HG--
extra : moz-landing-system : lando
This function works on all GeckoProcessTypes, not just those for child
processes.
Differential Revision: https://phabricator.services.mozilla.com/D54375
--HG--
extra : moz-landing-system : lando
This way we get the correct values for start-up prefs in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D51061
--HG--
extra : moz-landing-system : lando
The patch for Bug 1588975 specified the "open" verb to execute a target, but
the default verb is not always "open". For example, the default verb for a font
file is "preview". We should specify null verb to start the default operation.
Now we use `IShellDispatch2.ShellExecute` to ask explorer.exe to call
`ShellExecuteExW`. That method takes an optional `VARIANT` parameter as a verb.
According to https://devblogs.microsoft.com/oldnewthing/20140919-00/?p=44023,
we need to pass `VT_ERROR` to omit an optional parameter. If we pass
other values such as `nullptr` with `VT_BSTR` or `VT_EMPTY`, explorer.exe calls
`ShellExecuteExW` with the empty string `""` instead of `nullptr`, which is not
considered as a valid verb if the target file is not associated with any app.
Differential Revision: https://phabricator.services.mozilla.com/D54036
--HG--
extra : moz-landing-system : lando
Calling `AsWin32Error()` for the return value from `ShellExecuteByExplorer` can
cause the crash because it may not be a Win32 error. We simply return
`NS_ERROR_FILE_EXECUTION_FAILED` as we do in `nsProcess::RunProcess` or
`ShellExecuteWithIFile`.
We used to check the return value from `ShellExecuteExW` against `SE_ERR_NOASSOC`,
but it never happens because `SE_ERR_` is returned as `SHELLEXECUTEINFO::hInstApp`.
No worry about the no-association case because `IShellDispatch2.ShellExecute`
displays the "How do you want to open this file?" popup when needed.
Differential Revision: https://phabricator.services.mozilla.com/D54052
--HG--
extra : moz-landing-system : lando
The basic idea, suggested by Olli, is that we can try to get a runnable in
ThreadEventQueue::GetEvent, and if that does not produce anything unlock our
mutex, do whatever idle state updates we need to do, re-lock our mutex. Then
always we need to try getting a runnable again, because a non-idle runnable
might have gotten queued while we had the lock unlocked. So we can't sleep on
our mutex, in the mayWait case, unless we try to get a runnable again first.
My notes on the current (pre this patch) unlocking setup follow.
------------------------------------------------------------
There are four places where we currently unlock:
1) IdlePeriodState::GetIdleDeadlineInternal. Needed only when !aIsPeek, to
RequestIdleToken, which can do IPC. The only caller, via
GetDeadlineForIdleTask, is PrioritizedEventQueue::GetEvent and only when we
selected the idle or deferred queue. We need this to set the proper deadline
on the idle event. In the cases when this unlock happens we currently _never_
return an idle event, because if we got here that means that we do not have an
idle token.
2) IdlePeriodState::GetLocalIdleDeadline. Needs to unlock to get the idle
period hint. The can get called from GetIdleDeadlineInternal in _both_ cases:
peek and get. The callstack for the get case is covered above. The peek case
is called from PrioritizedEventQueue::HasReadyEvent which is called from
ThreadEventQueue::HasPendingEvent.
3) IdlePeriodState::SetPaused, because it sends an IPC message. This is only
called from EnsureIsPaused, which is called from:
- IdlePeriodState::GetIdleDeadlineInternal. Only in the !aIsPeek case.
- IdlePeriodState::RanOutOfTasks called from:
- PrioritizedEventQueue::GetEvent if we fell into the idle case and our
queues are empty.
- PrioritizedEventQueue::DidRunEvent if we are empty.
4) IdlePeriodState::ClearIdleToken because it sends an IPC message. This is
called from:
- IdlePeriodState::RanOutOfTasks; see SetPaused.
- IdlePeriodState::GetIdleDeadlineInternal like EnsureIsPaused.
- IdlePeriodState::GetIdleToken if token is in the past. This is only
called from GetIdleDeadlineInternal, both cases.
- IdlePeriodState::FlagNotIdle called from PrioritizedEventQueue::GetEvent
if we find an event in a non-idle queue.
Or rewriting in terms of API entrypoints on IdlePeriodState that might need to
unlock:
* Anything to do with getting deadlines, whether we are peeking or getting.
Basically, if we need an updated deadline we need to unlock.
* When we have detected we are completely out of tasks (idle or not) to run.
Right now we do that when either we're asked for an event and don't have one
or if we run an event and are empty after that (before unlocking!). But the
unlocking or not happens in nsThreadEventQueue::DidRunEvent, so separately
from the getting of the event. In particular, we are unlocked before we
enter DidRunEvent, and unlock again before we return from it, so we can do
whatever updates we want there.
* When we have detected that we have a non-idle event to run; this calls
FlagNotIdle.
Differential Revision: https://phabricator.services.mozilla.com/D53631
--HG--
extra : moz-landing-system : lando
This change makes it possible to access the remote agent service
from C++ and Rust.
Differential Revision: https://phabricator.services.mozilla.com/D50288
--HG--
extra : moz-landing-system : lando
Most event queues don't ever get many events queued at one time, but the
MainThread Input and Normal queues may.
Differential Revision: https://phabricator.services.mozilla.com/D53912
--HG--
extra : moz-landing-system : lando
This should avoid freeing and reallocating the buffer every N events, and
make it simpler to use smaller buffers, especially for non-MainThread queues.
Differential Revision: https://phabricator.services.mozilla.com/D53911
--HG--
extra : moz-landing-system : lando
Simon Giesecke
Karl Tomlinson
Mihai Alexandru Michis
Daniel Varga
Tyler
Cameron McCormack
Gabriele Svelto
Mike Hommey
Thinker Li
Nathan Froyd
Bogdan Tara
Kershaw Chang
Andrew McCreight
Boris Zbarsky
Noemi Erli
ffxbld
Emilio Cobos Álvarez
Cosmin Sabou
emalysz
Dorel Luca
Sylvestre Ledru
Jean-Yves Avenard
Coroiu Cristina
Jan de Mooij
Toshihito Kikuchi
Tim Nguyen
Andreas Tolfsen
Randell Jesup