FX_SESSION_RESTORE_COLLECT_DATA_LONGEST_OP_MS can go because that's exactly the same as FX_SESSION_RESTORE_COLLECT_DATA_MS now.
We can remove FX_SESSION_RESTORE_COLLECT_COOKIES_MS because that's just a flat line since bug 912717 landed.
Opening pages in a new tab might suffer an extra delay from e10s-multi because
the new process has to start up and then run all the process / frame scripts
before it can react on the request from the parent to load the first page.
There are two code paths. Either we start the tab with a remote browser and
then the RemoteWebNavigation will send the request. Or we start with a non-remote
browser and have to change the remoteness flag on it, and then the SessionStore
will send the request.
In each cases we start the timer on the parent side, send it with the message,
and when the child receives it it stops the timer and reports the measured delay.
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
This patch also moves the BUCKETS into a per-update-channel constant object at
the top of the file to allow for more easily configurable experiments on
multiple update channels running at once.
MozReview-Commit-ID: 9HTu5ssz4sG
--HG--
extra : rebase_source : 2f813b5f9ede43f68eac0f9a94a7a8e0be34a1bc
The goal of browser_bug795764_cachedisabled.js is to test elements using nsIApplicationCacheService so always enable siteDataGroup and offlineGroup there.
The goal of browser_bug731866.js is to test loading panes so move the checking of elements pref-on/off state to it.
MozReview-Commit-ID: 9QWMNnuu0OD
--HG--
extra : rebase_source : 323e05c493a575a879aff4cbceb84c332cf3a16f
Computing the subcategory based off of just the hash doesn't work when switchToTabHavingURI is used to open the preferences.
MozReview-Commit-ID: 5rYkiLkDgfT
--HG--
extra : rebase_source : 4edfa0e1e8f994625a7b7a9a3970acc6946a81f4
Since bug 912717 the cookies moved from state.windows[x].cookies (i.e. stored
per-window) to state.cookies (i.e. one global list of cookies). We forgot to
update the code in SessionSaver._saveState() that purges cookies upon clean
shutdown if requested by the user's preferences.
We can lower the eslint cyclomatic complexity threshold in some directories without adding eslint suppression comments in any .js source files. We need to specify the complexity rule in accessible/.eslintrc because it doesn't inherit the mozilla/recommended rules. eslint's default complexity threshold is 20.
Also bump the eslint-plugin-mozilla version because we modified the mozilla/recommended rules.
MozReview-Commit-ID: 57T4gAjPH7z
--HG--
extra : rebase_source : 4565abfa722b9459cfb4e006e843da13ed7cffd4
extra : intermediate-source : 658588564c08c9fd5e60633d1457f24087de8570
extra : source : 7e0526e3b943419a80c0cd2fa462cabbf8925eb1
The "no-spaced-func" name was deprecated in ESLint v3.3.0 and replaced by "func-call-spacing", which is already specified in the mozilla/recommended rules and some other .eslintrc.js files. We need to specify func-call-spacing in accessible/tests/browser/.eslintrc.js because it doesn't inherit the mozilla/recommended rules.
MozReview-Commit-ID: 7L8fuVtTu0X
--HG--
extra : rebase_source : 9cbd3717e6360d47b1a4589e8d5658ccf4bcba59
extra : intermediate-source : 61d723ca5f9b4dd9a22f2956c2f49d998e9db6c9
extra : source : e589244b9db5a744166ed151ff3e2e77432fdb04
Update tooltool manifests to reference rustc 1.16.0 stable repacks
which include cargo 1.19.0 nightly builds from 2017-04-19 which
support the RUSTC_WRAPPER environment override.
We're shipping with an unstable cargo while this feature makes its
way to release because it is necessary for deploying sccache support
for rust language code in our build and test automation.
MozReview-Commit-ID: Iow2894OPq7
--HG--
extra : rebase_source : f1a8e6cab612714f7b73ca8a14d14cabe9f4aef7
This patch replaces the usage of sNextTabParent pointer to store the next
PBrowser parent actor to be used by the next frame loader with the
following information:
* In the case where the content JS has requested a new tab, the ID of the
next TabParent will be stored on the <xul:browser> element.
* In the case where the content JS has requested a new window, the ID of
the next TabParent will be stored on the created nsXULWindow.
This matches the rest of the context menu and is better for unit tests.
MozReview-Commit-ID: 509HH4wnClN
--HG--
extra : rebase_source : 61456ee75f75baefd38fd9dd53e9cce9b7e3fefa
All of browser/ JS code passes these eslint rules, so we can hoist them from subdirectories' .eslintrc to the common browser/.eslintrc.
MozReview-Commit-ID: GMidHq0UIlH
--HG--
extra : rebase_source : 802631e372bbf6c256f5236deb275cb05fd73894
extra : histedit_source : a87b58345ff471b2504244d90c4ea1aa149a3c86
This eslint warning is a regression from bug 1340468:
browser/extensions/formautofill/content/FormAutofillFrameScript.js
warning Parameter 'aMessage' uses Hungarian Notation, consider using 'message' instead. mozilla/no-aArgs (eslint)
MozReview-Commit-ID: LqEZT0RNp7K
--HG--
extra : rebase_source : 25af56d0d1caa9cce7f03367bc61f88882e8d12b
extra : histedit_source : 0e25c63e195430a0b616144ee0cf1d141efabc8b
Previously we were showing a doorhanger when the user moused to the
top of the screen while in fullscreen mode. However, the doorhanger
would disappear before the user had a chance to interact with it.
We decided it's best anyway to simply display a badge when the user
is in fullscreen, and to reshow the doorhanger when the user exits
fullscreen.
MozReview-Commit-ID: ENRtXC4wqvZ
--HG--
extra : rebase_source : 4609fbc2d0bd38fe16a23151d94d265761cd57b0
A web page could generate an URL by URl.createObjectURL(new Blob(...));
then navigate to this generated URL.
In this case the (top-level) document URI will be blob:{origin}:{uuid}.
And we try to add firstPartyDomain on this top-level document with blob URI, so
the following request from this document could have correct origin
attributes.
* Track window states: active, fullscreen and tabsintitlebar for each window
* Use toolbar.id and window state to store and retrieve values from cache
* Note: As each window has its own ToolbarIconColor object, the cache is not currently shared across windows
* inferFromText callers pass in a reason and associated value, which is used to update the state we track, and potentially clear out the cache
* Create new windows test directory for browser-window-specific tests like this
* Test for the ToolbarIconColor changes to avoid sync style flushes when windows activate/deactivate
MozReview-Commit-ID: JDJ3RtL4Lge
--HG--
extra : rebase_source : f944ccd1c2340a5d2973bf47480a6eb78b2aae3b
This is just a small fix to the previous commit for bug 1352069 because one
line in the pref migration code was mispasted.
MozReview-Commit-ID: LnpUHKGAoKa
--HG--
extra : rebase_source : b16d6cfc83c2560025ff4fed626a8c59ce42f3fb
Change the ExperimentsService to get the current value of the preferences (since it only uses them once or twice), so that they match the values in Experiments, and avoid differences causing promises to be rejected in the updateManifest call.
Also fix Experiments to correctly re-enable itself when toolkit.telemetry.enabled is changed from false to true (also fixes bug 1232648).
Finally, add a catch for a promise when calling updateManifest so that we don't get an uncaught promise exception.
MozReview-Commit-ID: GD6gfcRSgbx
--HG--
extra : rebase_source : 44226ad68bc0bc8b9b763016ea54ca022bfcbcf9
If browser.cache.offline.enable was set to false, then calls to nsIApplicationCacheService would throw. The SiteDataManger and OfflineGroup using nsIApplicationCacheService has been moved into the privacy pane. We should test that the privacy pane is loaded well.
MozReview-Commit-ID: C9RRRYmb3Zb
--HG--
extra : rebase_source : b93ca35fdfe375b22dd82dfbc7c1ffe4cfde1d72
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
Implements "Sidebar" and "OutlineView" layouts for rendering the bookmarks of PDF
MozReview-Commit-ID: 2Evg13Ohwg
--HG--
extra : rebase_source : d04dd42b9f5f0d79d3290a40cbc4ec23720c864e
I checked each function of the old security.js to make sure there weren't any other missing functions.
MozReview-Commit-ID: DpFcAYsfcyg
--HG--
extra : rebase_source : 5d1b25ebde5a0cf8849210315c773bf25c10e7a3
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
Root domain icons are no more associated with their pages, BUT if the page uses
a root domain icon from another domain, it should still get an association with it
or we couldn't relate the two.
This also fixes an overlooked problem in PlacesTestUtils where Date objects
cross a boundary and fail instanceof checks. This causes failures in the same
test that this patch is modifying.
To protect from future similar issues some protection has been added to updatedPlaces
so that it will crash in debug builds.
MozReview-Commit-ID: 3MTKhGj3ehj
--HG--
extra : rebase_source : 55120252e7ea8abb91f21ca2486deddc43795142
Following https://github.com/webcompat/webcompat.com/issues/1360 , WebCompat
now accepts an arbitrary label (to help with sorting incoming reports), which
for media issues should be "type-media".
MozReview-Commit-ID: B3vaUOlhTBm
--HG--
extra : rebase_source : 73b32a3581cec665c11e745e59e6e025d9222e85
Root domain icons are no more associated with their pages, BUT if the page uses
a root domain icon from another domain, it should still get an association with it
or we couldn't relate the two.
This also fixes an overlooked problem in PlacesTestUtils where Date objects
cross a boundary and fail instanceof checks. This causes failures in the same
test that this patch is modifying.
To protect from future similar issues some protection has been added to updatedPlaces
so that it will crash in debug builds.
MozReview-Commit-ID: 3MTKhGj3ehj
--HG--
extra : rebase_source : e36ba1ab41649927f92fee053c10bf43474a0bcf
As of Firefox 52, Flash is the only NPAPI plugin ever activated. As a keyed histogram for all plugin names, PLUGIN_ACTIVATION_COUNT telemetry is unwieldy to view. We can use the BLOCKED_ON_PLUGIN_INSTANCE_INIT_MS telemetry probe's sample count to track the number of Flash instantiations.
MozReview-Commit-ID: 62iGNLQ0nnE
--HG--
extra : rebase_source : b4a31a6bcb7b2525693b078838de726023f37d14
In the past we used a fixed value for the firstPartyDomain of
NullPrincipal, now we derive it from the path of NullPrincipal, so it
will be unique everytime we create it.
The browser.contentPrincpal will report a null prinicpal instead of the actual
content principal if the tab is not loaded. So the SessionStore will collect a
wrong principal for the 'iconLoadingPrincipal', and it will use this wrong
principal to load favicon when session restoring.
To fix this problem, this patch makes the TabState.jsm to collect
'iconLoadingPrincipal' from browser.mIconLoadingPrincipal which will be the
correct principal for loading favicon.
MozReview-Commit-ID: AYUbHFKaG8v
--HG--
extra : rebase_source : 3e2333f18c221d415bd0e26bc416a841344cef2c
The newer Theming API follows the WebExtension install flow, which uses
PopupNotifications to request permission before installation, show progress and
notify upon install completion. This patch makes sure that older LWTs follow that
same flow.
MozReview-Commit-ID: C7X2si0a47J
--HG--
extra : rebase_source : 76f6283818dd69f62c4d59b6b11c5e90d37145a2
Put back in line that was incorrectly removed previously, and add a test.
MozReview-Commit-ID: FEl8fT1uCDm
--HG--
extra : rebase_source : 549b4d9ab9c963ab5a92b81311cffe07fae6953c
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
In the log file attached to this bug, we see multiple requests for
background updates come in at the same time. I can't see a way for
this to happen other than notify being called while the test is
running.
MozReview-Commit-ID: Gm0vW32X6mN
--HG--
extra : rebase_source : fe220a940b07bc45c10b460c22408eeecf3a3059
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
The version we update to is the current result from the
macosx64-cctools-port toolchain job.
(gotten with `mach artifact toolchain --from-build macosx64-cctools-port --nounpack`
and uploaded to tooltool)
--HG--
extra : rebase_source : 5d980012de2dfab0556ccb7ed27c434047054523
They are, in fact, the same version already, built from the same version
of clang-static-analysis-linux64.json, but one comes from a now expired
try build, and the other from a build on mozilla-central, that can still
be traced down:
https://tools.taskcluster.net/task-inspector/#Ro1bUCv4Svu2OWuQsOF_hA/0
--HG--
extra : rebase_source : 776314cecb3cba7043a02f4e1f2f4feb4b51731c
This patch creates a new print preview browser to host the simplified cloned-document
when Simplify Page option is used on preview. Also, this patch keeps track of what browser
should be presented, based on whether the 'Simplify page' checkbox is checked.
MozReview-Commit-ID: 77pLXhdbpPp
--HG--
extra : rebase_source : 7201f230299c571d6c3a86ce650d6852c43e0943
MozReview-Commit-ID: Kp8x5o66nrY
I want AccessibleHandler.dll to use different UUIDs based on release channel.
The way I was doing it before wasn't working correctly because I also wanted
local builds to have their own set of UUIDs vs our regular Nightly/Beta/Release
builds.
I also want the beta channel to have its own set of UUIDs that are distinct
from release.
I'm using MOZ_UPDATE_CHANNEL to distinguish between the channels when
NIGHTLY_BUILD and BETA_OR_RELEASE are insufficient.
--HG--
extra : rebase_source : 8cb28a22a3cac16fb743a8fe81db5e120c1fdf6d
Bug 588482 made it possible to restore pinned tabs in windows before restoring the rest of the
tabs. Part of this involves extracting the pinned tab data from the last session, and make it
the default state to restore. The rest can be restored later.
If one of the pinned tabs in a window were selected, the code that was preparing the default
state for that window set the selection value by calculating the length of the tabs array
(before adding the selected one), and adding 2. Presumably, 1 count is because of the tab
we're about to add, and another count is due to how the "selected" value in SessionStore
is 1-indexed (where "0" means, "don't change the selection").
This is an off-by-one error though, since the tabs array length already cancels out the
need for the extra "1-index" difference. It is sufficient to just add 1 to the length of
the tabs array to calculate the selected value.
This appears to have been a bug for a while, but was covered up by the fact that the old
tab selection code exited early if the 0-indexed value of the selected tab was not within
the length of the tabs array. Bug 1351677 uncovered this bug by removing that second check.
This patch fixes the off-by-one error, and also puts a check back in to ensure that the tab
we're going to select is at a valid index.
MozReview-Commit-ID: 9WbbU0vUJHG
--HG--
extra : rebase_source : cd5f4432c23084b672a844da40879bf53e393596
The tests in browser_tabCloseProbes.js were closing tabs without waiting for them
to be fully open, and when they're not fully open, closing occurs without animation.
This was intermittently breaking the test for the probe that checks that we add
a count to the right histogram when closing with animation.
MozReview-Commit-ID: 5Qz7mZvtbkB
--HG--
extra : rebase_source : 0d794faebc8e751bfcd15476ae849018dfb1f6c1
Current state:
--------------
Session cookies - those that have no Expires or Max-Age directive, sent as a
header or set via document.cookie - are meant to live for the duration of a
session. SessionStore is a feature that aims to enable users to resume where
they left off last time they closed the browser. So SessionStore will persist
and restore those cookies that the cookie service only keeps in memory.
SessionCookies.jsm registers observers with the cookie service and is thus
notified of cookie additions, deletions, and modifications as-it-happens. It
has its own internal storage that we could easily serialize and write to disk
together with the rest of the session data.
The hangs shown in various profiles stem from the fact that since the inception
of SessionStore as an add-on around Firefox 2, cookies have been tacked to
windows. This means that whenever we collect session data for a specific
window (i.e. tabs, their shistory entries, etc.) we have to iterate *all* its
tabs and *all* their shistory entries to enumerate the hosts contained in that
window. We will then ask the internal cookie store in SessionCookies.jsm to
give us all cookies for these hosts and then store them together with the
window. This way we filter out cookies from tabs/hosts that have no active
documents (BFCache counts as "active").
Changes in this patch:
----------------------
Instead of trying to only retain cookies from “active” documents, i.e. those
contained somewhere in the shistory of a tab, we now simply save all session
cookies of the session. This will surely reduce user complaints about us
"logging them out" too fast because we discard cookies from tabs they
open only once in a while, although those definitely belong to the
browsing session.
Instead of storing the cookies per each window we now have a top-level
"cookies" attribute that is a list of cookies. These get restored whenever we
restore a session. Legacy window.cookies attributes will still be restored to
support older session formats for a while.
The DEFER_SESSION startup mode is active by default when a user choses not to
restore their whole session automatically but they still have one or more
pinned tabs. These pinned tabs are restored automatically and split off of the
rest of the session. The rest can be restored manually if the user chooses to
do so.
In the past, we here extracted and restored only the pinned tabs' cookies from
the last session. This filtering also works against how some sites (e.g.
Google) use session cookies. It also means we have to iterate all windows,
tabs, shistory entries, and cookies to find the data we want.
This patch changes our past behavior so that we now restore only pinned tabs
but all session cookies. So we don't have to filter, and pages will break less
likely. We hereby assume that a user having pinned tabs wants to continue their
browsing session partially, although without Firefox remembering the exact list
of tabs. Or they simply like starting off of a clean slate.
There are 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 success and failure conditions.
There are 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 success and failure conditions.
This reduces the amount of places where we need to specify the mozilla/frame-script environment. It does have
the side effect of allowing those globals in the whole file, but that is what specifying the environment would
do, and this is also for mochitest test files only.
MozReview-Commit-ID: 1LLFbn6fFJR
--HG--
extra : rebase_source : 82a6934d90bbbbd25f91b7b06bf4f9354e38865a
When font.name.*.* is set to false, "value" attribute of <preference> is removed. Then, <preference>.setElementValue() with an element which doesn't have onsyncfrompreference tries to set null. Then, <menulist> selects nothing.
In such case, <menulist> should select the item whose value is "". If there is onsyncfrompreference attribute and it returns empty string, <preference>.setElementValue() works as expected.
MozReview-Commit-ID: 54KIe3JxwyA
--HG--
extra : rebase_source : 8b94ff9a790cb5f771901cbfea72240d6d8df554
Update also the similar logic in browser/installer/package-manifest.in. The
reason I added the symbolizer is because it'd be useful when someone conduct
jsshell testing/fuzzing.
MozReview-Commit-ID: J9IqFWsnskS
--HG--
extra : rebase_source : db461065f778fc025576b1fc7612642181d94dcd
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
It isn't needed until we create a context menu.
MozReview-Commit-ID: 4kCfq9PzVPV
--HG--
extra : rebase_source : 51907d6aa28d5bd2a9fb8a0acb28cac719888292
This avoids importing ContentWebRTC.jsm unless webrtc is actually
being used, which reduces memory usage.
MozReview-Commit-ID: GlMo1WIZEFD
--HG--
extra : rebase_source : 25476c825bef1948f22d0e6dae67dc01ab41f886
This avoids importing ContentWebRTC.jsm just to register observers
that may never observe anything. Avoiding importing .jsms reduces
memory usage.
ContentObserver.js gets loaded once per content process, so I think
the ._initialized stuff is not needed in the process script.
MozReview-Commit-ID: 5r9L3bfFS0U
--HG--
extra : rebase_source : 0fe6e14c2963efccf21bd1606885098902fed598
The tests in browser_tabCloseProbes.js were closing tabs without waiting for them
to be fully open, and when they're not fully open, closing occurs without animation.
This was intermittently breaking the test for the probe that checks that we add
a count to the right histogram when closing with animation.
MozReview-Commit-ID: 5Qz7mZvtbkB
--HG--
extra : rebase_source : 3533f2c43091829723463f8943cf43e722bbd70c
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
This avoids a sync IPC message from child to parent.
Changes entirely from:
https://github.com/mozilla/pdf.js/pull/8218
MozReview-Commit-ID: 3Egayok3DBZ
--HG--
extra : rebase_source : e02829e2508bb75caf44c0a3c86b06fac3bf167f
One is always run, the other is only run when PdfJs.enabled is true in
the parent process. This refactoring enables the next patch.
The extensions changes are from:
https://github.com/mozilla/pdf.js/pull/8218
MozReview-Commit-ID: HwQ3yk8Jck4
--HG--
extra : rebase_source : 94f1516989685176a95e235f2d3ef8658adaf8b7
MozReview-Commit-ID: CIrC4ise4Zs
Hotkeys works like normal DOM links, except "Open in background tab" (which corresponds to ctrl/command + click)
open tabs in foreground due to limitation from outside chrome process.
--HG--
extra : rebase_source : 6a3b43c518e23c61fe3c48cc4317b813a39acc7a