Removed the icon class from file column. I kept the css classes in RequestList.css so that we can easily add icons later.
Differential Revision: https://phabricator.services.mozilla.com/D21783
--HG--
extra : moz-landing-system : lando
If we're opening a private browsing window on startup, we won't run the
session restore code, and thus we won't end up cleaning up the preopened
tabs. This raises the question: are there other scenarios where we won't
run restoreWindow at all? Eyeballing the code I think not, but I'm not
sure.
Depends on D22195
Differential Revision: https://phabricator.services.mozilla.com/D22216
--HG--
extra : moz-landing-system : lando
This will fix the behavior, I think it might still be worth deliberating
over whether we want to consider non-default userContextId's when tracking
the number of pinned tabs or not. This will be visually correct - the
number of pinned tabs won't change, so things won't be moving around in
the tab bar, but we will throw away the preopened tab once we get further
down in SessionStore.jsm, which is less than ideal.
Differential Revision: https://phabricator.services.mozilla.com/D22195
--HG--
extra : moz-landing-system : lando
Track the number of times people use any of the export options from the Changes panel:
- Copy All Changes button
- Copy Rule button
- Copy Rule context menu option
- Copy Declaration context menu option
Differential Revision: https://phabricator.services.mozilla.com/D22090
--HG--
extra : moz-landing-system : lando
Bulk memory operations can be enabled at the same time Cranelift is, in which
case partial initialization of elements/segments/etc. implementation is
statically implemented, but dynamically controlled by wasmBulkMemoryOps().
Cranelift doesn't implement bulk memory operations yet, so wasmBulkMemoryOps()
returns false, while the static behavior is there. Thus, we have to temporarily
disable partial initialization tests when running with Cranelift. This will go
away when Cranelift supports bulk memory operations.
Differential Revision: https://phabricator.services.mozilla.com/D22271
--HG--
extra : moz-landing-system : lando
Nearly all dependencies except moznetwork and moztest already
support Python3. Lets make those releases the minimum allowed
version.
Differential Revision: https://phabricator.services.mozilla.com/D22105
--HG--
extra : moz-landing-system : lando
realigning the RTP stats types to match spec. This involves breaking out the remote dictionary types. This shouldn't create user space visible changes.
Differential Revision: https://phabricator.services.mozilla.com/D20432
--HG--
extra : moz-landing-system : lando
The SelectedOneOffButtonChanged event can fire when the popup is closed, so we should ignore it then. browser_switchTab_decodeuri.js hits this, as Mark says in the bug. The stack is:
_on_SelectedOneOffButtonChanged@resource:///modules/UrlbarView.jsm:569:131
handleEvent@resource:///modules/UrlbarView.jsm:298:23
dispatchEvent@chrome://browser/content/search/search-one-offs.js:147:20
set selectedButton@chrome://browser/content/search/search-one-offs.js:306:10
_on_popuphidden/<@chrome://browser/content/search/search-one-offs.js:1281:7
Alternatively we could modify the selectedButton setter in the one offs not to fire the event when the popup is closed. However, theoretically someone could be interested in listening for the selected button change even then, so I think it's better to modify the listener here.
Differential Revision: https://phabricator.services.mozilla.com/D22204
--HG--
extra : moz-landing-system : lando
The jar log is used for optimization of the packaged jar files according
to their usage patterns during a profile run. The current content of the
file currently come with 2 caveats:
- it contains entries for jar archives that aren't relevant to
packaging, which is not a problem in itself, but see below.
- it contains full paths for jar archives that may not correspond to the
location of the packaged directory (on e.g. Android, where the build
almost certainly doesn't happen in the same directory on the host as
Fennec runs in the emulator/on the device).
The current JarLog code does somehow handle the various ways paths are
currently presented, but it's clearly missing code to map the paths in
the log to packaged paths. Instead of requiring manual work and extra
build options to handle this mapping, and considering the caveats above,
it's just simpler to log archive paths as if they were relative to the
packaged application directory in a build, and use that during
packaging.
Depends on D21655
Differential Revision: https://phabricator.services.mozilla.com/D21656
--HG--
extra : moz-landing-system : lando
Instead of checking the MOZ_JAR_LOG_FILE for each log entry, only check
it once, and only check whether to log once per archive rather than once
per item.
Differential Revision: https://phabricator.services.mozilla.com/D21655
--HG--
extra : moz-landing-system : lando
This reverts commit 6e063ce2d1ff7aaa4a261b9c20fe6b2f05e842a4.
Bug 1531350 - fix flow + jest issues with column breakpoints. r=me
Differential Revision: https://phabricator.services.mozilla.com/D22249
--HG--
extra : moz-landing-system : lando
Minsoo Kim
Shruti
Marco Bonardo
Kartikaya Gupta
Mrigank Krishan
Gurzau Raul
Doug Thayer
Masatoshi Kimura
sotaro
Jan Beich
Razvan Caliman
Andrea Marchesini
Jonathan Kingston
championshuttler
Csoregi Natalia
Benjamin Bouvier
Henrik Skupin
Nick Thomas
Geoff Brown
monmanuela
shindli
Nico Grunbaum
Drew Willcoxon
Mike Hommey
Jason Laster
Sean Stangl
Matt Woodrow
Ehsan Akhgari