The patch fixes the problem by setting the correct 'max-width' value for
the header span of the protections panel which was referencing to the
wrong variable. This adds a shared variable and makes both identity
panel and protections referencing to it.
Differential Revision: https://phabricator.services.mozilla.com/D36739
--HG--
extra : moz-landing-system : lando
When the search string is supposed to be "empty", we should not store a url in
inputhistory's input column, instead we should store an empty input. This happens
for example when clicking the dropmarker and picking something, or when pressing
DOWN on a valid pageproxystate (no user input).
In the future we may evaluate not storing an empty string at all (Bug 1562823).
Differential Revision: https://phabricator.services.mozilla.com/D36568
--HG--
extra : moz-landing-system : lando
These tests mostly worked by accident in the past because assertions from
chrome scripts were not processed after a chrome script was destroyed, and
assertions were not treated as assertions anyway. But once those issues were
fixed, they started failing because of races in the RPC code in these tests,
which caused the first resolved call of a given method to resolve all other
calls as well, and not wait for them to finish and their assertions to fire
before ending the test.
--HG--
extra : rebase_source : 0578dd90e538ff0a8df3b8d9d0fbc426148e6ccd
extra : source : 19e0edc9207746c7987b98f3c7787b7c363d651d
This patch copies over the same fix that was used for the profile cleanup page
to the installing page, since in some locales it can run into the same problem
of the header string being so long that it causes the next control to get cut
off by the bottom of the window.
Differential Revision: https://phabricator.services.mozilla.com/D36523
--HG--
extra : moz-landing-system : lando
This patch also fixes the Home and Sidebar Touch Bar buttons, since using them after customizing showed that they no longer worked.
Differential Revision: https://phabricator.services.mozilla.com/D35085
--HG--
extra : moz-landing-system : lando
Bug 1553065 made this redundant by putting the profile-use mozconfig
settings in build/unix/mozconfig.unix. We no longer need them in each
leaf mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D36543
--HG--
extra : moz-landing-system : lando
This patch adds two tests. One for ensuring the mini panel is working
correctly. Another for check the correctness of the TP switch flow.
Differential Revision: https://phabricator.services.mozilla.com/D36332
--HG--
extra : moz-landing-system : lando
This patch adds the badge at the side of TP switch toggle. The badge
will only show when the TP switch toggles to off.
Differential Revision: https://phabricator.services.mozilla.com/D36019
--HG--
extra : moz-landing-system : lando
This patch makes the mini panel been shown after page reload due to
switch the tracking protection state. The mini panel will be auto hidden
after certain time, which can be configured by the pref
'browser.protections_panel.mini_panel_auto_hide_timing'. The default
value is 5 seconds.
This also implements the behavior that showing the protections panel on
clicking the mini panel.
Differential Revision: https://phabricator.services.mozilla.com/D36018
--HG--
extra : moz-landing-system : lando
This patch implements the capability for opening the protections panel
as a mini panel. The mini panel is a protections panel which only displays
the header section.
Differential Revision: https://phabricator.services.mozilla.com/D36017
--HG--
extra : moz-landing-system : lando
This patch implements the toggle switch flow for the TP switch section.
It adds a strip background to the TP switch section after toggled the
switch to off. Changing the string in the TP switch section. And the
breakage link should be remained after TP switch to off from on until
the page refreshs.
Differential Revision: https://phabricator.services.mozilla.com/D36016
--HG--
extra : moz-landing-system : lando
This patch makes the 'hasException' attribtion to be toggled right after
toggling the TP switch. In order to do styling after the toggling.
Differential Revision: https://phabricator.services.mozilla.com/D36015
--HG--
extra : moz-landing-system : lando
We can use MUI_BGCOLOR to change the background color, but there's no way to
globally override the text color, so we additionally need to set that on every
affected control in the Show functions (we have to wait until Show because
that's the earliest point that the controls have been created and we can get
handles to them).
This patch fixes both the full installer and the uninstaller.
Differential Revision: https://phabricator.services.mozilla.com/D33189
--HG--
extra : moz-landing-system : lando
We don't run any tests on these builds, since they are just used to
generate the profile data for the final build. We can save some time by
skipping all test related code.
Differential Revision: https://phabricator.services.mozilla.com/D36511
--HG--
extra : moz-landing-system : lando
Since JSWindowActors don't have direct access to synchronous messaging,
ChromeScript callers are going to need to migrate to asynchronous messaging
and queries instead.
Since there's no comparable API to sendQuery for frame message managers, this
patch adds a stub that uses synchronous messaging, but makes the API appear
asynchronous, and migrates callers to use it instead of direct synchronous
messaging. This will be replaced with a true synchronous API in the actor
migration.
Fortunately, most of the time, this actually leads to simpler code. The
`sendQuery` API doesn't have the odd return value semantics of
`sendSyncMessage`, and can usually just be used as a drop-in replacement. Many
of the `sendSyncMessage` callers don't actually use the result, and can just
be changed to `sendAsyncMessage`. And many of the existing async messaging
users can be changed to just use `sendQuery` rather than sending messages and
adding response listeners.
However, the APZ code is an exception. It relies on intricate properties of
the event loop, and doesn't have an easy way to slot in promise handlers, so I
migrated it to using sync messaging via process message managers instead.
Differential Revision: https://phabricator.services.mozilla.com/D35055
--HG--
extra : rebase_source : d5707e87f293a831a5cf2e0b0a7e977090267f78
extra : source : 75ebd6fce136ab3bd0e591c2b8b2d06d3b5bf923
When we migrate SpecialPowers to a JSWindowActor, it will no longer be able to
use synchronous IPC messaging, which means that its current synchronous APIs
will have to become asynchronous.
This patch doesn't change the behavior of those functions, but it does change
their callers to `await` their return values rather than using them directly.
This pattern will work the same whether the functions return a promise or a
plain value, which simplifies the migration.
Differential Revision: https://phabricator.services.mozilla.com/D35053
--HG--
extra : rebase_source : baffba2107b175250573baae3f54d48becbd2a16
extra : source : b4ed40bea2698802ef562a0931c0b560737fb89d
Create test entries via update introduces performance overhead.
We can store them directly in LookupCache and do not save test entries
to disk.
Differential Revision: https://phabricator.services.mozilla.com/D34576
--HG--
extra : moz-landing-system : lando
Turn off security.enterprise_roots.enabled for this test since that's
what it expects.
Differential Revision: https://phabricator.services.mozilla.com/D36334
--HG--
extra : rebase_source : 5904a8668cfaa7654895239e7698cac7338ffb51
The conversion for "regular" <tabs> elements is straightforward, most of
the work here is to support the tab strip (the <tabs> element with the id
"tabbrowser-tabs"). The markup needed for the tab strip moves directly
into browser.xhtml and the construction/teardown logic is now explicitly
driven from gBrowser. There are many more little tweaks too numerous to
enumerate.
Differential Revision: https://phabricator.services.mozilla.com/D32855
--HG--
rename : browser/base/content/tabbrowser.xml => browser/base/content/tabbrowser-tabs.js
extra : source : c163881a80c9a032b40f7d965fad6a6850fcf8a4
extra : intermediate-source : a5c6deeda8a9475ac0268a4351417c8ff659c962
extra : histedit_source : 5eb8b3d14027f2aeca5c52534096837cd0343104%2Ca23a07ddd5e1fb8bd084644dd6db0ee028b7c4b4
A bunch of existing code assumes that <tab> elements are the immediate
and only children of a <tabs> element, and uses dom apis to traverse
relationships between these elements. To simplify conversion of <tabs>
to a custom element (and hopefully improve readability a bit at the same
time!), introduce new apis:
On <tab>
this.parentNode -> this.container
this.nextElementSibling -> this.container.findNextTab(...)
this.previousElementSibiling -> this.container.findNextTab(...)
On <tabs>
this.children -> this.allTabs
Differential Revision: https://phabricator.services.mozilla.com/D34648
--HG--
extra : source : f4e21e465f384b90fa1e768141c4db708748bf66
extra : histedit_source : 95d8a4242e8e04df9e29c2b647558d37e910b845
This also moves the enabling of the feature out from all.js into firefox.js, where it should
probably have been all along.
Differential Revision: https://phabricator.services.mozilla.com/D35809
--HG--
extra : moz-landing-system : lando
* Rename the browser.urlbar.onQueryReady event onBehaviorRequested to make its purpose and return value clear.
* Add a browser.urlbar.onResultsRequested event that's fired when a query starts so that providers can add results. Listeners should return an array of Result objects. Add the Result type. It has a `payload` property that can be an arbitrary object depending on the result type.
* Add a browser.urlbar.onQueryCanceled event that's fired when a query is canceled.
* Rename the QueryContext type to just Query. From an extension's point of view, there's no difference between Query and QueryContext like there is for the internal implementation, so "Context" is unnecessary imo.
* Internally, remove the extension listeners map from UrlbarProvidersManager. Instead, extension listeners are added directly to UrlbarProviderExtension instances, and then UrlbarProvidersManager just loops through extension providers, not a separate map of listeners.
* Since UrlbarProviderExtension is getting a little bigger, move it to its own file.
* Fix a bug in UrlbarMuxerUnifiedComplete where the heuristic result sometimes does not come first in the sorted results, depending on the timing of when results from UrlbarProviderUnifiedComplete and other providers are added.
* Move SkippableTimer to UrlbarUtils.jsm, add a logger property, and add a name property so that it's easy to figure out which timers time out.
* Add lots of tests.
Differential Revision: https://phabricator.services.mozilla.com/D34809
--HG--
extra : moz-landing-system : lando
Our uninstaller currently calls the NSIS RMDir instruction on the `defaults`
directory with the /REBOOTOK flag set, which means that NSIS will register
the directory for deletion during the next reboot if it can't be removed
immediately for any reason. The problem here is that "any reason" includes
"the directory wasn't empty", and setting the reboot flag is not at all
the right thing to do in that situation. It won't help resolve the problem,
and those directories are expected to be empty at that point in the uninstall,
because we've already removed all the files that we know we put there, so
anything left is something we don't know about and shouldn't try to delete.
So the right thing to do here is just to remove the /REBOOTOK and allow the
RMDir to fail, so that any user files are never touched and we don't show
an unnecessary reboot prompt at the end of the wizard.
I also removed the FileExists checks, because the RMDir instruction does that.
Differential Revision: https://phabricator.services.mozilla.com/D34938
--HG--
extra : moz-landing-system : lando
These tests are full of too many problems to catalog here.
This patch just rewrites them to make them less insane.
Differential Revision: https://phabricator.services.mozilla.com/D34647
--HG--
extra : source : c71c45fe3e63c9fb97551654d079344448c49c6e
extra : histedit_source : 7caaeeed52e6937cb55dbd33b0156bc2762a0f16
If we decide to just go with an overlay that sits fully over the
window (which I don't personally see a perf problem with right now,
but correct me if you can think of one), then this should be all
we need.
Differential Revision: https://phabricator.services.mozilla.com//D33819
--HG--
extra : rebase_source : 44a5af47f9c10071b0933931fbf3708978f549e4
The conversion for "regular" <tabs> elements is straightforward, most of
the work here is to support the tab strip (the <tabs> element with the id
"tabbrowser-tabs"). The markup needed for the tab strip moves directly
into browser.xhtml and the construction/teardown logic is now explicitly
driven from gBrowser. There are many more little tweaks too numerous to
enumerate.
Differential Revision: https://phabricator.services.mozilla.com/D32855
--HG--
rename : browser/base/content/tabbrowser.xml => browser/base/content/tabbrowser-tabs.js
extra : rebase_source : 6b2b0ed9b01958d1b2db605ab300c4bebcaa461c
extra : source : c163881a80c9a032b40f7d965fad6a6850fcf8a4
A bunch of existing code assumes that <tab> elements are the immediate
and only children of a <tabs> element, and uses dom apis to traverse
relationships between these elements. To simplify conversion of <tabs>
to a custom element (and hopefully improve readability a bit at the same
time!), introduce new apis:
On <tab>
this.parentNode -> this.container
this.nextElementSibling -> this.container.findNextTab(...)
this.previousElementSibiling -> this.container.findNextTab(...)
On <tabs>
this.children -> this.allTabs
Differential Revision: https://phabricator.services.mozilla.com/D34648
--HG--
extra : rebase_source : affeda0295a5195124709f322de524aea3a28a3f
These tests are full of too many problems to catalog here.
This patch just rewrites them to make them less insane.
Differential Revision: https://phabricator.services.mozilla.com/D34647
--HG--
extra : rebase_source : 4b5f88278236bf74070561124983a35176474e3d
This patch adds a test for testing 'Show Full Report' link in the
footer section. The test will click the link and chekc if the
'about:protections' opens properly.
Differential Revision: https://phabricator.services.mozilla.com/D35186
--HG--
extra : moz-landing-system : lando
Specifically, a "control pref" for a pref must already exist locally, or
a new preference, `services.sync.prefs.dangerously_allow_arbitrary` must
be set to true.
This also removes a few preferences from the set we sync by default based
due to potential harm which can be caused syncing inappropriate values.
Differential Revision: https://phabricator.services.mozilla.com/D29775
--HG--
extra : moz-landing-system : lando
and migrate an existing test to use `TelemetryTestUtils.assertEvents`,
with a regular expression as filter.
Differential Revision: https://phabricator.services.mozilla.com/D35156
--HG--
extra : moz-landing-system : lando
The problem is that on switching back to the first tab (see the bug), userTypedValue is non-null when URLBarSetURI is called. Therefore the proxy state can't be valid. Something about bug 1529931 caused userTypedValue to go from null to non-null in this case. Details below, but the summary is that we shouldn't be calling UrlbarInput.setValueFromResult when opening the history popup, because setValueFromResult sets userTypedValue.
Before bug 1529931, result.autofill would always be undefined for the first result in the history popup, because we didn't allow UnifiedComplete to return an autofill result for the search triggered by the history popup. After that bug, UnifiedComplete could return an autofill result in that case -- and it likely would since the first result in the history popup has a very high frecency, which also makes it eligible for autofill.
The problem with having an autofill result in the history popup is that it triggers the input.setValueFromResult() call in UrlbarController.receiveResults [1], and setValueFromResult sets userTypedValue. So when the user opens the history popup, userTypedValue gets set to a non-null value (input._lastSearchString).
The fix is to not allow autofill for the history popup. After making that fix on revision https://hg.mozilla.org/mozilla-central/rev/5e2a3b886e64, the bug went away.
However, after I made that fix on a fresh tree, the bug still happened. It turns out that input.setValueFromResult still ends up getting called, by UrlbarView._selectItem [2], which is called when results are received [3]. The fix for this afaict is just to pass `updateInput: false` to _selectItem.
The autofill-related fix doesn't seem to be necessary at all anymore (likely due to the substantial changes to autofill since that bug landed), but I left it in anyway since it seems right to not allow autofill results for the history popup.
One other useful bit of info is that userTypedValue is set to null by tabbrowser on page load [4], so that's how userTypedValue has a null value when the bug manifests and it goes from null to non-null.
[1] https://hg.mozilla.org/mozilla-central/file/5e2a3b886e647af1968b9e52a6672bdeee2a0d6f/browser/components/urlbar/UrlbarController.jsm#l150
[2] https://searchfox.org/mozilla-central/rev/da14c413ef663eb1ba246799e94a240f81c42488/browser/components/urlbar/UrlbarView.jsm#685
[3] https://searchfox.org/mozilla-central/rev/da14c413ef663eb1ba246799e94a240f81c42488/browser/components/urlbar/UrlbarView.jsm#220
[4] https://searchfox.org/mozilla-central/rev/da14c413ef663eb1ba246799e94a240f81c42488/browser/base/content/tabbrowser.js#5118
Differential Revision: https://phabricator.services.mozilla.com/D35505
--HG--
extra : moz-landing-system : lando
This adds an API for fetching security info per frame, no matter if we have
a certificate error or a valid certificate.
I tried to make this work in a Fission-compatible way, let me know if this
is the right approach.
Differential Revision: https://phabricator.services.mozilla.com/D34354
--HG--
extra : moz-landing-system : lando
Bug 1284835 removed the hard-coded learn more link on cert and net error pages, which worked
for cert error pages because they explicitly set their own learn more links, but net error
pages were relying on the default href to be set. This wasn't revealed until bug 1530348
made about:neterror part of the new error pages.
The solution is simply to explicitly set the correct learn more link to net error pages.
Note that in the case of PR_END_OF_FILE errors, we were not previously showing a "learn more"
link. That was not intentional, as far as I can tell, but was caused by the bug fixed in bug 1477875.
Differential Revision: https://phabricator.services.mozilla.com/D35163
--HG--
extra : moz-landing-system : lando
With the removal of the old Chromium file_util code, we should no longer
be using temporary files with names starting with "org.chromium.", so the
crash reporter and main thread I/O test no longer need to recognize that
prefix.
Differential Revision: https://phabricator.services.mozilla.com/D34629
--HG--
extra : moz-landing-system : lando
The tests for unexpected main thread I/O had exemptions for the specific
paths that were being used for shared memory, which would cause it to
fail with the changes in this bug. This patch does two things:
1. On Linux, /dev/shm is always tmpfs (a memory filesystem), so it's not
going to cause disk I/O, and it's used by glibc to implement the POSIX
standard shm_open API. This allows all /dev/shm paths instead of
limiting it to a hard-coded prefix.
2. On MacOS, with the patches in this bug, we'll no longer use temporary
files for shared memory on current OS versions, but we still need them on
older versions to avoid an OS bug (https://crbug.com/project-zero/1671),
and they are backed by disk in this case, so we want to allow only the
IPC files. However, the path prefix has changed.
Differential Revision: https://phabricator.services.mozilla.com/D34628
--HG--
extra : moz-landing-system : lando
Bug 1545766 (D28442) tweaked PanelMultiView keyboard navigation to behave as expected for embedded browser elements.
This patch extends this to handle iframe elements such as used in the builtin Profiler panel.
In addition, it avoids setting tabindex="-1" on iframe and browser elements, since this breaks tabbing behavior in iframe elements (and possibly causes issues in browser elements as well).
iframe and browser elements are already focusable, so this isn't needed anyway.
Differential Revision: https://phabricator.services.mozilla.com/D34984
--HG--
extra : moz-landing-system : lando
With the removal of the old Chromium file_util code, we should no longer
be using temporary files with names starting with "org.chromium.", so the
crash reporter and main thread I/O test no longer need to recognize that
prefix.
Differential Revision: https://phabricator.services.mozilla.com/D34629
--HG--
extra : moz-landing-system : lando
The tests for unexpected main thread I/O had exemptions for the specific
paths that were being used for shared memory, which would cause it to
fail with the changes in this bug. This patch does two things:
1. On Linux, /dev/shm is always tmpfs (a memory filesystem), so it's not
going to cause disk I/O, and it's used by glibc to implement the POSIX
standard shm_open API. This allows all /dev/shm paths instead of
limiting it to a hard-coded prefix.
2. On MacOS, with the patches in this bug, we'll no longer use temporary
files for shared memory on current OS versions, but we still need them on
older versions to avoid an OS bug (https://crbug.com/project-zero/1671),
and they are backed by disk in this case, so we want to allow only the
IPC files. However, the path prefix has changed.
Differential Revision: https://phabricator.services.mozilla.com/D34628
--HG--
extra : moz-landing-system : lando
:root is potentially cheaper than #main-window, because IDs aren't actually guaranteed to be unique, so ID selectors are treated just like class selectors under the hood.
Changed #main-window to :root in browser/themes/shared/customizableui/panelUI.inc.css
Differential Revision: https://phabricator.services.mozilla.com/D35382
--HG--
extra : moz-landing-system : lando
Attributes that are related to Fluent-based strings intentionally weren't moved to element.dataset.
Differential Revision: https://phabricator.services.mozilla.com/D35113
--HG--
extra : moz-landing-system : lando
I named the INI file parameter "FallbackPage" so that people building these
configurations can quickly understand what this URL is for and don't have to
figure out what "manual download" means.
Differential Revision: https://phabricator.services.mozilla.com/D34359
--HG--
extra : moz-landing-system : lando
This workaround hands the top-level browser to nsContextMenu rather than the
mozbrowser in the RDM case. We need to do that since RDM does a lot of work
to make the inner mozbrowser _seem_ like the top-level browser, including
proxying messages from that top-most browser to the underlying mozbrowser.
This workaround makes us consistent with that model, and will have to do until
we can get bug 1559456 fixed.
Depends on D35077
Differential Revision: https://phabricator.services.mozilla.com/D35078
--HG--
extra : moz-landing-system : lando
In the content process case, preventing default stops the context menu event from being dispatched
within remote iframes, which is what causes bug 1558506.
In the parent process case, preventing default stops the nsXULPopupListener from opening the context
menu for us when we don't want ContextMenuParent to handle it, which we don't want to do.
Differential Revision: https://phabricator.services.mozilla.com/D35077
--HG--
extra : moz-landing-system : lando
Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
--HG--
extra : moz-landing-system : lando
Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
--HG--
extra : moz-landing-system : lando
add a webcompat intervention for TinyMCE 3.0 thru 3.4.4 to overwrite tiny_mce.js and tiny_mce_src.js such that isGecko=false
Differential Revision: https://phabricator.services.mozilla.com/D34776
--HG--
extra : moz-landing-system : lando
The separation didn't work out right and some work started getting duplicated between login-item and modal-input.
Differential Revision: https://phabricator.services.mozilla.com/D34466
--HG--
extra : moz-landing-system : lando
The separation didn't work out right and some work started getting duplicated between login-item and modal-input.
Differential Revision: https://phabricator.services.mozilla.com/D34466
--HG--
extra : moz-landing-system : lando
This isn't necessary, since it has only 2 static children (the selected tab's content
and the customizable UI), and their visibility is toggled in a single place. We already
toggle .hidden for both - there's no need for a separate deck.
Differential Revision: https://phabricator.services.mozilla.com/D34792
--HG--
extra : moz-landing-system : lando
Remove the mozpersist attribute and XULDocument requirement to use XUL
persistence and allow any system privilege document to use it by default.
Differential Revision: https://phabricator.services.mozilla.com/D34602
--HG--
extra : moz-landing-system : lando
This fixes Bug 1558506 by making it so that the parent process ignores the context menu event
when right-clicking on the remote <browser> hosting the Add-on Options page. Before, we were
handling the event, stopping it from propagating and preventDefault'ing it, and then sending
a message to the parent that ultimately did nothing (since we knew that we didn't want to
display the context menu). Stopping propagation and preventDefault'ing meant that the event
was never fired in the Extension process for the options page.
With the parent process now returning early in the event that it knows that it doesn't want
to be the one to open the context menu, the underlying ContextMenuSpecialProcessChild can
handle the contextmenu event in the extension process, and do the right thing.
Differential Revision: https://phabricator.services.mozilla.com/D34901
--HG--
extra : moz-landing-system : lando
On MacOSX, especially on MacOS 10.10, the toolbar paint flush happens along
with the urlbar flickers.
Differential Revision: https://phabricator.services.mozilla.com/D34489
--HG--
extra : moz-landing-system : lando
Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
--HG--
extra : moz-landing-system : lando
This also removes the two extra copies of the byte buffer that we had; we don't
need to copy it more than once. Once we have it in an std::vector, we can pass
that around by reference, not by value or by creating new vectors from copies
of its buffer.
Differential Revision: https://phabricator.services.mozilla.com/D34630
--HG--
extra : moz-landing-system : lando
* Add password generation checkbox as child of savePasswords checkbox
* Shuffle layout to put the Exceptions and Saved Logins buttons in a right-column
Differential Revision: https://phabricator.services.mozilla.com/D34446
--HG--
extra : moz-landing-system : lando
In the preSummary function TmpVal was being checked before it could be set
causing the test to always fail.
Differential Revision: https://phabricator.services.mozilla.com/D18601
--HG--
extra : moz-landing-system : lando
This patch add a test for ensuring the protection settings button works
correctly. It will open a tab and its protection panel. Clicking the
protection settings button and chekcing if the about:preferences has
been opened properly or not.
Differential Revision: https://phabricator.services.mozilla.com/D34874
--HG--
extra : moz-landing-system : lando
This patch adds a protection settings section into Protection Panel.
This section consist of one button which will open a
'about:preferences#privacy' when been clicked.
Differential Revision: https://phabricator.services.mozilla.com/D34873
--HG--
extra : moz-landing-system : lando
Autofill only when the user enters text -- i.e., when event.data in _on_input is non-empty. That allows us to simplify autofill quite a bit. We can get rid of the edit action listener that we previously used to detect selection deletion, and we also don't need the prefix check (lastSearchStartsWithNewSearch).
Therefore this fixes both this bug (bug 1557555) and bug 1545731/719888.
This makes one other change: We can check event.inputType in _on_input to tell whether the user is pasting, rather than keeping a _valueIsPasted property that we set in _on_paste.
Differential Revision: https://phabricator.services.mozilla.com/D34645
--HG--
extra : moz-landing-system : lando
Upon enabling the HTML about:addons discovery pane, about:addons page
start to send a fetch request from the default user context, instead of
a content load request with the tab's user context.
This mismatch in userContextId triggers the following debug assertion:
https://searchfox.org/mozilla-central/rev/c606cdd6d014f/netwerk/base/nsNetUtil.cpp#3021-3024
This assertion can be ignored, because the request has no credentials,
so its context should not matter.
Differential Revision: https://phabricator.services.mozilla.com/D34688
--HG--
extra : moz-landing-system : lando
We need to whistlist 'PCompositorBridge::Msg_MapAndNotifyChildCreated'
and 'PCompositorBridge::Msg_NotifyChildCreated' sync IPCs in the stage
'before becoming idle' for Windows platform since removing the content
window telemetry probe causing these sync IPCs been sent earlier than
before. And the IPC recorder sometimes doesn't fully cover the stage
in Windows platform. So, we will get these sync IPCs in the stage and
we need to whitelist them.
Differential Revision: https://phabricator.services.mozilla.com/D34491
--HG--
extra : moz-landing-system : lando
In order for the remote settings blocklist to sync, we need to ensure that
the corresponding remote settings clients are created (see also
https://bugzilla.mozilla.org/show_bug.cgi?id=1557790#c2 ). This is
necessary because the blocklist clients are not in the `main` bucket.
This would otherwise happen as soon as any consumer asked the blocklist
for any block data, but that's not going to happen unless the list of
add-ons or plugins changes. Even if there are no changes to the local
lists of installed things, we do need blocklist updates because
otherwise already-installed items would never get blocked even if/when
they are added to the blocklist.
The client initialization should have no other side effects (in terms of
performance/cost) beyond ensuring they get included in things we ask for
when the update-timer fires.
Differential Revision: https://phabricator.services.mozilla.com/D34550
--HG--
extra : moz-landing-system : lando
In bug 1519577, the badged-button class for toolbarbuttons was replaced
with a "badged" attribute but a few old uses of the class were overlooked.
This patch fixes them.
Differential Revision: https://phabricator.services.mozilla.com/D34438
--HG--
extra : moz-landing-system : lando
When HTML `about:addons` is enabled, the "Manage extension" button still
opens the add-on's details page, but without automatically loading the
inline options.
The test assumed that it did and failed. This patch switches to a
different way of detecting that the menu item works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D34209
--HG--
extra : moz-landing-system : lando