This patch
- adds one hide-onboarding-tour checkbox
- after toggling the overlay, hides the onboarding tour if user checked hide-the-tour checkbox
- creates the message channel between the chrome process and the content process to set prefs.
- listens to the pref-updated event and then hide the onboarding tour across pages.
- Add one browser_onboarding_hide_tours.js test
MozReview-Commit-ID: 7ZjbrhfO9dB
--HG--
extra : rebase_source : 5c59527ff7cb16996539a4eec49b47a9decafb3a
A change in Windows 10 Creators update is preventing Firefox from launching properly when a staged update's replace request is performed. Since staging updates doesn't provide a significant time on Windows this patch disables it via its preference. See bug 1368600 for additional information and this will likely fix bug 1368600 as well.
This patch activates the Flash blocklists for all users, and configures other prefs that only take effect when Flash is set to Ask-to-Activate, such as which fallback heuristics to use and the option to remember infobar dismissals on a per-domain basis
MozReview-Commit-ID: Ht0Y53UnjoQ
I thought of fixing this in the e10srollout addon because DevEdition is now
built off of Beta, but it would only serve to complicate the addon even more
and expose us to more risk every time we touch it. Also, DevEdition stayed on
the Aurora update channel and who knows if we're going to change that in the
future. Special casing DevEdition (via AppConstants) is possible, but it was
going to get messy pretty quickly. This is probably the most straightforward
way to make this all work.
MozReview-Commit-ID: 6WPjBawUutz
--HG--
extra : rebase_source : 156846085e1e3db7cd4924793a1de5d9336fab1c
If the "security.sandbox.content.level" preference is set to a value less than
1, all consumers will automatically treat it as if it were level 1. On Linux and
Nightly builds, setting the sandbox level to 0 is still allowed, for now.
MozReview-Commit-ID: 9QNTCkdbTfm
--HG--
extra : rebase_source : cd5a853c46a5cd334504b339bef8df30a3cabe51
If the "security.sandbox.content.level" preference is set to a value less than
1, all consumers will automatically treat it as if it were level 1. On Linux and
Nightly builds, setting the sandbox level to 0 is still allowed, for now.
MozReview-Commit-ID: 9QNTCkdbTfm
--HG--
extra : rebase_source : 1a26ffc5b9f80e6df4c37c23f506e907ba44053a
Since we now have a store of notifications that is global across
all windows, it no longer makes sense to consume the API from
within browser.js. This patch moves the browser.js logic out into
a jsm file that is wired up through nsBrowserGlue, such that it
will be lazily instantiated on the first update event it would
receive[1].
We decided to move this into toolkit, as this piece of the
system is fairly generic and shouldn't differ between
applications.
[1]: There is a change to nsBrowserGlue to use "global[module]"
instead of this[module]. This mirrors the code for all the other
types of notifications, and I suspect it was just a latent bug,
since the original diff that includes this line makes no use of
it.
MozReview-Commit-ID: 8EQdM9BOpgl
--HG--
rename : browser/base/content/test/appUpdate/.eslintrc.js => toolkit/mozapps/update/tests/browser/.eslintrc.js
rename : browser/base/content/test/appUpdate/browser.ini => toolkit/mozapps/update/tests/browser/browser.ini
rename : browser/base/content/test/appUpdate/browser_updatesBackgroundWindow.js => toolkit/mozapps/update/tests/browser/browser_updatesBackgroundWindow.js
rename : browser/base/content/test/appUpdate/browser_updatesBackgroundWindowFailures.js => toolkit/mozapps/update/tests/browser/browser_updatesBackgroundWindowFailures.js
rename : browser/base/content/test/appUpdate/browser_updatesBasicPrompt.js => toolkit/mozapps/update/tests/browser/browser_updatesBasicPrompt.js
rename : browser/base/content/test/appUpdate/browser_updatesBasicPromptNoStaging.js => toolkit/mozapps/update/tests/browser/browser_updatesBasicPromptNoStaging.js
rename : browser/base/content/test/appUpdate/browser_updatesCantApply.js => toolkit/mozapps/update/tests/browser/browser_updatesCantApply.js
rename : browser/base/content/test/appUpdate/browser_updatesCompleteAndPartialPatchesWithBadCompleteSize.js => toolkit/mozapps/update/tests/browser/browser_updatesCompleteAndPartialPatchesWithBadCompleteSize.js
rename : browser/base/content/test/appUpdate/browser_updatesCompleteAndPartialPatchesWithBadPartialSize.js => toolkit/mozapps/update/tests/browser/browser_updatesCompleteAndPartialPatchesWithBadPartialSize.js
rename : browser/base/content/test/appUpdate/browser_updatesCompleteAndPartialPatchesWithBadSizes.js => toolkit/mozapps/update/tests/browser/browser_updatesCompleteAndPartialPatchesWithBadSizes.js
rename : browser/base/content/test/appUpdate/browser_updatesCompletePatchApplyFailure.js => toolkit/mozapps/update/tests/browser/browser_updatesCompletePatchApplyFailure.js
rename : browser/base/content/test/appUpdate/browser_updatesCompletePatchWithBadCompleteSize.js => toolkit/mozapps/update/tests/browser/browser_updatesCompletePatchWithBadCompleteSize.js
rename : browser/base/content/test/appUpdate/browser_updatesDownloadFailures.js => toolkit/mozapps/update/tests/browser/browser_updatesDownloadFailures.js
rename : browser/base/content/test/appUpdate/browser_updatesMalformedXml.js => toolkit/mozapps/update/tests/browser/browser_updatesMalformedXml.js
rename : browser/base/content/test/appUpdate/browser_updatesPartialPatchApplyFailure.js => toolkit/mozapps/update/tests/browser/browser_updatesPartialPatchApplyFailure.js
rename : browser/base/content/test/appUpdate/browser_updatesPartialPatchApplyFailureWithCompleteAvailable.js => toolkit/mozapps/update/tests/browser/browser_updatesPartialPatchApplyFailureWithCompleteAvailable.js
rename : browser/base/content/test/appUpdate/browser_updatesPartialPatchApplyFailureWithCompleteValidationFailure.js => toolkit/mozapps/update/tests/browser/browser_updatesPartialPatchApplyFailureWithCompleteValidationFailure.js
rename : browser/base/content/test/appUpdate/browser_updatesPartialPatchWithBadPartialSize.js => toolkit/mozapps/update/tests/browser/browser_updatesPartialPatchWithBadPartialSize.js
extra : rebase_source : 24048650b23eff0a1da9679d1e9b5e1db1900287
Flip the default search suggestions in location bar prefs to true.
Users who didn't previously make a choice regarding the feature will see a hint explaining how to recognize suggestsions and
a link to change search settings.
Users who previously made an explicit choice won't see any hint and their choice will be respected on upgrade.
This doesn't make any guarantee regarding a downgrade/upgrade path and previous choices.
MozReview-Commit-ID: 7pGxwXDmKZO
--HG--
extra : rebase_source : d96ee8098e145c325c7a754f2b2017015884a70f
Make the onboarding being opt-in or opt-out depending on the default value of the
browser.urlbar.sugges.searches pref.
In both cases respect userMadeSearchSuggestionChoice though, so we won't further nag users that
made a choice already.
MozReview-Commit-ID: D4rRMRbdMrW
--HG--
rename : browser/base/content/test/urlbar/browser_urlbarSearchSuggestionsNotification.js => browser/base/content/test/urlbar/browser_urlbarSearchSuggestions_opt-in.js
extra : rebase_source : 819ba7a77998940fb230fb531dd9fcf1301cfcd5
This also activates the Favor fallback mode to give preference for HTML <video> content over Flash objects, and to not load Flash when the page has not speficied a src url (as the data attribute).
MozReview-Commit-ID: Lo4eWGbWyOt
Enabled by default behind the browser.suppress_first_window_animation pref.
MozReview-Commit-ID: 4mzy4Qif0LX
--HG--
extra : rebase_source : 926dd03514dd1792ee1c9d9a662a4a3657bc6796
Remove suggested and enhanced tiles along with related campaign, frequency-cap, inadjacency, pings, preferences, strings, styles, tests.
MozReview-Commit-ID: FkjaSpSFQHu
--HG--
extra : rebase_source : 1c58ac542180f0abb290639ec1c61b9edf3d0a51
This pref change will means that Flash will also start to be blocked on null or system principals, including chrome-privileged test files (e.g. mochitest-chrome/browser-chrome).
MozReview-Commit-ID: CmxF2dJubwS
To mitigate the delay that a new content process startup might cause, when the
browser reaches a non-busy state we attempt to prelaunch an empty content process
in the background that can be grabbed and used the next time we need one. This patch
enables the preallocated process manager by default and attempts to fix all the
issues that prevented us doing this sooner.
In order to rewrite the Gecko Profiler add-on as a WebExtension,
we need an API for the profiler which allows us to control the
nsIProfiler, and symbolicate the stacks that it provides. This
is the implementation of the simpler parts of that API.
TODO:
- Support profiling of remote targets through a new devtools
API.
- Support the dump_syms breakpad code which was asm.js in the
old extension by directly calling into native code.
- Figure out a faster way to send the large volume of data from
getSymbols all the way from our extension down to the content
process and then into the page's context.
MozReview-Commit-ID: JzDbV4l2eXd
--HG--
extra : rebase_source : fee9acfaa522372c22c61f9b0f1cab13d5da2a86
Note that the UITour library can still show a panel in the event that we want to
promote the feature that way.
MozReview-Commit-ID: FzKSzO987h7
--HG--
extra : rebase_source : 8c129106478559f011a3a4e311331851939ab408
When sending the shutdown ping we launched the pingsender executable via
PR_CreateProcessDetached() which on both Linux and MacOS X would fork()
gecko's main process and then exec() the pingsender executable. On MacOS X
this seemed to trigger a race with the mozalloc shutdown procedure within the
forked process. This patch changes the telemetry logic to use nsIProcess
instead which relies on posix_spawnp() to launch the new executable making it
immune to issues related to mozalloc's shutdown.
Since we don't need C++ code anymore to run the pingsender the runPingSender()
method is also moved to TelemtrySend.
MozReview-Commit-ID: C7fZw1ZpVBO
--HG--
extra : rebase_source : b6e1bd08f45533fceab4a2f2d81abd81c2267c9b
This rolls browser.tabs.animate, browser.fullscreen.animate, and
alerts.disableSlidingEffect into a single pref; if any of these are disabled,
we'll disable the new pref too (toolkit.cosmeticAnimations.enabled). Most
future animations will also be subject to this pref.
MozReview-Commit-ID: 77pLMtERDna
--HG--
extra : rebase_source : 8939e453c2277caa4a90123ae09bb542aaa421ed
Before bug 1348069, MS manifest tool was used to embed manifest files.[1]
The Makefile used to use EXTRA_DEPS to invoke the manifest tool when a manifest files is changed. But it is no longer effective because the manifest file namepattern is no longer $@.exe.manifest.
Now manifest files will be embedded via .res files. So we have to rebuild .res files to update embedded manifests.
[1] https://dxr.mozilla.org/mozilla-central/rev/35c7be9c2db288d1d449e3cc586c4164d642c5fd/config/rules.mk#642-655
MozReview-Commit-ID: 5QiXVeImZdY
--HG--
extra : rebase_source : 9e321e30ecd389ef0aa21e438d321e79edf0a009
1. Use the right strings in permission dialogs
2. Don't show permissions dialogs for non-promptable permissions
3. Enable dialogs by default
MozReview-Commit-ID: JJdxxcP7IeU
--HG--
extra : rebase_source : b5525cbae3822f3e2727788fd63580e6d5bd8293
Screenshots is a system add-on imported from https://github.com/mozilla-services/screenshots/.
This is the initial build system patch for building screenshots. ESLint is ignored since Screenshots currently use their own version (this may change in the future).
MozReview-Commit-ID: 4OEcaduaeWE
Screenshots is a system add-on imported from https://github.com/mozilla-services/screenshots/.
This is the initial build system patch for building screenshots. ESLint is ignored since Screenshots currently use their own version (this may change in the future).
MozReview-Commit-ID: 4OEcaduaeWE
--HG--
extra : source : d4b155c9ee3db31f5494e1d15bac0984932ed7a2
There's quite a few changes in here. At a high level, all we're trying to do
is to replace the old update popup with a less intrusive and more modern
doorhanger (set of doorhangers) for various update failure conditions.
MozReview-Commit-ID: 24sESMTosNX
--HG--
extra : rebase_source : ee0c1e00fe3f99e16388f0de17274ff97a3b9fcf
The .app directory for OSX builds is created piecemeal by several
commands in browser/app/Makefile.in, however it isn't normally cleaned
by a build. If a file is removed from the tree, it's possible that an
incremental build will still have a copy in the .app dir and get
packaged up in the final dmg. It's simple to just rm -rf this directory
beforehand.
MozReview-Commit-ID: 2Zr97o9dTn8
--HG--
extra : rebase_source : 2c9995991c58ee9724464514ec8285c31ab8d062
Code written by Manotej Meka <manotejmeka@gmail.com> and Ian Ferguson <fergu272@msu.edu>
This is the initial landing of the search feature, and is preffed off behind
browser.preferences.search.
MozReview-Commit-ID: 7iaeRsIIV3Y
--HG--
extra : rebase_source : 5e875ed0777397ecc6d98731179a1dfbd1f073df
This patch includes:
- (By Yoric) Don't collect/save the session when the user is idle;r=mdeboer
- Add a test for the behavior of state writing in idle/active mode
When the user is not actively using the computer, webpages may still
perform changes that require (re)writing to sessionstore, e.g. updating
Session Cookies or DOM Session Storage, or refreshing, etc. Before
this patch, a single active page can require us to
recollect/serialize/write the entire Session Restore file every 15
seconds even when the user is not in front of the computer.
We expect that, when the user is not in front of the computer, changes
are not critical and don't need to be saved as often. We now adopt the
following strategy:
- when the user has been away for (by default) 15 seconds, finish any
pending collect/write, then increase the collect/write buffering
delay to (by default) 1h
- when the user returns, reschedule any pending 1h collect/write as a
(by default) 15 seconds collect/write, then proceed with (by
default) 15 seconds collect/write delays.
--HG--
extra : histedit_source : b7ea6a6fbfee2f3a2bddeaa69b6446d7544c2585
MozReview-Commit-ID: 6G3zm2jrrMx
This patch needs to use different manifests depending on whether we are building
32-bit or 64-bit Firefox. In order to distinguish between them, I am using
checking for HAVE_64BIT_BUILD in the resource file and embedding the manifests
there.
--HG--
rename : browser/app/firefox.exe.manifest => browser/app/firefox.exe.32.manifest
rename : browser/app/firefox.exe.manifest => browser/app/firefox.exe.64.manifest
rename : ipc/app/plugin-container.exe.manifest => ipc/app/plugin-container.exe.32.manifest
rename : ipc/app/plugin-container.exe.manifest => ipc/app/plugin-container.exe.64.manifest
extra : rebase_source : 2d937f47c7b79a4f29a2c2001dec5ed8f00e54bc
This patch defines the concept of a "doctor" for collections. The doctor is
responsible for running all validators and deciding whether or not to initiate
a repair request based on the validation results.
MozReview-Commit-ID: 6NLRE6L0OpA
Hook this into the browser via the XREAppData. This patch does not include the changes to Chromium source code.
--HG--
extra : rebase_source : 4d5637bcdbeae605b0b99e9192598d48f371b698
Hook this into the browser via the XREAppData. This patch does not include the changes to Chromium source code.
--HG--
extra : rebase_source : e34e8b50101cc40ded26e80791052123b24c8243
extra : histedit_source : 69c9b2dc91546adbfdad03b5d43842809191ffb9
Assigns the preference security.sandbox.logging.enabled and the environment variable MOZ_SANDBOX_LOGGING to control whether or not sandbox violations are logged. The pref defaults to true. On Linux, only the environment variable is considered.
--HG--
extra : rebase_source : f67870a74795228548b290aec32d08552c068874
The FileExists check can be removed because the code loading the library
will handle that case already.
--HG--
extra : rebase_source : bac53d3f88ed1dd716ee1340d40dae42becdfdf0
Going further from the previous changes, all libfuzzer_main really does
is call the init function, and then proceed to call the fuzzer driver
with the testing function.
So instead of calling that function for it to do all that, the
LibFuzzerRunner can just call the init function itself, and then
call the fuzzer driver with the testing function.
--HG--
extra : rebase_source : 2eb1a2ae763ef21827471cd32addceacefc1ac5d
The LibFuzzerRunner code lives in libxul. It's unnecessary complications
to have it call back a function in the firefox executable just so that
it calls another function that is in libxul. Passing the init and
testing functions to the libfuzzer_main function allows to just bypass
that roundtrip, simplifying the setup.
--HG--
extra : rebase_source : ba72c029a904e05fe3b0ed5984c1bad946b73c6a
The function given to XRE_LibFuzzerSetMain is called from somewhere that
does have access to argc/argv already, so we can avoid passing them
to XRE_LibFuzzerSetMain.
This actually might fix subtle issues with argc/argv not really matching
reality when calling the LibFuzzerMain function in the current code:
some arguments are handled before the call, and both argc and argv are
modified from within XRE_main, but the values stored for the
LibFuzzerMain call still are the original ones.
Argv being a pointer, and it not being reallocated, the value stored for
the LibFuzzerMain call points to the changed one, but argc, being an
integer, is not modified accordingly.
In fact, it's actually worse, because while the Gecko code doesn't
reallocate argv, gtk_main might. So if some GTK flag is passed on the
command line, there's also a possibility that the LibFuzzerMain function
will do a use-after-free.
So all in all, it's just better to use the set of modified argc/argv
from XRE_main instead of storing them from main().
--HG--
extra : rebase_source : 92b89909eab0fc2f67ce372b959bb0e3ed12cd2b
Turns on sandbox denial logging if security.sandbox.logging.enabled is true.
Removes most sandbox violation messages but some related messages generated
by other processes will still get through.
--HG--
extra : rebase_source : 4f06e70d53b0f500cc85a869c5bd7f8ea20d8341
Reading application.ini involves using nsCOMPtr<nsIFile>, and that can
only happen through the XPCOM glue, which we eventually want to get rid
of.
So, while keeping the command line argument/environment variable
handling in nsBrowserApp, we move the actually parsing of the file to
XRE_main, where things can be handled without the XPCOM glue.
--HG--
extra : rebase_source : 487960a671476d4edae4f568c37efa6563ef4dff
This just wraps all the XRE method calls to go through the Bootstrap API
instead of relying on the XPCOM glue methods.
--HG--
extra : rebase_source : eccbe18b9b21ca1ab6c403515ffd60f0a9174d9c
Instead of having nsBrowserApp.cpp set a flag in XREAppData to indicate
whether the DLL blocklist properly initialized, just have XRE code ask
the blocklist itself.
--HG--
extra : rebase_source : e872853481acce68b325909e476d009aec878701
This hasn't been used since the removal of the Metro code in bug
1039866, close to two years ago.
--HG--
extra : rebase_source : 58ec1ce63e4231c8006cafd3424675f14ddbf9f1
It turns out nsAppRunner.cpp sets it to the exact same thing when it's
not already set, so we might as well use that.
--HG--
extra : rebase_source : cb8955e75c13a02494f3e163089c53696a661aa9
Back in bug 632404, when the function was added, preloading was
conditional. But after some A/B testing, the conclusion in bug 771745
was that we would just do preloading unconditionally.
Which means in practice, we don't need to have a function to enable it
manually anymore, since we're always enabling it.
--HG--
extra : rebase_source : c76307c13c057e87e1fe4564b82113fbfa20d382