Previously the `boolean` type was also declared using a `bool` typedef in
xpidl, meaning that both were used in various places. This patch standardizes
on the built-in `boolean` type, removing the typedef.
Differential Revision: https://phabricator.services.mozilla.com/D206382
Added in some code to expose the path to the os default application. Tested via tests on Windows. Mac and Linux will use the nsMIMEInfoImpl which will supply the functionality for them and be tested with the auto-tests.
Differential Revision: https://phabricator.services.mozilla.com/D204306
Some code to exercise this in the browser console:
```
{
const printNames = async (appList) => {
let buffer = "Start:\n";
for (let index = 0; index < appList4.length; index++) {
let app = appList4.queryElementAt(index, Ci.nsILocalHandlerApp);
buffer += app.executable.leafName;
buffer += "\n";
}
buffer += "\n";
for (let index = 0; index < appList4.length; index++) {
let app = appList4.queryElementAt(index, Ci.nsILocalHandlerApp);
let prettyName = await app.prettyNameAsync();
buffer += prettyName;
buffer += "\n";
}
buffer += "\n";
for (let index = 0; index < appList4.length; index++) {
let app = appList4.queryElementAt(index, Ci.nsILocalHandlerApp);
buffer += app.executable.displayName;
buffer += "\n";
}
buffer += "\n";
for (let index = 0; index < appList4.length; index++) {
let app = appList4.queryElementAt(index, Ci.nsILocalHandlerApp);
if (AppConstants.platform == "win") {
let file = app.executable;
if (file instanceof Ci.nsILocalFileWin) {
try {
buffer += file.getVersionInfoField("FileDescription");
} catch (e) {
}
}
}
buffer += "\n";
}
buffer += "\nEnd\n";
console.log(buffer);
};
const lazy4 = {};
XPCOMUtils.defineLazyServiceGetters(lazy4, {
gMIMEService: ["@mozilla.org/mime;1", "nsIMIMEService"],
});
let mimeInfo4 = lazy4.gMIMEService.getFromTypeAndExtension("text/html", "html");
if (mimeInfo4.hasDefaultHandler) {
console.log(`HasDefaultHandler = true`);
console.log(`Description = ${mimeInfo4.defaultDescription}`);
} else {
console.log(`HasDefaultHandler = false`);
}
let appList4 = mimeInfo4.possibleLocalHandlers || [];
console.log("appList4 = ");
console.log(JSON.stringify(appList4));
printNames(appList4);
}
```
That produces output that can be seen in a pretty form here:
https://docs.google.com/spreadsheets/d/1OvtrZgMlPMJO4Wgu6wwAYvm89orj9HdS_tsDxYn7yrA/edit#gid=0
This does not fix-up things so that all calls to getName() on the LocalHandlerApp are switched to prettyNameAsync. That work is tracked here: https://bugzilla.mozilla.org/show_bug.cgi?id=1884267
Differential Revision: https://phabricator.services.mozilla.com/D203876
This reverts the change from 30cde47f9364e5c7da78fd08fa8ab21737d22399,
and instead re-orders the NS_ERROR_FILE_NOT_FOUND check before
DONT_RETARGET.
Testing suggests that a-download-click-404.html behaviour isn't
impacted, and this improves the handling of this edge-case when doing
process switching.
Differential Revision: https://phabricator.services.mozilla.com/D202007
Some code to exercise this in the browser console:
```
{
const printNames = async (appList) => {
let buffer = "Start:\n";
for (let index = 0; index < appList4.length; index++) {
let app = appList4.queryElementAt(index, Ci.nsILocalHandlerApp);
buffer += app.executable.leafName;
buffer += "\n";
}
buffer += "\n";
for (let index = 0; index < appList4.length; index++) {
let app = appList4.queryElementAt(index, Ci.nsILocalHandlerApp);
let prettyName = await app.prettyNameAsync();
buffer += prettyName;
buffer += "\n";
}
buffer += "\n";
for (let index = 0; index < appList4.length; index++) {
let app = appList4.queryElementAt(index, Ci.nsILocalHandlerApp);
buffer += app.executable.displayName;
buffer += "\n";
}
buffer += "\n";
for (let index = 0; index < appList4.length; index++) {
let app = appList4.queryElementAt(index, Ci.nsILocalHandlerApp);
if (AppConstants.platform == "win") {
let file = app.executable;
if (file instanceof Ci.nsILocalFileWin) {
try {
buffer += file.getVersionInfoField("FileDescription");
} catch (e) {
}
}
}
buffer += "\n";
}
buffer += "\nEnd\n";
console.log(buffer);
};
const lazy4 = {};
XPCOMUtils.defineLazyServiceGetters(lazy4, {
gMIMEService: ["@mozilla.org/mime;1", "nsIMIMEService"],
});
let mimeInfo4 = lazy4.gMIMEService.getFromTypeAndExtension("text/html", "html");
if (mimeInfo4.hasDefaultHandler) {
console.log(`HasDefaultHandler = true`);
console.log(`Description = ${mimeInfo4.defaultDescription}`);
} else {
console.log(`HasDefaultHandler = false`);
}
let appList4 = mimeInfo4.possibleLocalHandlers || [];
console.log("appList4 = ");
console.log(JSON.stringify(appList4));
printNames(appList4);
}
```
That produces output that can be seen in a pretty form here:
https://docs.google.com/spreadsheets/d/1OvtrZgMlPMJO4Wgu6wwAYvm89orj9HdS_tsDxYn7yrA/edit#gid=0
This does not fix-up things so that all calls to getName() on the LocalHandlerApp are switched to prettyNameAsync. That work is tracked here: https://bugzilla.mozilla.org/show_bug.cgi?id=1884267
Differential Revision: https://phabricator.services.mozilla.com/D203876
Added in some code to expose the path to the os default application. Tested via tests on Windows. Mac and Linux will use the nsMIMEInfoImpl which will supply the functionality for them and be tested with the auto-tests.
Differential Revision: https://phabricator.services.mozilla.com/D204306
Some code to exercise this in the browser console:
```
{
const printNames = async (appList) => {
let buffer = "Start:\n";
for (let index = 0; index < appList4.length; index++) {
let app = appList4.queryElementAt(index, Ci.nsILocalHandlerApp);
buffer += app.executable.leafName;
buffer += "\n";
}
buffer += "\n";
for (let index = 0; index < appList4.length; index++) {
let app = appList4.queryElementAt(index, Ci.nsILocalHandlerApp);
let prettyName = await app.prettyNameAsync();
buffer += prettyName;
buffer += "\n";
}
buffer += "\n";
for (let index = 0; index < appList4.length; index++) {
let app = appList4.queryElementAt(index, Ci.nsILocalHandlerApp);
buffer += app.executable.displayName;
buffer += "\n";
}
buffer += "\n";
for (let index = 0; index < appList4.length; index++) {
let app = appList4.queryElementAt(index, Ci.nsILocalHandlerApp);
if (AppConstants.platform == "win") {
let file = app.executable;
if (file instanceof Ci.nsILocalFileWin) {
try {
buffer += file.getVersionInfoField("FileDescription");
} catch (e) {
}
}
}
buffer += "\n";
}
buffer += "\nEnd\n";
console.log(buffer);
};
const lazy4 = {};
XPCOMUtils.defineLazyServiceGetters(lazy4, {
gMIMEService: ["@mozilla.org/mime;1", "nsIMIMEService"],
});
let mimeInfo4 = lazy4.gMIMEService.getFromTypeAndExtension("text/html", "html");
if (mimeInfo4.hasDefaultHandler) {
console.log(`HasDefaultHandler = true`);
console.log(`Description = ${mimeInfo4.defaultDescription}`);
} else {
console.log(`HasDefaultHandler = false`);
}
let appList4 = mimeInfo4.possibleLocalHandlers || [];
console.log("appList4 = ");
console.log(JSON.stringify(appList4));
printNames(appList4);
}
```
That produces output that can be seen in a pretty form here:
https://docs.google.com/spreadsheets/d/1OvtrZgMlPMJO4Wgu6wwAYvm89orj9HdS_tsDxYn7yrA/edit#gid=0
This does not fix-up things so that all calls to getName() on the LocalHandlerApp are switched to prettyNameAsync. That work is tracked here: https://bugzilla.mozilla.org/show_bug.cgi?id=1884267
Differential Revision: https://phabricator.services.mozilla.com/D203876
This patch modifies the behaviour of loads when the DONT_RETARGET
nsIURILoader flag is set, making them ignore the Content-Disposition
header. This means that loads which cannot trigger downloads will
attempt to display handleable content which would otherwise be
downloaded.
This keeps overall behaviour of object/embed elements more similar to
their behaviour pre-Fission, while allowing them to load attachment PDFs
and Images as-if they were being displayed by a plugin.
This patch does not change the existing behaviour around
unknown/unhandleable resource types in object/embed elements.
In Gecko, object/embed elements are prevented from triggering downloads
or external protocol handlers during their initial load. Other browser
engines can trigger a download for an unknown resource type (or
sometimes an attachment resource).
The new pref dom.navigation.object_embed.allow_retargeting can be
enabled to instead trigger a download when loading these resources
within an object/embed element.
Differential Revision: https://phabricator.services.mozilla.com/D201645
This patch adds fetchpriority support for `<link rel=preload as=image>`
and equivalent HTTP Link header. The fetchpriority value is passed from
where the link is parsed down to `NewImageChannel` where the priority
is initially set. Currently, the default equals PRIORITY_LOW, but is
decreased a bit if LOAD_BACKGROUND flag is set (this is always the case
for link preload images, see `imgLoader::LoadImage`). Later, the
priority can be increased again depending on the category (see
`imgRequest::BoostPriority`).
In order to minimize the changes, the new calculation is to keep the
initial setting to PRIORITY_LOW, adjust it using a new
`network.fetchpriority.adjustments.*` preference depending on the
fetchpriority attributes, and then preserve further adjustments for
LOAD_BACKGROUND and `BoostPriority`.
For the default value `fetchpriority=auto`, there is no adjustment
i.e. we continue to start with PRIORITY_LOW. `fetchpriority=low/high`
are respectively mapped to PRIORITY_LOW/PRIORITY_HIGH which is simple
and consistent with the "Image" cases from Google's web.dev article
https://web.dev/articles/fetch-priority. These values could of course
be revised in the future after more experiments.
This change is covered by the following tests below. The expectations
is modified to match what is described above (i.e. map to PRIORITY_LOW
or PRIORITY_HIGH with adjustment due to LOAD_BACKGROUND):
- `link-initial-preload-image.h2.html`
- `link-dynamic-preload-image.h2.html`
- `kPipeHeaderPreloadImageLinks`
Based on a patch by Mirko Brodesser (mbrodesser@igalia.com)
Differential Revision: https://phabricator.services.mozilla.com/D197493
This patch adds fetchpriority support for `<link rel=preload as=image>`
and equivalent HTTP Link header. The fetchpriority value is passed from
where the link is parsed down to `NewImageChannel` where the priority
is initially set. Currently, the default equals PRIORITY_LOW, but is
decreased a bit if LOAD_BACKGROUND flag is set (this is always the case
for link preload images, see `imgLoader::LoadImage`). Later, the
priority can be increased again depending on the category (see
`imgRequest::BoostPriority`).
In order to minimize the changes, the new calculation is to keep the
initial setting to PRIORITY_LOW, adjust it using a new
`network.fetchpriority.adjustments.*` preference depending on the
fetchpriority attributes, and then preserve further adjustments for
LOAD_BACKGROUND and `BoostPriority`.
For the default value `fetchpriority=auto`, there is no adjustment
i.e. we continue to start with PRIORITY_LOW. `fetchpriority=low/high`
are respectively mapped to PRIORITY_LOW/PRIORITY_HIGH which is simple
and consistent with the "Image" cases from Google's web.dev article
https://web.dev/articles/fetch-priority. These values could of course
be revised in the future after more experiments.
This change is covered by the following tests below. The expectations
is modified to match what is described above (i.e. map to PRIORITY_LOW
or PRIORITY_HIGH with adjustment due to LOAD_BACKGROUND):
- `link-initial-preload-image.h2.html`
- `link-dynamic-preload-image.h2.html`
- `kPipeHeaderPreloadImageLinks`
Based on a patch by Mirko Brodesser (mbrodesser@igalia.com)
Differential Revision: https://phabricator.services.mozilla.com/D197493
This patch modifies the behaviour of loads when the DONT_RETARGET
nsIURILoader flag is set, making them ignore the Content-Disposition
header. This means that loads which cannot trigger downloads will
attempt to display handleable content which would otherwise be
downloaded.
This keeps overall behaviour of object/embed elements more similar to
their behaviour pre-Fission, while allowing them to load attachment PDFs
and Images as-if they were being displayed by a plugin.
This patch does not change the existing behaviour around
unknown/unhandleable resource types in object/embed elements.
In Gecko, object/embed elements are prevented from triggering downloads
or external protocol handlers during their initial load. Other browser
engines can trigger a download for an unknown resource type (or
sometimes an attachment resource).
The new pref dom.navigation.object_embed.allow_retargeting can be
enabled to instead trigger a download when loading these resources
within an object/embed element.
Differential Revision: https://phabricator.services.mozilla.com/D201645
This introduces preferences <link rel=preload as=font/fetch>.
See D201997 for the rationale, test coverage and why there is no
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D202047
In bug 1866277 we aligned internal priority of
`<link rel=preload as=fetch>` when `network.fetchpriority` is disabled
with the case of `fetchpriority=auto` (PRIORITY_HIGH), effectively
exposing a behavior change in M124. This commit restores the previous
behavior when `network.fetchpriority` is disabled (PRIORITY_NORMAL)
and instead aligns `fetchpriority=auto` with that value.
Differential Revision: https://phabricator.services.mozilla.com/D201944
This commit aligns the internal priority of <link rel=preload as=fetch>
when fetchpriority support is disabled with the fetchpriority=auto case
when the support is enabled. Also aligns unreachable code in
LinkRelPreloadFetch with that value.
Differential Revision: https://phabricator.services.mozilla.com/D199877
Renames all instances of the snake_case identifier to
camelCase to match more closely to idiomatic JavaScript
and to existing conventions throughout the code base.
Differential Revision: https://phabricator.services.mozilla.com/D198826
This is somewhat complex, untested, never shipped, and predates
fission.
Remove it to simplify the code.
Depends on D198183
Differential Revision: https://phabricator.services.mozilla.com/D198184
Previously it may have been possible in some edge cases for us to send
`MaybeFireEmbedderLoadEvents` for a non-toplevel frame during docshell
tree teardown.
Differential Revision: https://phabricator.services.mozilla.com/D197825
This adds code to emit ETW markers on windows. It supports all current
markers through a generic marker emitting schema. It also supports
additional payload and filtering for any markers that are updated to a
new compile-time marker schema system. Because of our abstraction layer
and cross-platform nature we have to manually create the TraceLogging
structs used and can't rely on their macro's, but this should give us a
very flexible and performant marker implementation on ETW.
Differential Revision: https://phabricator.services.mozilla.com/D196331
Previously, for `rel=preload as=fetch`, the internal priority,
`nsISupportsPriority`, was not adjusted. Now, the adjustment happens in
`FetchPreloader::CreateChannel`.
For `rel=preload as=font`, previously, the internal priority was always
set to high in `FontLoaderUtils::BuildChannelSetup`. Now, the internal
priority is a parameter, whose value potentially depends on the
`fetchpriority` attribute.
Note the minor correction of calling `SetPriority` instead of
`AdjustPriority` in `FontLoaderUtils::BuildChannelSetup`.
Differential Revision: https://phabricator.services.mozilla.com/D194205
