The Marionette component ships in Firefox, but is not enabled by default.
We want to facilitate activating Marionette at runtime by flipping
the marionette.enabled preference, and showing the Marionette related
preferences in about:config helps discoverability.
It is also useful to rely on the preferences' default values so that
they do not have to be hardcoded in the component.
When Marionette is enabled by setting marionette.enabled to true, a set of
recommended automation preferences found in testing/marionette/server.js
are set if the user has not overriden/user-defined one of them and
marionette.prefs.recommended is true (default). When Marionette is
stopped, the altered preferences are reset.
MozReview-Commit-ID: 3HLnEI0TEBB
--HG--
extra : rebase_source : 6557962c8dbd91002bbf22690ef03cd4cbcbbe38
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
CLOSED TREE
Backed out changeset 941e0f9ff9a7 (bug 1351074)
Backed out changeset 4fdf3b87a70b (bug 1351074)
Backed out changeset 586428f69838 (bug 1351074)
TESTING_JS_MODULES uses testing-common, not gre. So we should replace gre with testing-common for mochitest.
MozReview-Commit-ID: BqsS2D3IGR6
--HG--
extra : rebase_source : 2143fcdf33c428c82c6b2e00b542649b958aeccc
FontBuilder adjusted font settings if reading font isn't available in the system. Now, we support empty string value of "font.name.*" which means default font in the system. If it's empty string, gfx checks default font from "font.name-list.*" at runtime. Therefore, resetting "font.name.*" to empty string is the best approach if specified font becomes not available (e.g., uninstalled from the system).
Therefore, this patch replaces the code in FontBuilder.readFontSelection() with just returning empty string.
MozReview-Commit-ID: HgR88Qw8Xwe
--HG--
extra : rebase_source : 3878bf6a1c98ef7ba27c2cbdaaa9307061820f85
Since AsyncSpellCheckTestHelper.jsm is test only file, so we have to remove it from whitelist.
MozReview-Commit-ID: J9T6iaUdDgx
--HG--
extra : rebase_source : 6be252f9da67742f9caf63edce037e686a3601ed
TESTING_JS_MODULES uses testing-common, not gre. So we should replace gre with testing-common for mochitest.
MozReview-Commit-ID: BqsS2D3IGR6
--HG--
extra : rebase_source : a8553684f8f106c1dfb6e2d9b51df7ebeb15275d
The Marionette component ships in Firefox, but is not enabled by default.
We want to facilitate activating Marionette at runtime by flipping
the marionette.enabled preference, and showing the Marionette related
preferences in about:config helps discoverability.
It is also useful to rely on the preferences' default values so that
they do not have to be hardcoded in the component.
When Marionette is enabled by setting marionette.enabled to true, a set of
recommended automation preferences found in testing/marionette/server.js
are set if the user has not overriden/user-defined one of them and
marionette.prefs.recommended is true (default). When Marionette is
stopped, the altered preferences are reset.
MozReview-Commit-ID: 3HLnEI0TEBB
--HG--
extra : rebase_source : 00b22e2b63cf2f5183c49bdc84bcc172b8a4c3a1
The Marionette component ships in Firefox, but is not enabled by default.
We want to facilitate activating Marionette at runtime by flipping
the marionette.enabled preference, and showing the Marionette related
preferences in about:config helps discoverability.
It is also useful to rely on the preferences' default values so that
they do not have to be hardcoded in the component.
When Marionette is enabled by setting marionette.enabled to true, a set of
recommended automation preferences found in testing/marionette/server.js
are set if the user has not overriden/user-defined one of them and
marionette.prefs.recommended is true (default). When Marionette is
stopped, the altered preferences are reset.
MozReview-Commit-ID: 3HLnEI0TEBB
--HG--
extra : rebase_source : 56e99bb5d075b54dedc2a957e0f46a209a1e48a8
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 : 4444caea3622bcd2ff4ca49d23fa8b609e724146
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
Historically changes to shipped-locales landed in mozilla-aurora directly, skipping mozilla-central.
With Project Dawn we'll land these changes directly to mozilla-central, and let them ride the trains to
mozilla-beta, so we should sync their content.
MozReview-Commit-ID: DRuK5K7FJuI
--HG--
extra : rebase_source : dad327e6564c244c394afdb5d9e2a79d4dd65cc9
A new function Classifier::AsyncApplyUpdates() is implemented for async update.
Besides, all public Classifier interfaces become "worker thread only" and
we remove DBServiceWorker::ApplyUpdatesBackground/Foreground.
In DBServiceWorker::FinishUpdate, instead of calling Classifier::ApplyUpdates,
we call Classifier::AsyncApplyUpdates and install a callback for notifying
the update observer when update is finished. The callback will occur on the
caller thread (i.e. worker thread.)
As for the shutdown issue, when the main thread is notified to shut down,
we at first *synchronously* dispatch an event to the worker thread to
shut down the update thread. After getting synchronized with all other
threads, we send last two events "CancelUpdate" and "CloseDb" to notify
dangling update (i.e. BeginUpdate is called but FinishUpdate isn't)
and do cleanup work.
MozReview-Commit-ID: DXZvA2eFKlc
--HG--
extra : rebase_source : cd2e27a6b679d2c96e769854d1582ed2dcda12bb
This patch also changes the 'headerURL' and 'theme_frame' properties to be of type
ExtensionURL, instead of strings. This improves validation robustness.
Alignment and tiling properties for the additional background images can be
specified in the newly introduced 'properties' section of the manifest.
MozReview-Commit-ID: BzvS3eHmDCY
--HG--
extra : rebase_source : 03560c0441bd2a6643c20a3f1fff8b905eca59ad
This intermittent was likely occurring because we set the expiry timeout
for temporary permissions to a really low value in the previous test.
The failing test was only failing on slow machines, leading me to believe
that the time between setting and checking was larger than the 500ms timeout
defined in the previous test. Thus, the permission was reset on checking it.
The expiry pref was set using pushPrefEnv, which restores prefs only after
the entire test was run. To just eradicate this category of problems in
the future I moved the test that manipulates the expiry into its own file.
MozReview-Commit-ID: 3mc5xHY4XLn
--HG--
extra : rebase_source : 40f78258a975da9dca9a47beddcaaeea83649de3
PrivacyLevel checks currently allow to disable storing secure cookies and any
cookies belonging to an HTTPS host, or completely disable storing cookies. We
call PrivacyLevel.canSave() for every host found in the shistory of a given
window's tabs. We then call it again for every cookie when retrieving all
cookies stored for a given host.
The two different privacy checks exist because in the past an HTTP site could
send a secure cookie too. Since Firefox 52 this isn’t possible anymore, only
HTTPS sites can send secure cookies. So as soon as nsICookie.isSecure=true
we know the site was loaded over TLS.
That means there are the following scenarios:
[PRIVACY_LEVEL=NONE] (default)
We store all cookies.
[PRIVACY_LEVEL=FULL]
We store no cookies at all.
[PRIVACY_LEVEL=ENCRYPTED]
HTTP site sends cookie: Store.
HTTP site sends secure cookie: Can't happen since Fx52
HTTPS site sends cookie: Store. The site is HTTPS but we should store the
cookie anyway because the "Secure" directive is missing. That means the
site wants us to send it for HTTP requests too.
HTTPS site sends secure cookie: Don't store.
This allows us to simplify the code and remove the per-host PrivacyLevel
checks. Checking nsICookie.isSecure is enough to tell whether we want
to keep a cookie or not.
During the test, we open a new window which loads a URL, and have code to wait for that
initial browser to complete the load. For the initial browser, there is (when we open
a remote-able URL), the remoteness of that initial browser flips from non-remote to
remote. Sometimes, due to messaging / timing, the initial browser will send a message
saying that a load completed for the initial about:blank before the URL we actually
want is loaded. This causes the test to continue, and attempt to click on an element
that isn't actually on the page yet.
This modification allows us to wait for the initial browser to actually load the page
that we care about before proceeding.
I also changed some of the assertion messages to actually reflect what's being asserted,
as opposed to reflecting what is being revealed if the assertion fails.
MozReview-Commit-ID: 608SaA1nCVs
--HG--
extra : rebase_source : 0662d166e10de5036c40b278554ff5b3dd11de04
extra : source : 4255a184eac6d037763deb9319df652abf5f703b
This patch adds two more test cases, browser_roundedWindow_open.js and
browser_roundedWindow_windowSetting.js. The browser_roundedWindow_open.js tests
the window.open() with window features, it will test window.open() with numbers
of window features to see that whether the opened window is correctly rounded.
The browser_roundedWindow_windowSetting.js tests the setting of
innerWidth/Height and outerWidth/Height. To see that the window is correctly
rounded or not after the setting.
This patch also adds a head.js and rename the browser_roundedWindow.js to
browser_roundedWindow_newWindow.js. The head.js carries two helper functions
that calculate the maximum available content size and the chrome UI size of
the pop up window.
MozReview-Commit-ID: LxJ2h2qAanY
--HG--
extra : rebase_source : b3744155fda93bd9e1650d07db7105092a2e5260
This tweaks the temporary qualification step (currently used only for DevTools)
so that it does not apply on channels that are 100% enabled anyway. This does
not change how many users receive e10s on, it only tweaks who falls into which
cohort, since there's no reason to push all DevTools users to a special cohort
if everyone would have received e10s on anyway.
MozReview-Commit-ID: 5Yn6M50Ny1w
This changeset changes tests using ForgetAboutSite.removeDataFromDomain
to yield on it, since now it is a Task
MozReview-Commit-ID: 72OEYoO1avd
--HG--
extra : rebase_source : 9ea8cc06493c3e965d260dc9377461ff29fe572a
Amended to fix review changes
(stylistic + other)
Turns all cleaners into promises so they run asyc
MozReview-Commit-ID: DV5ug6vNXkS
--HG--
extra : rebase_source : df9d9cd98f25e2a899c0a74f836f217d3ad52426
I'm not sure this is necessarily going to do anything about the intermittent,
but at the least it will remove a bunch of noise from the logs hopefully
making it easier to get to the real problem.
MozReview-Commit-ID: KeGWJlHUlzh
--HG--
extra : rebase_source : f1603fe652bace143ff5e73d85181592028dbc24
The FX_PREFERENCES_CATEGORY_OPENED probe must be extended to version 59 to support the fallback "forked" preference implementation (in-content-old).
The switchToAdvancedSubPane within utilityOverlay's openPreferences must also remain until the fallback has been removed (bug 1349689).
Patch co-authored by Zack Herrick <herrickz@msu.edu> and Ziyan Long <lzylong@gmail.com>.
MozReview-Commit-ID: 1sx0Wj15yM7
--HG--
extra : rebase_source : 0266027fb3023d4cb155533193d6809d799de1e4
The first change we can make is to simplify the PrivacyLevel.canSave() method
itself as it only takes a single argument, `isHTTPS`. Callers shouldn't be
required to pass an object, they should simply pass a boolean.
The second change here is to cleanup SessionCookies.jsm that still passes the
old `isPinned` argument that's no longer needed. We can remove some house
keeping and simplify the cookie collection code.
SessionCookies.getHostsForWindow() that previously returned a map from hostnames
to a site's pinned status (tab.pinned) can now simply return a Set containing
all hostnames found in a window.
Re-apply the patch from bug 1327953 since it got lost in the re-arrangement of preference code in bug 1335907.
MozReview-Commit-ID: 1L4A2QC3Bns
--HG--
extra : rebase_source : 90b19dcd953cf15aaf478125df28dcce3381debc
This removes all the code for add-on performance watching from the
perfmonitoring component. This should mean that for add-on
compartments, we no longer trigger jank or CPOW monitoring in the JS
engine. This should result in minor performance improvements. As a
result, about:performance no longer reports on add-on performance
(but still reports on web page performance).
It also removes the AddonWatchers.jsm module and the related Nightly-
only UI (disabled in the parent commit) and strings. This UI wasn't
ready for release, there wasn't sufficient data it was creating
value for users, and there was some evidence that it didn't always
correctly identify the cause of performance issues, thus potentially
leading to user confusion or annoyance. Removing it therefore seemed
the right thing to do.
MozReview-Commit-ID: LsRwuaUtq6L
--HG--
extra : rebase_source : 92d4b775a7a7cbb5793e74eea471be81be974dda
This is to make sure that the text will wrap and not force the box to have its full width. These changes look to have gotten lost as part of the re-org in bug 1335907.
MozReview-Commit-ID: EiTALg6dY7G
--HG--
extra : rebase_source : b14834435b60ff139e562cf91789d6ee9c42fba4
Replaced it with BrowserTestUtils.waitForErrorPage instead.
MozReview-Commit-ID: KsVjMlaZaa6
--HG--
extra : rebase_source : 7754cd3eab18731b79afa7de0383ccb7fd39eb34
The comparison being removed was only put in place because it seemed like a "good-idea" to prevent <select> from being unreadable, though it's not a fool-proof strategy and it breaks content that uses different styling approaches. This removal does not regress any of the other test cases.
MozReview-Commit-ID: 8HeXZXnjpbl
--HG--
extra : rebase_source : f4eb33de4a8b795fe5dd90c1ede510e8584bf53e
The FX_PREFERENCES_CATEGORY_OPENED probe must be extended to version 59 to support the fallback "forked" preference implementation (in-content-old).
The switchToAdvancedSubPane within utilityOverlay's openPreferences must also remain until the fallback has been removed (bug 1349689).
Patch co-authored by Zack Herrick <herrickz@msu.edu> and Ziyan Long <lzylong@gmail.com>.
MozReview-Commit-ID: 1sx0Wj15yM7
--HG--
extra : rebase_source : 29359bb726a0ac8164d7304a2453ffeb8009e990
This patch also changes the 'headerURL' and 'theme_frame' properties to be of type
ExtensionURL, instead of strings. This improves validation robustness.
Alignment and tiling properties for the additional background images can be
specified in the newly introduced 'properties' section of the manifest.
MozReview-Commit-ID: BzvS3eHmDCY
--HG--
extra : rebase_source : c421a7feaa8492fae40258086bdb7e4fcc51a80d
This extends the existing the existing scroll position test by navigating to a second page and then checking that after closing and restoring that tab, the scroll position is restored not only for the current history entry, but after going back as well.
MozReview-Commit-ID: Ddig1Mfo5rz
--HG--
extra : rebase_source : 20bdc1f116b27f7386a9b7d1cdc0ad383b21b99c
Since a LayoutHistoryState is basically just a collection of PresStates, we just save each PresState we can find and then later restore it.
MozReview-Commit-ID: A6WpdelseHn
--HG--
extra : rebase_source : 21c2929ed64ff5ef046ea65664af78cdad517786
Updates consumers to the new behavior.
Some consumers are changed to use the "page-icon:" protocol, since it's not
trivial to join the icons table and get a single result out of it. In most cases
the join would return multiple results since a page can have multiple icon payloads.
These consumers for now will return the biggest payload, bug 1347532 will fix
some of them to properly pass a #size=NN fragment.
Note that, even before, these were just "moz-anno:favicon:" uris, and the
payload had to be fetched from the database.
Some other consumers for now just fallback to the largest payload, by passing 0
to GetFaviconURLForPage.
The favicon optimization still happens on the main-thread, bug 1346139 will
handle that problem.
Most of the changes involve handling the modified IconData objects, that now
retain an array of payloads, rather than just one. But note that .ico files are
not yet split into single frames, due to imagelib missing APIs that will be handled
in bug 1337402.
The other changes involve fixing queries to properly join with the new tables.
Finally, note that thanks to the FOREIGN KEYS support, removing from moz_icons or
moz_pages_w_icons will also remove relations from moz_icons_to_pages.
The system only supports square icons, so icons are resized based on their larger side.
This doesn't include new tests, those will be in a following changeset.
MozReview-Commit-ID: JUkpquhpS8y
--HG--
rename : toolkit/components/places/tests/unit/test_svg_favicon.js => toolkit/components/places/tests/favicons/test_svg_favicon.js
extra : rebase_source : fa49c4a81d6ab6b34a2f19ee4175e889a6e9d734
Open webcompat.com in new tab, similar to what "Report Site Issue" button does.
MozReview-Commit-ID: 1ESOY3upHgc
--HG--
extra : rebase_source : 3f55c6798671ad430e59f5954a177a22b4b7642d
Thanks to the previous patch, these tests can now be run on Mac, though they
don't do anything useful there just yet.
MozReview-Commit-ID: 3HyN7ms1EPl
--HG--
extra : rebase_source : c9487790d9c424dd8d21cfb6af927fd4121a15fa