This is the skeleton for interacting with the Windows Task Scheduler, it
produces an exe that can register and unregister itself as a scheduled
task.
The schedule is to run once daily. Bug 1568287 is reserved for discussions
of other trigger patterns, possibly depending on the channel.
This uses a the Windows Event Log for logging, Bug 1343676 deals with
possibly extending that to a rotating log file.
Differential Revision: https://phabricator.services.mozilla.com/D35507
--HG--
extra : moz-landing-system : lando
This patch does the following:
* Moves most logic for initiating about:home / about:newtab into AboutNewTab.jsm
* Makes AboutNewTab the API surface for overriding the default about:newtab URLs.
* Reduces the surface of nsIAboutNewTabService, and makes the properties read-only
* Splits the remaining code in the nsIAboutNewTabService into an implementation for
the parent process, and one for content processes.
This split will hopefully help reduce confusion about which code in
AboutNewTabService is running in which process.
Differential Revision: https://phabricator.services.mozilla.com/D65569
--HG--
rename : browser/components/newtab/test/xpcshell/test_AboutNewTabService.js => browser/components/newtab/test/xpcshell/test_AboutNewTab.js
extra : moz-landing-system : lando
This patch does the following:
* Moves most logic for initiating about:home / about:newtab into AboutNewTab.jsm
* Makes AboutNewTab the API surface for overriding the default about:newtab URLs.
* Reduces the surface of nsIAboutNewTabService, and makes the properties read-only
* Splits the remaining code in the nsIAboutNewTabService into an implementation for
the parent process, and one for content processes.
This split will hopefully help reduce confusion about which code in
AboutNewTabService is running in which process.
Differential Revision: https://phabricator.services.mozilla.com/D65569
--HG--
rename : browser/components/newtab/test/xpcshell/test_AboutNewTabService.js => browser/components/newtab/test/xpcshell/test_AboutNewTab.js
extra : moz-landing-system : lando
For test_protocol_stack we now generate a different function name like
onConnect/>. This happens because the test doesn't execute with strict mode
anymore, which would inhibit lazy parsing. With lazy parsing we get
different function naming ..
option("strict") will throw now.
Differential Revision: https://phabricator.services.mozilla.com/D65833
--HG--
extra : moz-landing-system : lando
This patch doesn't make ContentBlocking::AllowAccessFor fission
compatible. This is more like a prerequisite work.
Differential Revision: https://phabricator.services.mozilla.com/D65729
--HG--
extra : moz-landing-system : lando
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
The test was originally using BrowserTestUtils.waitForNewWindow with an argument for
the expected initial tab URL which was a function rather than a string. This helper
function never expects a function, but transparently passed it along to browserLoaded,
which _can_ handle a function, so everything worked.
With the privileged about content process enabled, the waitForNewWindow code fell
down a codepath that doesn't handle the function parameter at all, and causes the
test to wait for a XULFrameLoaderCreated event that will never fire.
This patch adjusts the test to no longer pass the function to waitForNewWindow, since
it never supported having a function passed to it. Instead, we do the check for the
initial tab URL after the window has been opened.
Differential Revision: https://phabricator.services.mozilla.com/D64603
--HG--
extra : moz-landing-system : lando
Add a new label to collect the number of BFCached documents that are not
the only top level documents in their BrowsingContextGroup.
Differential Revision: https://phabricator.services.mozilla.com/D65790
--HG--
extra : moz-landing-system : lando
Handle rfc822Name and iPAddress subjectAltNames, and replace "[object
Object]" with an explicit "unsupported" string for otherName.
Differential Revision: https://phabricator.services.mozilla.com/D65749
--HG--
extra : moz-landing-system : lando
This removes the obsolete backend. Notes on some of the less obvious changes
made as part of this patch:
- some of the gFoo style getters in Blocklist.jsm were only used by the XML
version of the blocklist; I've removed them and tried to remove spurious
settings of those properties in the remaining tests.
- some utility methods (e.g. distribution information getters) were also only
used for the XML version (for the update URL).
- it's no longer necessary to test switching implementations.
- in browser/base/content/test/plugins/, we ran some tests from two manifests
in order to run them with both blocklist backends. The simplest way of
reducing this back down to one was to remove the remote-settings one. If I'd
been more future-oriented when I created the duplication, perhaps I would
have moved the XML version out into a different manifest instead, but I
didn't, so now it looks like we're removing the modern one, whereas really
we're going to be running the modern one as part of the "normal" tests and
we're no longer running the "old" tests.
- removed all mentions I could see of extensions.blocklist.url which is no
longer used for anything.
- per https://bugzilla.mozilla.org/show_bug.cgi?id=1016555#c23, updated
references for the OneCRL timing and how it relates to blocklist updates.
Differential Revision: https://phabricator.services.mozilla.com/D64933
--HG--
extra : moz-landing-system : lando
Bug 1603714 showed there were `UntrustedModulesData` instances in which a load
event pointed to a module which did not exist in the modules list.
This patch adds `MOZ_DIAGNOSTIC_ASSERT` to the following places to narrow down
when it happened.
Given that the number of the impected users seems big (~200 crashes/day on Nightly),
we activate the assers with a probability of 1/16 (~12.5 crashes/day).
1. When processing load events
1-1. [Content] `UntrustedModulesProcessor::CompleteProcessing:`
Verify events of a trusted module were eliminated by `GetModulesTrust`
1-2. [Content] `UntrustedModulesData::AddNewLoads`:
Verify a new `ModuleRecord` matches the event
1-3. [Content] `UntrustedModulesProcessor::CompleteProcessing`:
Verify processed data after new items were appended.
2. When processed data is sent
2-1. [Content] `UntrustedModulesProcessor::GetAllProcessedData`:
Verify processed data before serialization.
2-2. [Content] `ParamTraits<mozilla::UntrustedModulesData>::WriteEvent`:
Verify processed data before transferring to the browser process
2-3. [Browser] `ParamTraits<mozilla::UntrustedModulesData>::ReadEvent`:
A final point to catch this integrity problem. We had an IPC error here.
Differential Revision: https://phabricator.services.mozilla.com/D59964
--HG--
extra : moz-landing-system : lando
If an addon is updated and moves permissions between required to optional, we
want to retain the previously granted permission so the extension does not have to
request the permission from the user again. We also handle permission removal
and changes to preferences based on permissions.
Differential Revision: https://phabricator.services.mozilla.com/D64696
--HG--
extra : moz-landing-system : lando
Bug 1603714 showed there were `UntrustedModulesData` instances in which a load
event pointed to a module which did not exist in the modules list.
This patch adds `MOZ_DIAGNOSTIC_ASSERT` to the following places to narrow down
when it happened.
Given that the number of the impected users seems big (~200 crashes/day on Nightly),
we activate the assers with a probability of 1/16 (~12.5 crashes/day).
1. When processing load events
1-1. [Content] `UntrustedModulesProcessor::CompleteProcessing:`
Verify events of a trusted module were eliminated by `GetModulesTrust`
1-2. [Content] `UntrustedModulesData::AddNewLoads`:
Verify a new `ModuleRecord` matches the event
1-3. [Content] `UntrustedModulesProcessor::CompleteProcessing`:
Verify processed data after new items were appended.
2. When processed data is sent
2-1. [Content] `UntrustedModulesProcessor::GetAllProcessedData`:
Verify processed data before serialization.
2-2. [Content] `ParamTraits<mozilla::UntrustedModulesData>::WriteEvent`:
Verify processed data before transferring to the browser process
2-3. [Browser] `ParamTraits<mozilla::UntrustedModulesData>::ReadEvent`:
A final point to catch this integrity problem. We had an IPC error here.
Differential Revision: https://phabricator.services.mozilla.com/D59964
--HG--
extra : moz-landing-system : lando
* Dont flag a form as user-modified when the input is from autofilling a login
* Avoid sending PasswordEditedOrGenerated messages to the parent from non-user-modified forms.
Differential Revision: https://phabricator.services.mozilla.com/D65668
--HG--
extra : moz-landing-system : lando
Abort it before writing the cache to avoid potentially writing a incomplete cache.
Differential Revision: https://phabricator.services.mozilla.com/D65723
--HG--
extra : moz-landing-system : lando
Expire favicons older than 6 months when:
* they are for permanently redirecting urls, that are unlikely to receive
updated favicons
* they are for urls with refs (often mail, docs) that have a fallback root
favicon for their origin
Expiration happens in chunks, mostly on idle-daily.
Differential Revision: https://phabricator.services.mozilla.com/D65308
--HG--
extra : moz-landing-system : lando
This also bumps the cache version numbers, because we currently need to cache the telemetry id as part of the engine info.
Differential Revision: https://phabricator.services.mozilla.com/D65134
--HG--
extra : moz-landing-system : lando
These methods were used for media control and audio focus on Fennec, and we don't need them anymore.
Differential Revision: https://phabricator.services.mozilla.com/D65262
--HG--
extra : moz-landing-system : lando
These tests are used to test `SUSPENDED_PAUSE`, which is used for the old audio focus mechanism on Fennec, and `SUSPENDED_PAUSE_DISPOSABLE`, which is used for the media control on Fennec.
As we don't use them anymore, we can remove these tests.
Differential Revision: https://phabricator.services.mozilla.com/D65261
--HG--
extra : moz-landing-system : lando
With this and all the previous changes, the necessary mozconfig for
local cross-builds only contains DIA_SDK_PATH, WINDOWSSDKDIR and
--target.
Differential Revision: https://phabricator.services.mozilla.com/D65295
--HG--
extra : moz-landing-system : lando
This should be less confusing. This is not supported outside of chrome:// or
user-agent stylesheets so we can name this however we want.
Differential Revision: https://phabricator.services.mozilla.com/D65605
--HG--
extra : moz-landing-system : lando
The telemetry session ID annotation is only used to correlate crash pings with
main pings, it does not need to be sent along with crash reports as we have no
use for it there.
Differential Revision: https://phabricator.services.mozilla.com/D65446
--HG--
extra : moz-landing-system : lando
The signatures are used for Firefox's FIPS mode. But they are actually
mostly a longstanding lie: people interested in the FIPS mode ought to
use a FIPS-validated version of the affected NSS libraries, and the last
validated version is now more than 10 years old. Needless to say,
Firefox doesn't ship anything close to the validated version anymore.
Furthermore, at the moment, the build system doesn't support generating
these signature while cross compiling. We have been cross compiling
Firefox for Mac for 5 years give or take, which means it hasn't been
possible to enable FIPS mode in Firefox on Mac out of the box for that
long.
As we are moving towards cross compiling for Windows, the question
whether we should keep those signatures has risen again. And if we're
going to remove them for the cross compiled platforms, we might as well
remove them everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D65468
--HG--
extra : moz-landing-system : lando
This patch prevents the URL formatter from setting empty values for distribution data.
Differential Revision: https://phabricator.services.mozilla.com/D65368
--HG--
extra : moz-landing-system : lando