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
With this patch, permissions are not actually applied,
but the permissions api is in place.
MozReview-Commit-ID: CTaXz5sa1xy
--HG--
extra : rebase_source : d5cc18abbae6809b196f8497ff91608d662d5030
extra : source : e4c13d11e401ae3bd40be3a5a7fb0aaf95c992bb
- Convert the object used to represent permissions to the format
used in the optional permissions UI (property hosts becomes origins)
- Turn Extension.userPermissions into a getter
MozReview-Commit-ID: Dc44DMfKjG
--HG--
extra : rebase_source : e24e1b52edd3ddcd353a6407497ec4076039af03
This patch makes urlbarBindings.xml use AppConstants from the global scope and
removes the related field.
MozReview-Commit-ID: E2KvOsZVX7q
--HG--
extra : rebase_source : f0d8c35e17717d81ae1d7d2d1cc5fea21b1b5ccd
With this patch, permissions are not actually applied,
but the permissions api is in place.
MozReview-Commit-ID: CTaXz5sa1xy
--HG--
extra : rebase_source : d5cc18abbae6809b196f8497ff91608d662d5030
extra : source : e4c13d11e401ae3bd40be3a5a7fb0aaf95c992bb
- Convert the object used to represent permissions to the format
used in the optional permissions UI (property hosts becomes origins)
- Turn Extension.userPermissions into a getter
MozReview-Commit-ID: Dc44DMfKjG
--HG--
extra : rebase_source : e24e1b52edd3ddcd353a6407497ec4076039af03
CLOSED TREE
Backed out changeset 24f52ebe6dc9 (bug 1096013)
Backed out changeset dc7d1c21c857 (bug 1096013)
Backed out changeset 28229b5ba95a (bug 1096013)
With this patch, permissions are not actually applied,
but the permissions api is in place.
MozReview-Commit-ID: CTaXz5sa1xy
--HG--
extra : rebase_source : d5cc18abbae6809b196f8497ff91608d662d5030
extra : source : e4c13d11e401ae3bd40be3a5a7fb0aaf95c992bb
- Convert the object used to represent permissions to the format
used in the optional permissions UI (property hosts becomes origins)
- Turn Extension.userPermissions into a getter
MozReview-Commit-ID: Dc44DMfKjG
--HG--
extra : rebase_source : e24e1b52edd3ddcd353a6407497ec4076039af03
With this patch, permissions are not actually applied,
but the permissions api is in place.
MozReview-Commit-ID: CTaXz5sa1xy
--HG--
extra : rebase_source : f623b4c7c66888ab1fb4876a3d63ec47677711b8
extra : source : e4c13d11e401ae3bd40be3a5a7fb0aaf95c992bb
- Convert the object used to represent permissions to the format
used in the optional permissions UI (property hosts becomes origins)
- Turn Extension.userPermissions into a getter
MozReview-Commit-ID: Dc44DMfKjG
--HG--
extra : rebase_source : 4924aa007da4b649266311138b4d240eeeade9a4
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 : d8d76945d6e36023a7ea9395c3a7355f346df0f0
Merge "DOMServiceWorkerFocusClient" & "DOMWebNotificationClicked"
to "DOMWindowFocus" event. Utilize the event to switch tab when
loading links to an existing target tab.
MozReview-Commit-ID: Hd1NkVkrJA1
--HG--
extra : rebase_source : 745c0d66c3afd8e487c616891c0f10bd820da1fe
HTMLMediaElement relies on user's interaction to allow playback when media.autoplay.enabled set to false.
MozReview-Commit-ID: IPZdAAKlrjM
--HG--
extra : rebase_source : c1654b47fc7b14b1a5b5309c38e60d246edafc54
This patch also fixes a bug in our UpdateDropDown code where we weren't computing updated styles for <select> element, as well as another bug where we weren't passing the correct number of arguments to this.populate.
MozReview-Commit-ID: 8LAeIliRXhZ
--HG--
extra : rebase_source : 19c573ffebf700de4b4a470ceb1d2706a8088574
This looks to be happening because the binding for the checkbox may get torn down too fast when a restart is required.
MozReview-Commit-ID: 1y68jMubATx
--HG--
extra : rebase_source : 5e3277e71e771b13179b60f77352e8a5bea56d5d
This patch removes the redundant lazy import of AppConstants.jsm from
browser/base/content/browser.js since it gets loaded previously as described
in the bug description.
MozReview-Commit-ID: EoSfSgedgNc
--HG--
extra : rebase_source : 8db27f79b9b43559ed4f94457592b092c5f75942
checkEmptyPageOrigin was only checking the currentURI on the passed browser for about:blank, but
sometimes the currentURI isn't the whole picture. For example, SessionStore, after restoring a
window, can cause a number of blank tabs to start to load, be cancelled, and have their history
replaced. This results in a bunch of unrestored background tabs that appear to have currentURI
set to the URI that the tab will be sent to once restored, but a null content principal, since
the original about:blank load was stopped before it could complete.
We side-step this issue by checking both the currentURI and the documentURI for about:blank
when comparing against the null principal for checkEmptyPageOrigin.
MozReview-Commit-ID: Kzm0MthLqVM
--HG--
extra : rebase_source : e6a83368dd99d458333789f9d986e4706cd4d2bf
Originally, we were forcing these restored background tabs to be non-remote by default.
This was because we didn't want them to show the crashed tab favicon nor show about:tabcrashed
if the user hadn't restored them before.
Bug 1241459 added infrastructure that makes it possible to put crashed background tabs into
the "restore on demand" state again, without showing about:tabcrashed or showing the crashed
tab favicon.
This means we should be able to restore tabs in the content process again which should take
some load off of the parent process during session restore, which is good for perceived
performance.
Note that if the content process does crash, the background tabs are then loaded in the parent
process. Restoring them on demand will then do the remoteness flip.
MozReview-Commit-ID: 1mWe0td6geB
--HG--
extra : rebase_source : ea872b615ebe3d8639b214bfafc5e358ba6e65fd
This helps differentiate restorations that were caused by navigateAndRestore, as opposed
to SessionStore having set state via setBrowserState, setWindowState, or setTabState.
MozReview-Commit-ID: DEEbKLh7f7p
--HG--
extra : rebase_source : c48ab225d17128041ccbde4e5cc8c87899166b9e
In bug 1044586 we changed nsDocument::GetEventTargetParent such that events for
a document were not sent to its parent window if the inner window for the
document wasn't the current inner window. Unfortunately it seems this means
event listeners on the window sometimes miss user input events (mousedown etc.)
when user input takes place before the first paint of a new document that's
loading. In order to fix this, this patch backs out the changes from bug 1044586.
This reintroduces the issue we had before with the preference window, where
reloading the preferences quickly meant that its listeners (attached to the
window) got confused by DOMContentLoaded events from a previously loaded
document. Instead of the broad fix to nsDocument::GetEventTargetParent, this
patch simply changes the event listeners from the preferences code to be
attached to the document instead of the window, thus ensuring they only get
notified for events relating to their own document.
MozReview-Commit-ID: 9DImyNst9fS
--HG--
extra : rebase_source : 94936a0ec7e60d61b25ea2e2f3236884b3cf4293
This patch removes code marked with #ifdef CRH_DIALOG_TREE_VIEW
since it's not used anymore as described in the bug description.
MozReview-Commit-ID: 6VnJIIGtGVl
--HG--
extra : rebase_source : 3c181a33d90ebf4621fee61fe4e667cc11410167
MozReview-Commit-ID: 5RlLYy7O9yi
Removed all rules of #alltabs_undoCloseTab, class="menuitem-iconic" and the .png
images
--HG--
extra : rebase_source : c475714b162d84a074fc65bcde9138c58217ca8c
Merge "DOMServiceWorkerFocusClient" & "DOMWebNotificationClicked"
to "DOMWindowFocus" event. Utilize the event to switch tab when
loading links to an existing target tab.
MozReview-Commit-ID: Hd1NkVkrJA1
Enable the rule with the maximums set to avoid current failures, except for test_form_autocomplete which is very
high (82). The levels are set per major area, with existing warnings being changed to errors.
MozReview-Commit-ID: 37M6Ry0Mr1c
--HG--
extra : rebase_source : 07e6864bdd945eb322499912dd702638430c0365