This includes improvements to the Linux exception handler that will provide
crash addresse for a number of signals by reading the NT_SIGINFO structure and
quites warnings in a number of files. This also removes an unused header.
Differential Revision: https://phabricator.services.mozilla.com/D26488
--HG--
extra : moz-landing-system : lando
There shouldn't be any need to do this for content processes as
the DLL should already be in the system file cache.
Differential Revision: https://phabricator.services.mozilla.com/D26017
--HG--
extra : moz-landing-system : lando
nsBrowserStatusFilter is updated to not filter out STATE_IS_REDIRECTED_DOCUMENT.
The test here is adding a way to have a "login form" do a post to a server script, which then does a 303 redirect. This mimics what some services, including LinkedIn do during this stage.
Differential Revision: https://phabricator.services.mozilla.com/D26969
--HG--
extra : moz-landing-system : lando
After calling Lookup API per table, Safe Browsing outputs too many debug
message for a single URL lookup. Refine the current output.
Differential Revision: https://phabricator.services.mozilla.com/D27066
--HG--
extra : moz-landing-system : lando
`Async.jankYielder` is known to, unfortunately, cause jank by creating a lot of
immediately resolved promises that must be then GCed. For a collection of 50
items, it will create 50 promises and 49 of them will immediately resolve.
Instead of `Async.jankYielder`, we now have `Async.yieldState`, which simply
keeps track of whether or not the caller should yield to the event loop. Two
higher level looping constructs are built on top of it:
* `Async.yieldingIterator`, which has been rewritten to not create extraneous
promises; and
* `Async.yieldingForEach`, which is a replacement for awaiting
`Async.jankYielder` in a loop. Instead, it accepts the loop body as a
function.
Each of these can share an instance of an `Async.yieldState`, which allows an
object with multiple loops to yield every N iterations overall, instead of
every N iterations of each loop, which keeps the behaviour of using one
`Async.jankYielders` in multiple places.
Differential Revision: https://phabricator.services.mozilla.com/D26229
--HG--
extra : moz-landing-system : lando
randomly choose 1% users and their 0.14% page view to measure content blocking.
Differential Revision: https://phabricator.services.mozilla.com/D26130
--HG--
extra : moz-landing-system : lando
We don't need an additional array just for byte reordering, replace
it with in-place processing.
Testcase are modified because the LookupCacheV4::Build API now clears the
input parameter.
Differential Revision: https://phabricator.services.mozilla.com/D26861
--HG--
extra : moz-landing-system : lando
Here is the flow how prefixes are handled during an V4 update:
1. Prefixes are received from Safe Browsing update, stored in ProtocolBuffer
2. Copy the prefixes from ProtocolBuffer to TableUpdate structure
3. Prefixes in TableUpdate are merged with local prefixes (stored in LookupCacheV4)
4. Merged prefixes are processes by PrefixSet to generate the in-memory prefix
set data structure (MakePrefixSet).
In this patch, we free the prefixes stored in TableUpdate right after step3.
This reduces the peak memory used during an update (peak happens in step 4).
Differential Revision: https://phabricator.services.mozilla.com/D26860
--HG--
extra : moz-landing-system : lando
In particular, this enables Marionette in local Fennec builds, which
were the only place it wasn't enabled by default. (Automation builds
all enabled Marionette.) That default is getting in the way of the
Performance Team (and others!) testing GeckoView-based products
easily.
Differential Revision: https://phabricator.services.mozilla.com/D26815
--HG--
extra : moz-landing-system : lando
We also take account those values in the case of `Find in page`.
The corresponding web platform tests will be coming from this PR.
https://github.com/web-platform-tests/wpt/pull/8575
Though some of them will not be passed, the failure reason is not related
to this change, I will take a look when the PR gets merged into mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D25915
--HG--
extra : moz-landing-system : lando
In the case where scroll-snap-type is specified for the scroll container, the
scroll-padding is also factored into in ScrollFrameHelper::ComputeScrollSnapInfo
which is called via ScrollFrameHelper::ScrollToWithOrigin. It doesn't double
the scroll-padding value, but it's actually redundant, we should avoid it.
We could separate the functionality of ScrollToWithOrigin, one is to scroll
to a given element, the other is to scroll to a given position. The former will
be used for Element.scrollIntoElement and relevant stuff, the latter will be
used for Element.scrollTo and relevant stuff. That's being said, as of now, we
have still the old scroll snap implementation, so the separation will introduce
complexity, the separation should be done once after the old implementation
removed.
There are 9 call sites of nsIPresShell::ScrollContentIntoView:
nsIPresShell::GoToAnchor
nsIPresShell::ScrollToAnchor
Element::ScrollIntoView
We definitely needs scroll-padding and scroll-margin for these functions.
nsCoreUtils::ScrollTo
This is used for Accesible::ScrollTo which scrolls to a given accesible node,
probably we should behave as what Element::ScrollIntoView does.
Accessible::DispatchClickEvent
Similar to the above, similated various mouse events on a given target node.
PresShell::EventHandler::PrepareToUseCaretPosition
PresShell::EventHandler::GetCurrentItemAndPositionForElement
Both are for context menu, we shouldn't consider scroll-padding and
scroll-margin.
nsFormFillController::SetPopupOpen
This is used for autocompletion popup, we shouldn't consider scroll-padding
and scroll-margin.
nsFocusManager::ScrollIntoView
This is bit unfortunate, we should use scroll-padding and scroll-margin
depending on call site of this function. Bug 1535232 is for this case.
cssom-view/scrollIntoView-scrollPadding.html which has some tests that is
actually testing scroll-padding with scrollIntoView passes with this change.
The reftest in this change is a test case that the browser navigates to an
element with specifying the anchor to the element.
Differential Revision: https://phabricator.services.mozilla.com/D23084
--HG--
extra : moz-landing-system : lando
* Use Services.(ppmm|cpmm).sharedData to make isMasterPasswordSet value available to the content process
* We don't handle runtime enable/disable of MP
Differential Revision: https://phabricator.services.mozilla.com/D26939
--HG--
extra : moz-landing-system : lando
If MOZ_INSTRUMENT_CUSTOM_ELEMENTS is set in the environment, then modify Custom Elements
to wrap each function and property lookup to keep a count and running time. Then print out
tables for each element at startup. Tables can be re-printed with `MozElements.printInstrumentation()`.
Differential Revision: https://phabricator.services.mozilla.com/D24953
--HG--
extra : moz-landing-system : lando
Removed FX_PREFERENCES_OPENED_VIA probe as it expired in 63.Origin parameter for openPreferences has also been removed.
Differential Revision: https://phabricator.services.mozilla.com/D26795
--HG--
extra : moz-landing-system : lando
Bug 1478124 and bug 1524687 converted many things to static xpcom
component registration, but somehow left the corresponding C++
initialization.
Differential Revision: https://phabricator.services.mozilla.com/D26697
--HG--
extra : moz-landing-system : lando
Originally, RDD reused the GPU process selector since they were
using all the same services, and it reduced the number of places
that had to be touched. Now that RDD needs pref handling, it
needs its own process selector to avoid GPU inheriting pref
handling.
Differential Revision: https://phabricator.services.mozilla.com/D26566
--HG--
extra : moz-landing-system : lando
The RemoteAgent.js script has (temporarily) changed name to
remote/command-line-handler.js, and the chrome component remote.jar
was not included during packaging. This patch fixes both these things.
Differential Revision: https://phabricator.services.mozilla.com/D26591
--HG--
extra : moz-landing-system : lando
After replacing precise line information from .debug_line with coarse
line information from DW_AT_call_{file,line}, it's very likely that
adjacent line records actually refer to identical file and line
numbers. Such adjacent records are not really useful and take up more
space than they should in the symbol file. We might as well merge them
and save ourselves some space.
Differential Revision: https://phabricator.services.mozilla.com/D25473
--HG--
extra : moz-landing-system : lando
DW_TAG_subprogram DIEs sometimes have child DW_TAG_lexical_block DIEs
which in turn contain child DW_TAG_inlined_subroutine DIEs that we woud
like to look at. If we skip the DW_TAG_inlined_subroutine DIEs, we miss
important information. We therefore need to look through the
DW_TAG_lexical_block DIEs to find the DIEs that we are interested in.
Depends on D25471
Differential Revision: https://phabricator.services.mozilla.com/D25472
--HG--
extra : moz-landing-system : lando
We record the file and line that these subroutines were inlined from.
We'll use that information to provide more coarse-grained line
information in the next patch.
Depends on D25469
Differential Revision: https://phabricator.services.mozilla.com/D25470
--HG--
extra : moz-landing-system : lando
The DW_AT_call_file attributes that we eventually want to parse from
DW_TAG_inlined_subroutine DIEs refer to the file name table stored in
the .debug_line section. To resolve those DW_AT_call_file attributes,
we need access to that table after parsing of the appropriate
.debug_line bits is done. This patch adds support for extracting that
information from the .debug_line parsing process.
Differential Revision: https://phabricator.services.mozilla.com/D25469
--HG--
extra : moz-landing-system : lando
Fixes the tokenizer to recognize file:/// urls, plus adds a second layer of
protection, so that if URI fixup thinks the typed string may be an url, we don't
fetch suggestions for it.
Differential Revision: https://phabricator.services.mozilla.com/D26282
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
Avoid using Rkv::Manager, which calls std::fs::canonicalize, triggering bug 1531887 in Firefox on Android.
Differential Revision: https://phabricator.services.mozilla.com/D26605
--HG--
extra : moz-landing-system : lando
I assume this was an artifact of when this was done with XBL.
Depends on D26517
Differential Revision: https://phabricator.services.mozilla.com/D26518
--HG--
extra : moz-landing-system : lando
In bug 1375476 I fixed one of the places but missed the other. I'll refactor
them in a bit.
I wish I could run the select tests locally to extend them properly...
Differential Revision: https://phabricator.services.mozilla.com/D26517
--HG--
extra : moz-landing-system : lando
I changed DelegatedQueryInterface and CallMethod to be non-static
methods rather than taking an explicit |self| parameter.
There is already a method nsXPCWrappedJS::CallMethod() with the same
signature, but it is a shim, so I inlined it into the version in
XPCWrappedJSClass.cpp.
I also fixed up a few comments that mention nsXPCWrappedJSClass.
The new comments starting with "We now need to enter the realm" were
written by Boris, and are a little more explicit so they are easier to
understand.
I renamed DebugDump() to DebugDumpInterfaceInfo() to be more
informative.
Differential Revision: https://phabricator.services.mozilla.com/D26422
--HG--
extra : moz-landing-system : lando
Disable gtests observed to fail on Android. Some of these are simple build
failures and failures due to file permissions or paths, while other failures
are more obscure.
Once Android gtests are running on mozilla-central, I will file follow-up
bugs inviting teams to investigate the failures and re-enable Android gtests
that are important to them.
Differential Revision: https://phabricator.services.mozilla.com/D26606
--HG--
extra : moz-landing-system : lando
The binary path type of a particular content process is useful information
outside of IPC. Given that `XRE_EnableSameExecutableForContentProc` already
exists, and given that the binary path type is closely related to
`GeckoProcessType`, I've added a new function, `XRE_GetContentProcBinPathType`.
The mapping of process type to binary type has been moved to the
`GeckoProcessTypes` definitions.
This patch also modifies `ipc::GeckoChildProcessHost` to call into the new
function.
Differential Revision: https://phabricator.services.mozilla.com/D25816
--HG--
extra : moz-landing-system : lando
Produces a help text that conforms to the line width recommendations
of nsICommandLine.
On the other hand, the formatting of the source code itself is
rendered rather ugly by clang-format.
Differential Revision: https://phabricator.services.mozilla.com/D26583
--HG--
extra : moz-landing-system : lando
I changed DelegatedQueryInterface and CallMethod to be non-static
methods rather than taking an explicit |self| parameter.
I did a tiny bit of cleanup in the nsIXPConnectJSObjectHolder case of
DelegatedQueryInterface().
There is already a method nsXPCWrappedJS::CallMethod() with the same
signature, but it is a shim, so I inlined it into the version in
XPCWrappedJSClass.cpp.
I also fixed up a few comments that mention nsXPCWrappedJSClass.
The new comments starting with "We now need to enter the realm" were
written by Boris, and are a little more explicit so they are easier to
understand.
I renamed DebugDump() to DebugDumpInterfaceInfo() to be more
informative.
Differential Revision: https://phabricator.services.mozilla.com/D26422
--HG--
extra : moz-landing-system : lando
Here are the file extensions are added to the list:
1. action
2. caction
3. configprofile
4. definition
5. dylib
6. internetconnect
7. networkconnect
8. service
9. wflow
10.workflow
Differential Revision: https://phabricator.services.mozilla.com/D26284
--HG--
extra : moz-landing-system : lando
This is based on the `c_str` macro in `js/rust/src/heap.rs`, but
returns a `NulTerminatedCStr` type that can be cast to a pointer.
This commit also changes `ThreadPtrHolder::new` to take a
`NulTerminatedCStr`, and removes an unnecessary `RefPtr` reference in
`is_current_thread`.
Differential Revision: https://phabricator.services.mozilla.com/D26429
--HG--
extra : moz-landing-system : lando
This commit:
* Uses chunking to insert child GUIDs in `storeRemoteFolder`.
* Changes the mirror schema to store diverging structure, so that it
can be passed to Dogear.
* Sorts remote items by GUID, so that diverging ones can be reparented
in a deterministic order.
* Measures and logs the time taken to run the Rust merger.
* Adds tests for multiple parents and replacing invalid remote items.
* Fixes two tests in `test_bookmark_structure_changes` to ensure the
remote structure is consistent.
Differential Revision: https://phabricator.services.mozilla.com/D26275
--HG--
extra : moz-landing-system : lando
This patch contains three fixes.
1) As in Bug 1515982, we use the constant for RT_MANIFEST instead of
the define, which needs winuser.rh to be included
2) We stop exempting the mingw builds from RCINCLUDE in
toolkit/library/moz.build which causes us to miss all of the
resources in xul.dll
3) We explicitly include IA2Marshal.dll instead of relying on
compiler magic to include it for us.
Differential Revision: https://phabricator.services.mozilla.com/D26295
--HG--
extra : moz-landing-system : lando
This is only called on environment-changed pings.
We avoid re-setting the scheduler timeout, so that we can trigger other
pings at regular intervals unrelated to main pings.
This will not cause the daily ping to be sent more often, at worst we
schedule something once too frequently.
Depends on D26149
Differential Revision: https://phabricator.services.mozilla.com/D26150
--HG--
extra : moz-landing-system : lando
This is useful to prevent issues in TRR mode 2 when a captive portal redirect occurs via DNS.
For example, if we are in an unlocked CP and in suddenly locks, we must make sure that we don't use a cached DNS entry from when the portal was unlocked.
This is especially relevant in split horizon situations.
This isn't useful in TRR mode 3, as the flag would just cause the resolution to fail.
For that we need to add the captive portal URI to the TRR exclusion list.
Differential Revision: https://phabricator.services.mozilla.com/D25619
--HG--
extra : moz-landing-system : lando
Previously `mozvisualscroll` would close the reader dropdown and maybe even
hide the system UI and the 'reader-toolbar' entirely.
Because this would fire for any visual viewport scrolls which might happen when
the user choses any new font options it would inadvertently close that dropdown
and take the options away from the user even if he did not finish configurating
reader mode.
With this patch closing the reader dropdown will be the responsability of other
events firing and `mozvisualscroll` will only hide the 'reader-toolbar' if the
reader dropwdown is not currently opened signifying the user is in the process
of making changes to the reader mode experience.
Differential Revision: https://phabricator.services.mozilla.com/D25596
--HG--
extra : moz-landing-system : lando
For example, you can do MOZ_INSTRUMENT_CUSTOM_ELEMENTS=MozXULElement,Button
to limit output to classes containing those strings in their name
Differential Revision: https://phabricator.services.mozilla.com/D27800
--HG--
extra : moz-landing-system : lando
Adds a basic test for this process switching functionality in subframes.
This tests one of the few forms of remoteness which are supported with the Part
1 patch, which is when navigating an iframe in a file:// document to a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D26565
--HG--
extra : moz-landing-system : lando
This code builds on top of the E10S "remote tabs" configuration system to add a
system for specifying that remote subframes should be used. Fission can be
enabled for a window by including the "fission" flag in options when opening
the window.
Differential Revision: https://phabricator.services.mozilla.com/D26560
--HG--
extra : moz-landing-system : lando
Includes an otherwise-automated change to test_jsctypes.js that required an
expectation change in test_ctypes.xul.
Differential Revision: https://phabricator.services.mozilla.com/D27449
--HG--
extra : moz-landing-system : lando
Result of running:
$ mach eslint -funix toolkit/ | sed -Ee 's/:.+//' - | xargs sed -E \
-e 's/throw ((["`])[^"]+\2);/throw new Error(\1);/g' \
-e 's/throw ((["`])[^"]+\2 \+ [^ ";]+);/throw new Error(\1);/g' \
-e 's/throw \(/throw new Error(/g' -i
...and then reverting a couple of places where comments were touched,
as well as changes to toolkit/components/ctypes/tests/unit/test_jsctypes.js
that required expectation changes to
toolkit/components/ctypes/tests/chrome/test_ctypes.xul
Differential Revision: https://phabricator.services.mozilla.com/D27448
--HG--
extra : moz-landing-system : lando
nsBrowserStatusFilter is updated to not filter out STATE_IS_REDIRECTED_DOCUMENT.
The test here is adding a way to have a "login form" do a post to a server script, which then does a 303 redirect. This mimics what some services, including LinkedIn do during this stage.
Differential Revision: https://phabricator.services.mozilla.com/D26969
--HG--
extra : moz-landing-system : lando
This also moves SiteDataTestUtils to have it available in toolkit.
Differential Revision: https://phabricator.services.mozilla.com/D26248
--HG--
rename : browser/base/content/test/sanitize/SiteDataTestUtils.jsm => toolkit/components/cleardata/SiteDataTestUtils.jsm
extra : moz-landing-system : lando
The original name of the profile is irrelevant here since we aren't testing
a migration to profiles-per-install. On dev-edition DEDICATED_NAME is the same
as PROFILE_DEFAULT so we correctly make a new profile with a unique name.
Differential Revision: https://phabricator.services.mozilla.com/D26230
--HG--
extra : moz-landing-system : lando
This fixes two bugs. The first is that when the firefox profile migrator doesn't
know which profile to migrate it attempts to fall back to another profile. I
think this was intended to be the default but in bug 1322797 I ended up making
it the current profile, which is the profile we're restoring into now. I think
at this stage the profile directory doesn't even exist so things go wrong.
Changing to use the actual default works but....
When the profile migrator UI doesn't know what profile to migrate from it uses
the default profile. So if the profile you're actually trying to restore is not
the default we'll effectively throw its data into the archive and replace it
with data from the default profile. I'm inclined to say that if the migrator
does not know what profile to migrate from it should error at that point for
safety.
Why would the profile migrator not know what profile to migrate from? Because of
a long-standing text encoding problem. In C++ profile names are encoded in UTF8.
But we try to pass them to JS through an IDL parameter of type ACString. This
does no UTF8 decoding and so JS recieves an incorrect name if the name includes
non-ascii characters and so can't find the profile.
This patch fixes the IDL parameter to AUTF8String which does the decoding
correctly and so JS gets the name correctly.
We should probably think about whether just passing the nsIToolkitProfile object
to the migrator is a better choice here.
Differential Revision: https://phabricator.services.mozilla.com/D26250
--HG--
extra : moz-landing-system : lando
This fixes the filename and line number of login manager logs.
This is basically a rebased backout of the LMH portion of changeset b1e3cd7db269.
Differential Revision: https://phabricator.services.mozilla.com/D26023
--HG--
extra : moz-landing-system : lando
Since we rarely touch this code, I took the liberty of changing this to a JS class
and fix the contrast ratio calculations to actually conform to the WCAG spec,
instead of using arbitrary constants.
I changed the `isBright` getter to `useBrightText`, because that is more apt;
we're usually looking for an answer to 'should I use white text on this background?',
instead of looking for an arbitrary threshold to classify a color as being bright.
I updated the tests to cover more of this and clarified the assertion messages as
well.
Differential Revision: https://phabricator.services.mozilla.com/D26097
--HG--
extra : moz-landing-system : lando
The Prio pilot project has completed, so we no longer need to add prio-encoded
payloads to the "main" ping.
Differential Revision: https://phabricator.services.mozilla.com/D26004
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
We do not need to handle onProgressChange64 notifications since the TabChild's
web progress events are filtered through an nsBrowserStatusFilter, which
truncates onProgresChange64 event values to 32-bit integers and then calls
onProgressChange.
Differential Revision: https://phabricator.services.mozilla.com/D25649
--HG--
extra : moz-landing-system : lando
Now that we have access to the RemoteWebProgress from the TabParent and can
construct RemoteWebProgress and RemoteWebProgressRequests in C++, we can
reconstruct the RemoteWebProgress and RemoteWebProgressRequest in the TabParent
instead of RemoteWebProgressManager. This improves the API for nsIBrowser and
RemoteWebProgressManager, removing the need for the
`callWebProgressContentBlockingEventListeners` method in both. It also means we
won't need to implement `callWebProgress*Listeners` for methods on nsIBrowser
and RemoteWebProgressManager for all other nsIWebProgress events.
Differential Revision: https://phabricator.services.mozilla.com/D24942
--HG--
extra : moz-landing-system : lando
The RemoteWebProgressManager is now implemented in terms of a
nsIWebProgressListener. This paves the way for reconstructing the
nsIWebProgress and nsIRequest passed to the event handlers in C++ instead of in
JS and will alllow for a cleaner overall design.
While here, I also cleaned up RemoteWebProgressManager to use the class
syntactic sugar.
Differential Revision: https://phabricator.services.mozilla.com/D24941
--HG--
extra : moz-landing-system : lando
Changing RemoteWebProgress to a C++ XPCOM object will cause the request being
passed into the `onStateChange` handler in `promiseBrowserLoaded` to become a
wrapped XPCOM object for an nsIRequest, instead of the JS object it was
previously. This results in the attribute lookup for `originalURI` on the
request to fail, leading to cascading failures.
Differential Revision: https://phabricator.services.mozilla.com/D24809
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
Some sites use `email`, `tel` and `tel-national` values for @autocomplete even when they are used as the username and 'username' would be more appropriate.
We already allowed type=email / type=tel so allowing the autocomplete equivalents is reasonable.
Differential Revision: https://phabricator.services.mozilla.com/D25883
--HG--
extra : moz-landing-system : lando
This is needed for cross-language LTO (bug 1512723). We don't want to block on waiting for 1.34's release, so we'll get a head start now, but we'll update to the final 1.34 release when available. Rust Forge estimates the release at 11 April.
Differential Revision: https://phabricator.services.mozilla.com/D25851
--HG--
extra : moz-landing-system : lando
This login should not show up in tests that don't expect it once we allow non-matching formSubmitURLs.
Differential Revision: https://phabricator.services.mozilla.com/D23443
--HG--
extra : moz-landing-system : lando
The `nsresult` codes that mozStorage returns are often too generic. For
example, `NS_ERROR_FAILURE` might be anything from a SQL syntax error
to an invalid column name in a trigger.
This commit adds a `Conn::call_and_wrap_error` helper that checks the
last SQLite error, and returns that instead of `nsresult`. Not all
errors are SQLite errors, however, so we only use this for mozStorage
methods that return `convertResultCode`.
Differential Revision: https://phabricator.services.mozilla.com/D25179
--HG--
extra : moz-landing-system : lando
Remove the now obsolete event handling code including `new Funcition`. Remove dialog.xml from eval() whitelist.
Differential Revision: https://phabricator.services.mozilla.com/D25742
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
Since reporting intervals are ~1 day/1 session, the Origin Telemetry prototype
must support the possibility that multiple origins will be recorded for the
same metric.
For example, if the user is sampled to record two pageloads where the same
ultra-common tracker is present and blocked we must record that tracker as
having been blocked twice.
This requires a bit of a shift in storage and plaintext snapshot. Instead of
being an array of origins with duplicates, now we're storing origins as a bag
(aka multiset, aka hashtable of origin->count).
Differential Revision: https://phabricator.services.mozilla.com/D25283
--HG--
extra : moz-landing-system : lando
Content Blocking's list is longer than the largest bool vector size supported
by PrioEncoder, so we need to split the list into shards before encoding.
This means we need to use the metric name and shard number together to identify
the encoding so it's possible to decode it later.
While I'm here, restructure GetEncodedSnapshots to make my life easier when I
eventually try to put the heavy lifting on its own thread. There's a clearer
split now between JS stuff and non-JS stuff.
Differential Revision: https://phabricator.services.mozilla.com/D25129
--HG--
extra : moz-landing-system : lando
In order to notify the "prio" ping when we reach the data limit, we need to
keep an accounting of how many prioData elements we'd need to encode what's in
storage.
This also adds the pref reading and topic notification code for the
"origin-telemetry-storage-limit-reached" topic that the "prio" ping observes.
Differential Revision: https://phabricator.services.mozilla.com/D25127
--HG--
extra : moz-landing-system : lando
The CHECKERBOARD probes are used as performance outcomes / diagnostics for WebRender.
We are beginning to test WebRender in release, so we should have these probes available.
This change additionally extends collection through version 73 to be compatible
with the January 2020 horizon for the ongoing nightly/beta WebRender study.
Differential Revision: https://phabricator.services.mozilla.com/D25126
--HG--
extra : moz-landing-system : lando
Mechanical change from Matcher::match(...) to Matcher::operator()(...).
This will now permit the use of generic lambdas, and facilitate the
implementation of multi-lambda match.
Differential Revision: https://phabricator.services.mozilla.com/D24889
--HG--
extra : moz-landing-system : lando
Since reporting intervals are ~1 day/1 session, the Origin Telemetry prototype
must support the possibility that multiple origins will be recorded for the
same metric.
For example, if the user is sampled to record two pageloads where the same
ultra-common tracker is present and blocked we must record that tracker as
having been blocked twice.
This requires a bit of a shift in storage and plaintext snapshot. Instead of
being an array of origins with duplicates, now we're storing origins as a bag
(aka multiset, aka hashtable of origin->count).
Differential Revision: https://phabricator.services.mozilla.com/D25283
--HG--
extra : moz-landing-system : lando
Content Blocking's list is longer than the largest bool vector size supported
by PrioEncoder, so we need to split the list into shards before encoding.
This means we need to use the metric name and shard number together to identify
the encoding so it's possible to decode it later.
While I'm here, restructure GetEncodedSnapshots to make my life easier when I
eventually try to put the heavy lifting on its own thread. There's a clearer
split now between JS stuff and non-JS stuff.
Differential Revision: https://phabricator.services.mozilla.com/D25129
--HG--
extra : moz-landing-system : lando
In order to notify the "prio" ping when we reach the data limit, we need to
keep an accounting of how many prioData elements we'd need to encode what's in
storage.
This also adds the pref reading and topic notification code for the
"origin-telemetry-storage-limit-reached" topic that the "prio" ping observes.
Differential Revision: https://phabricator.services.mozilla.com/D25127
--HG--
extra : moz-landing-system : lando
In the test_classify_by_default.html, we use "network.cookie.cookieBehavior"
to test if a channel is correctly classified.
Cookie restriction is only enabled in nightly and early beta so the
default preference is not always set. Although we set the preference
in the testcase, it is too late because that the channel's cookie
setting might inherit from it's parent and may end up with getting
the old(default) value.
In this patch, we use window.open to test the tracker frame to make
sure we use the udpated prefrence.
Differential Revision: https://phabricator.services.mozilla.com/D25657
--HG--
extra : moz-landing-system : lando
To correctly present IPv6 URL, we need to add the brackets for the host obtained from nsIURI
Differential Revision: https://phabricator.services.mozilla.com/D21828
--HG--
extra : moz-landing-system : lando
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
Fluent strings load asynchronously, so some text will be empty until that
happens. Once the strings load the page will shift down as the elements
gain the height of the text. Ensure there's always text in the add-on
cards so their height won't change (or at least it's reduced) once
strings load.
Differential Revision: https://phabricator.services.mozilla.com/D23196
--HG--
extra : moz-landing-system : lando
The .contentPane rule for /browser was consolidated and removed throughout the codebase but the .contentPane rule in passwordmgr.css is in /toolkit and shouldn't have been removed.
Differential Revision: https://phabricator.services.mozilla.com/D24922
--HG--
extra : moz-landing-system : lando
Disabled plugin related tests.
Added `crashreporter` dependency for browser_restore_isAppTab.js.
Differential Revision: https://phabricator.services.mozilla.com/D25504
--HG--
extra : moz-landing-system : lando
On Mac, don't attempt to save print settings after the user cancels out of the print dialog.
Differential Revision: https://phabricator.services.mozilla.com/D23889
--HG--
extra : moz-landing-system : lando
In previous versions of the LZ4 library, lz4_decompress_fast, which does not
take an input buffer size, was supposed to be faster than lz4_decompress_safe,
which does. In newer versions, however, the reverse is supposed to be true,
and lz4_decompress_fast is therefore deprecated.
This patch updates our code to use the now-preferred "safe" version of the
API.
Differential Revision: https://phabricator.services.mozilla.com/D28128
--HG--
extra : rebase_source : 572e7355ed6b31936632e977ee1584834e441fec