mReplySuccess is set appropriately only when the reply is received.
An inappriopriate success could lead to incorrect data being returned.
Depends on D140023
Differential Revision: https://phabricator.services.mozilla.com/D140025
RecvPCamerasConstructor() is used because IPC messages cannot be sent from
AllocPCamerasParent() because SetManagerAndRegister() has not been called to
change mLinkStatus to Connected.
Differential Revision: https://phabricator.services.mozilla.com/D140022
Add a new property to downloads such that downloaded files deleted from within
Firefox (currently just by the context menu item) are marked "File deleted"
instead of "File moved or missing" (this adds a new translation). Also refactor
downloadsCmd_deleteFile and downloadsCmd_cancel to clean up some related issues.
Add a new download history metadata property so that Firefox can persist this
"File deleted" state between sessions.
This should resolve bug 1755570 as well as bug 1755728. Bug 1755729 is a
separate issue, more like an enhancement, because missing/moved downloads have
never allowed resume/retry. They couldn't be resumed as they were stopped, not
paused. They could conceivably be retried but this would be adding a whole lot
of new core download logic, since the target and saver are in a very different
state for a stopped download with a deleted file than what they'd be if the
download was merely canceled.
So, this patch won't give the user an opportunity to resume/retry deleted
downloads. Previously we had a problem where we made it look like you could
retry a download if you used the "delete file" command while the download was in
progress. This patch will make sure that using the "delete file" command
actually finalizes the download. So it will just fix the immediate problem where
some menuitems and buttons simply don't work in edge cases. A later patch can
implement a new affordance that will allow "retrying" downloads that were
already downloaded/interrupted and deleted, whether from within Firefox or not.
Differential Revision: https://phabricator.services.mozilla.com/D139356
AsmJS compilation may be off the main thread, so we cannot report warnings
to JSContext. wasm::Log may do this if the right pref is on. CompileArgs::
build() uses wasm::Log. AsmJS uses CompileArgs::build(). This commit adds
a separate version of CompileArgs::build() which will not log or report
errors. AsmJS then asserts that only an OOM may be possible here, as we
should ensure a wasm compiler is available before compiling.
Differential Revision: https://phabricator.services.mozilla.com/D141007
* @import rather than %include stylesheets in each platform's browser.css
* Remove the inc.css suffix for @imported files
* browser.inc.css becomes browser-shared.css
* Move shared @imports to browser-shared.css
* panelUI.inc.css becomes panelUI-shared.css
* download/indicator.inc.css becomes download/indicator.css and is @import-ed.
* addons/extension-controlled.inc.css becomes addons/extension-controlled.css and is @import-ed
* places/places-tooltip.inc.css becomes places/places-tooltip.css and is @import-ed
* urlbar/dynamicResults.inc.css becomes urlbar-dynamic-results.css and is @import-ed from urlbarView.css
* Remove preprocessing flags from css resources in jar.inc.mn that no longer contain any preprocessor directives
Differential Revision: https://phabricator.services.mozilla.com/D140275
This doesn't change behavior but makes some code a bit nicer to read and
documents some of the code that wasn't obvious otherwise.
Differential Revision: https://phabricator.services.mozilla.com/D141236
The presenting issue is that each background task's audio session is
user-visible via various Windows UIs that display "volume controls" or
"volume mixers"; this avoids that.
Differential Revision: https://phabricator.services.mozilla.com/D141101
There are a few ways that we could test this. We could use the
profiler and "File IO" markers, a la
https://searchfox.org/mozilla-central/source/browser/base/content/test/performance/browser_startup_content_mainthreadio.js.
This would profile content that is transient, which could be good or
bad -- temporary files for atomic writes would show up for example.
But in fact there are profile contents created after the profiler is
shut down (including `Telemetry.ShutdownTime.txt`), so this approach
isn't sufficient.
Therefore we do the simpler thing: we simply don't remove the
temporary profile directory after the background task exits.
Differential Revision: https://phabricator.services.mozilla.com/D139909
Now that we're using `sysconfig` instead of `distutils`, our `purelib`
and `platlib` paths should correctly point to python environment paths
without a spurious `local/` component at their roots.
Differential Revision: https://phabricator.services.mozilla.com/D140871
Depending on the subprocesses created (such as if
`--with-ccache=sccache` is set), `./mach configure` may hang.
More details about why this is is documented in bug 1753797.
The workaround is to lean on the standard library to stream-and-format
output, rather than our existing `ProcessHandler` code.
Though this still streams both `stdout` and `stderr` in real-time, I saw
some ordering differences between the two streams locally. I don't yet
have a reason to believe that these differences are harmful or otherwise
incorrect.
Differential Revision: https://phabricator.services.mozilla.com/D141028
