Prior to this patch, PDF.js tracks both its own 'disabled' pref (which is used
by enterprise policy) and whether it is the default handler per the handler
service - but it tracks both in one bool, which determines whether its
streamconverter registers.
Really, what we want is to never use PDF.js if it's preffed off.
However, if there is some other default, it should be acceptable to use PDF.js
in some circumstances, like for <embed> or <object>s where otherwise we
would show no content at all.
Even for toplevel PDFs, if the user has configured Firefox to open PDFs in
an external helper app which is Firefox (which is currently an easy mistake
to make in the unknownContentType dialog), or has it set to the OS default,
but has changed their OS default to Firefox, we really still want to open
those PDFs with PDF.js.
This patch fixes all of this by splitting out the pref tracking from the
handler state tracking. Only the pref will completely disable PDF.js.
Then, in the streamconverter code, we check whether PDF.js should be used for
PDFs, and if there's a misconfiguration that we can correct. This code is
invoked from the parent process when we load PDFs in frames or toplevel
documents, and will prevent us from invoking PDF.js in the child if the user
would prefer that not to happen.
As a driveby, this cleans up how we track the pref inside PDF.js, and how we
get notified of changes to the handler - we were missing changes made in the
unknown content type dialog, so it seemed worth making it generic.
Differential Revision: https://phabricator.services.mozilla.com/D73510
This also renames `saveToDisk` to the more accurate `promptForSaveDestination`
given that it doesn't actually do the saving itself.
Differential Revision: https://phabricator.services.mozilla.com/D73507
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- No support for ICC profiles (bug 1634741)
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's __attribute__((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
I also needed to wrap the nsDocLoader::RemoveChildLoader() function declaration with // clang-format off and // clang-format on. clang-format insists on indenting the function declaration because it is confused by the NS_DECL_ macros without trailing semicolons before the [[nodiscard]] attribute.
Differential Revision: https://phabricator.services.mozilla.com/D70478
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
This fixes 1597154 because the lists of URIs here and in nsDocShell now
match.
Note that they don't exactly match, there's an exception for about:newtab
which we'll fix in a follow-up bug.
Differential Revision: https://phabricator.services.mozilla.com/D69136
--HG--
extra : moz-landing-system : lando
It's only used to check whether the docshell is gone already, and we need to
deal with that in other places anyway. No other useful implementation.
In comm-central there are a couple, but they're useless too.
Differential Revision: https://phabricator.services.mozilla.com/D68731
--HG--
extra : moz-landing-system : lando
We use `ShellExecuteByExplorer` to open a uri because applications may not
support the mitigation policies inherited from our process.
Unlike Firefox, Thunderbird runs `ShellExecuteByExplorer` to launch a browser
to open an HTTP/HTTPS uri. If a uri includes credentials like
http://user:password@domain.com/, `ShellExecuteByExplorer` succceds, but
explorer.exe refuses to open the uri by design. In this case the fallback to
`ShellExecuteExW` does not happen because the API is async and no error is
returned
The proposed fix is to skip `ShellExecuteByExplorer` if it's Thunderbird.
Because Thunderbird does not apply additional mitigation policies which may
cause compat issues, we don't need to run `ShellExecuteByExplorer` in the
first place.
Differential Revision: https://phabricator.services.mozilla.com/D67339
--HG--
extra : moz-landing-system : lando
Only 3 callers are using a non-UTF-8 charset as the first parameter.
* MediaDocument.cpp: This does not make sense because the "filename" part of
URLs will always be encoded with UTF-8.
* nsContextMenu.js: This is wrong because "mailto:" URLs don't care about the
document charset.
* Finder.jsm: This caused bug 1623222.
Differential Revision: https://phabricator.services.mozilla.com/D67386
--HG--
extra : moz-landing-system : lando
Note that this also suppresses notifications from the initial about:blank in the new process, and updates the tabbrowser to not expect those.
Differential Revision: https://phabricator.services.mozilla.com/D65923
--HG--
extra : moz-landing-system : lando
If a system uses a custom shell instead of Windows Explorer,
`ShellExecuteByExplorer` always fails because it relies on explorer.exe,
but `ShellExecute` stil works because it's in-proc implementation.
We added a fallback for a local file to address Bug 1602726. This patch adds
a fallback for a uri.
Differential Revision: https://phabricator.services.mozilla.com/D63095
--HG--
extra : moz-landing-system : lando
This also fixes the Window lookup in nsExternalAppHandler, which was the reason for previously needing the process-top BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D64910
--HG--
extra : moz-landing-system : lando
Given that we are going to add ContentBlockingAllowList in
CookieSettings, so CookieSettings will be responsible for more stuff than the
cookie behavior and cookie permission. We should use a proper name to
reflect the purpose of it. The name 'CookieSettings' is misleading that
this is only for cookie related stuff. So, we decide to rename
'CookieSettins' to 'CookieJarSettings' which serves better meaning here.
Differential Revision: https://phabricator.services.mozilla.com/D63935
--HG--
rename : netwerk/cookie/CookieSettings.cpp => netwerk/cookie/CookieJarSettings.cpp
rename : netwerk/cookie/nsICookieSettings.idl => netwerk/cookie/nsICookieJarSettings.idl
extra : moz-landing-system : lando
This covers most cycle collected objects which support weak references, but
not the ones which inherit from a cycle collected class and don't do any cycle
collection on their own.
Differential Revision: https://phabricator.services.mozilla.com/D63962
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
Thunderbird has no default handlers so test_check_defaults_get_added does
nothing and test_check_default_modification fails looking for a mailto handler.
Differential Revision: https://phabricator.services.mozilla.com/D62525
--HG--
extra : moz-landing-system : lando
And fix a bunch of fallout as we now don't include nsDocShell.h everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D62169
--HG--
extra : moz-landing-system : lando
The getDefaultFileName helper function does its own filename parsing using header info
it has previously 'manually' retrieved, so it needs to manually unescape its input.
Meanwhile, NS_GetFilenameFromDisposition is used by webbrowserpersist and for
the title of documents, and so updating that helps ensure better UI as well as
correct filename suggestions when saving from the context menu.
Differential Revision: https://phabricator.services.mozilla.com/D61734
--HG--
rename : accessible/tests/mochitest/moz.png => uriloader/exthandler/tests/mochitest/file_with@@funny_name.png
rename : toolkit/components/mediasniffer/test/unit/data/file.webm => uriloader/exthandler/tests/mochitest/file_with[funny_name.webm
extra : moz-landing-system : lando
The following methods are removed:
1. notifyChannelClassifierProtectionDisabled
2. notifyCookieAllowed
3. notifyCookieBlocked
Depends on D56875
Differential Revision: https://phabricator.services.mozilla.com/D57630
--HG--
extra : moz-landing-system : lando
At this point, there is no consumer that uses ContentBlockingLog stored
in the child. This patch removes the following code:
1. Removing nsGlobalWindowOuter::NotifyContentBlockingEvent
2. Removing nsDocLoader::OnContentBlockingEvent
3. Removing contentBlockingEvent in nsISecureBrowserUI.idl
4. Removing mContentBlockingLog from Document.cpp and APIs related to it.
Differential Revision: https://phabricator.services.mozilla.com/D56874
--HG--
extra : moz-landing-system : lando
The following methods are removed:
1. notifyChannelClassifierProtectionDisabled
2. notifyCookieAllowed
3. notifyCookieBlocked
Depends on D56875
Differential Revision: https://phabricator.services.mozilla.com/D57630
--HG--
extra : moz-landing-system : lando
At this point, there is no consumer that uses ContentBlockingLog stored
in the child. This patch removes the following code:
1. Removing nsGlobalWindowOuter::NotifyContentBlockingEvent
2. Removing nsDocLoader::OnContentBlockingEvent
3. Removing contentBlockingEvent in nsISecureBrowserUI.idl
4. Removing mContentBlockingLog from Document.cpp and APIs related to it.
Differential Revision: https://phabricator.services.mozilla.com/D56874
--HG--
extra : moz-landing-system : lando
We currently fail to offer 'open with' options for application/zip mimetype
.zip files, because out of the box, the Windows registry does not contain
mimetype entries for application/zip. In fact, it contains comparatively
few entries, and right now we bail out with an empty mime info object if
we cannot find the server-provided mimetype in the registry (or cannot
find an associated extension for that mimetype).
Prior to the changes from bug 1597985, we would first try to find a handler
based on the default extension for the mimetype, and used the file extension
if that failed.
The changes in this commit will cause us to fetch the default file extension
for the mimetype, but continue with the provided extension if no mimetype
information is available, restoring functionality in the case where Windows
has no mimetype information.
Differential Revision: https://phabricator.services.mozilla.com/D60139
--HG--
extra : moz-landing-system : lando
It turned out that `ShellExecuteByExplorer` does not work on VDI such as Citrix
or Microsoft RemoteApp. This patch adds a fallback to the original launching
code if `ShellExecuteByExplorer` fails. This will be a temporary solution until
we find out a way to solve both interop issues `PreferSystem32Images` and VDI.
Differential Revision: https://phabricator.services.mozilla.com/D58054
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
A fix for Bug 1588975 replaced the call to `LaunchWithIProcess` in
`nsMIMEInfoWin::LaunchWithFile` with the call to `ShellExecuteWithIFile` to use
`mozilla::ShellExecuteByExplorer`. This caused a regression that if a filepath
contains whitespaces, we pass it to a target application without quoting it
while the old codepath `ShellExecuteWithIFile` quoted a path accordingly in
`assembleCmdLine`.
A proposed fix is to quote a path in the same way as `assembleCmdLine` does.
This patch also moves `assembleCmdLine` to an exported header so that we can add
a unittest to cover both of `assembleCmdLine` and a new function
`assembleSingleArgument. It would be better to refactor these functions in the
future because many lines are duplicated.
Differential Revision: https://phabricator.services.mozilla.com/D56646
--HG--
extra : moz-landing-system : lando
Previously, GetCancelled() would have return true should the channel's status was an error.
Doing Cancel(NS_OK) for example, would have made a follow-up call to GetCancelled() return false. However, we can assert that such a call would have been a bug.
Following this change GetCancelled() will only return true if Cancel() was explicitly called.
Differential Revision: https://phabricator.services.mozilla.com/D55401
--HG--
extra : moz-landing-system : lando
There is no functional change with this commit. The default implementation for GetCanceled() is still to check if the status code is a failure.
However, it can be argued that as you had to call Cancel() on the nsIChannel, having to check the nsIHttpChannelInternal interface to determine if you had been canceled in the past was rather a non obvious path.
It makes more sense to check the nsIChannel interface to determine if it's been canceled already and this allows for finer granularity if needed in the future.
Differential Revision: https://phabricator.services.mozilla.com/D55268
--HG--
extra : moz-landing-system : lando
Previously, GetCancelled() would have return true should the channel's status was an error.
Doing Cancel(NS_OK) for example, would have made a follow-up call to GetCancelled() return false. However, we can assert that such a call would have been a bug.
Following this change GetCancelled() will only return true if Cancel() was explicitly called.
Differential Revision: https://phabricator.services.mozilla.com/D55401
--HG--
extra : moz-landing-system : lando
There is no functional change with this commit. The default implementation for GetCanceled() is still to check if the status code is a failure.
However, it can be argued that as you had to call Cancel() on the nsIChannel, having to check the nsIHttpChannelInternal interface to determine if you had been canceled in the past was rather a non obvious path.
It makes more sense to check the nsIChannel interface to determine if it's been canceled already and this allows for finer granularity if needed in the future.
Differential Revision: https://phabricator.services.mozilla.com/D55268
--HG--
extra : moz-landing-system : lando
The only time we fire OnStart/StopRequest from nsExtProtocolChannel is when we cancel with NS_ERROR_NO_CONTENT, which DocumentLoadListener explicitly handles to avoid calling Suspend (which asserts).
Unfortunately we fire OnStart/StopRequest from a runnable, so it's possible for the channel to get Cancelled by something else in the middle. This Cancel doesn't really work, since we've already dispatched to the handler, so don't update mStatus.
Depends on D57030
Differential Revision: https://phabricator.services.mozilla.com/D57032
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
Most of these fixes involve fixing test XUL to not use <dialog> as a top level element or replacing calls to document.documentElement that expect it to return the dialog, now that the dialog is not the top level element anymore.
Differential Revision: https://phabricator.services.mozilla.com/D53722
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--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
This is an initial implementation of this idea that works on mac.
I've added a Windows implementation in another commit in this stack. I'll
look at a Linux one in a follow-up bug. I do not think we need them in the
child process implementation or on Android.
Effectively, this makes nsIHandlerInfo::LaunchWithURI() fall back to asking if
the handler info points to the OS default and that's us, or if it points to
a helper app and that's us. The latter is fairly easy to check, but the former,
more common case, is actually annoying - there don't seem to be APIs on the
external helper app service or the handler service that provide any information
about the app that's currently the default. So despite my belief that these
interfaces have too many methods that all do very similar things, and what we
need is fewer interfaces with fewer methods, I added another one...
For this mac implementation, I'm comparing bundle URLs and added newer API
usage for 10.10 and later to avoid deprecation warnings. I've not changed
the mac shell service as it uses bundle identifiers to check if we're the
default.
Another way of fixing these issues would be to complain about things when we
receive these URIs from external parties and our own config says that we will
just hand them to someone else. I decided not to do so because we end up with
at least one of the following problems:
- if we implement in BrowserContentHandler, that won't help for
PWAs/Thunderbird
- if we try to implement in the external protocol handler, we'd need to start
passing load flag information through to lots of checks.
- it wouldn't stop the recursion until we've already done one round of
it for links that are in webpages, which seems suboptimal (ie, if you
clicked a mailto: link on a webpage it'd go to the OS with that mailto link
and only realize something's awry when we've gone back through the OS to us,
rather than straightaway).
If we wanted to, we could add a fix like that in belt-and-suspenders fashion.
Differential Revision: https://phabricator.services.mozilla.com/D48742
--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
The signatureInfo that has been used in ExternalHelperAppService and
ReputationService has been stored Array of nsIX509CertList, which
isn't necessary because only the raw bytes of the certs are required.
This patch intends to remove the usage of nsIX509CertList and store
the raw bytes directly.
Differential Revision: https://phabricator.services.mozilla.com/D44243
--HG--
extra : moz-landing-system : lando
The launcher process turns on the `PreferSystem32Images` mitigation policy for
the browser process. Since the mitigation policy is inherited, a process launched
by the browser process also has `PreferSystem32Images`. If an application which
does not support `PreferSystem32Images`, such as Skype for Business, is launched
via a hyperlink, a custom uri, or a downloaded file, it would fail to launch.
Bug 1567614 fixed this issue by introducing `mozilla::ShellExecuteByExplorer` to
`nsMIMEInfoWin::LoadUriInternal`. This patch introduces
`mozilla::ShellExecuteByExplorer` to two more places.
1. xul!nsLocalFile::Launch
This is invoked when a user opens a file from the Download Library, or a user
opens a downloaded file with the default application without saving it.
2. xul!nsMIMEInfoWin::LaunchWithFile
This is invoked when a user opens a downloaded file with a custom application
(configured in about:preference) without saving it.
*Why does this patch change worker.js?*
The mochitest dom/tests/browser/browser_test_new_window_from_content.js failed
if it was executed after dom/serviceworkers/test/browser_download.js in the
same batch. This was because browser_download.js launched Notepad to open
fake_download.bin.txt, preventing a new window from being opened in the
foreground in browser_test_new_window_from_content.js.
The test browser_download.js can verify downloaded data without opening an
associated application. So this patch adds the content-type to the response
header in order not to open Notepad on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D52567
--HG--
extra : moz-landing-system : lando
This also converts MaybeCloseWindowHelper, and results in the window close operations being always run in the parent (even without DocumentChannel).
Differential Revision: https://phabricator.services.mozilla.com/D49528
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--HG--
extra : moz-landing-system : lando
For launching with an external protocol handler on Windows, we validate a uri
before sending it to `ShellExecute`, by converting a string into `PIDL` using
`SHParseDisplayName` and extract a string back from PIDL using
`IShellFolder::GetDisplayNameOf`. The problem was that if a fragment, a
string following a hash mark (#), is always dropped after this validation.
This is caused by the intended design of Windows.
A proposed fix is to use `CreateUri` for validation, which is used behind
`IShellFolder::GetDisplayNameOf`. However, we also keep `SHParseDisplayName`
because there are cases where `CreateUri` succeeds while `SHParseDisplayName`
fails such as a non-existent `file:` uri and we want to keep the same
validation result for those cases.
Adding `CreateUri` broke MinGW build because of our toolkit issue. We use
dynamic linking for MinGW build in the meantime.
This patch adds a new unittest to make sure the new validation logic
behaves the same as the old one except the fragment issue.
Differential Revision: https://phabricator.services.mozilla.com/D42041
--HG--
extra : moz-landing-system : lando
For launching with an external protocol handler on Windows, we validate a uri
before sending it to `ShellExecute`, by converting a string into `PIDL` using
`SHParseDisplayName` and extract a string back from PIDL using
`IShellFolder::GetDisplayNameOf`. The problem was that if a fragment, a
string following a hash mark (#), is always dropped after this validation.
This is caused by the intended design of Windows.
A proposed fix is to use `CreateUri` for validation, which is used behind
`IShellFolder::GetDisplayNameOf`. However, we also keep `SHParseDisplayName`
because there are cases where `CreateUri` succeeds while `SHParseDisplayName`
fails such as a non-existent `file:` uri and we want to keep the same
validation result for those cases.
This patch adds a new unittest to make sure the new validation logic
behaves the same as the old one except the fragment issue.
Differential Revision: https://phabricator.services.mozilla.com/D42041
--HG--
extra : moz-landing-system : lando
This allows us to actually correctly load URIs into and return BCs for
cross-process named targets. It still leaves a lot of code which needs to
operate directly on DocShells, but it only applies to new windows, which
always start out same-process.
The one exception is the logic to change the opener of an existing
cross-process window targeted by an open() operation, which can't currently be
accomplished outside of the BC's owner process. This will need a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D40501
--HG--
extra : rebase_source : 15ecef471ac27283861c2d3b87afeb1458bbf788
extra : histedit_source : 6801b42f81babd308b6f1791964518d9d73b19ee
Converts dom.largeAllocation.testing.allHttpLoads varcache pref to a static pref.
Differential Revision: https://phabricator.services.mozilla.com/D40716
--HG--
extra : moz-landing-system : lando
This functionality is currently unused, and blocks work needed to support
Fission.
Differential Revision: https://phabricator.services.mozilla.com/D39542
--HG--
extra : rebase_source : 1d8fdea73d48c714112d13844f5110f7f1892dda
They're infallible in practice and always `NS_OK`. (This stems from
`AddVarCacheNoAssignment()` always returning `NS_OK`.)
As a result, the commit removes lots of unnecessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D39804
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Now that we have built up the required primatives in previous patches, this
patch simply replaces the previous code with a new version that uses the new
APIs from ShellHeaderOnlyUtils.h.
Differential Revision: https://phabricator.services.mozilla.com/D38945
--HG--
extra : moz-landing-system : lando
My preference was to annotate most of the failing tests with `fail-if` so that
if they start passing, the `fail-if` needs to be removed and they need to keep
passing. That doesn't work for tests that timeout, or which trigger failures
from their cleanup functions, however, so those tests need skip-if. And tests
with fail in their cleanup functions likely leave the browser in an
inconsistent state for subsequent tests, anyway, so really should be skipped
regardless.
There are some remaining tests which still fail because of crashes. I chose
not to skip them here, but to fix the crashes in separate bugs instead.
Differential Revision: https://phabricator.services.mozilla.com/D38247
--HG--
extra : rebase_source : 39ba8fec2e882cfe577c5f2b58ab7e4b461f1178
This patch adds the ability to load cross domain iframes in the
background to make the top level documents finish earlier.
This is an experiment feature that we'll keep it disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D24938
--HG--
extra : moz-landing-system : lando
This error code indicates the specific case where the antitracking backend
rejects a particular access request because the resource is third-party and
the cookie policy mandates that third-party resources must be partitioned.
Differential Revision: https://phabricator.services.mozilla.com/D29737
--HG--
extra : moz-landing-system : lando
Honza Bambas
Geoff Lankow
Edgar Chen
Gijs Kruitbosch
Ian Moody
Jon Bauman
Simon Giesecke
Razvan Maries
Bogdan Tara
sagudev
Jean-Yves Avenard
Matt Woodrow
Cosmin Sabou
Noemi Erli
Sebastian Streich
Kagami Sascha Rosylight
Chris Peterson
Dylan Roeh
Emilio Cobos Álvarez
Eric Rahm
Christoph Kerschbaumer
Paul Bone
sonakshi
Mihai Alexandru Michis
Toshihito Kikuchi
Andrea Marchesini
Masatoshi Kimura
Coroiu Cristina
Boris Zbarsky
Marco Bonardo
Sylvestre Ledru
Mark Banner
Tim Huang
Kris Maglione
Andreea Pavel
Dorel Luca
shindli
Eugen Sawin
Narcis Beleuzu
Dimi Lee
Brindusan Cristian
Zibi Braniecki
Valentin Gosu
Jonathan Kingston
Emma Malysz
Oana Pop Rus
Kirk Steuber
Tom Ritter
Daniel Varga
Gabriele Svelto
Sean Feng
Gurzau Raul
Ehsan Akhgari
Tom Schuster
Dave Townsend
Nihanth Subramanya
Nick Alexander
Jonathan Watt
Henri Sivonen
Paul Zuehlcke
arthur.iakab
Sebastian Hengst
Nika Layzell
Mike Hommey
Kristen Wright
Nicholas Nethercote
Kannan Vijayan
Aaron Klotz
Thomas Nguyen
Michal Novotny
Victor Porof