***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
Let SessionStoreUtils be a WebIDL namespace, rather than a XPCOM service
Differential Revision: https://phabricator.services.mozilla.com/D9776
--HG--
rename : toolkit/components/sessionstore/nsSessionStoreUtils.cpp => toolkit/components/sessionstore/SessionStoreUtils.cpp
extra : moz-landing-system : lando
For simplicity's sake, for now we keep storing only one scroll position per
history entry (bug 1499210), so if we have to choose between the layout and the
visual viewport, the latter is a vastly better choice, as it more accurately
represents the scroll position as perceived by the user, especially when the
page has been pinch-zoomed.
This also means that instead of the normal scroll events, the session store now
has to listen for the corresponding events specific to the visual viewport.
We also extend the scroll position test to check that the scroll position isn't
just properly saved, but also actually properly restored in practice as well.
We only add this test now instead of already adding it beforehand like we did
with the rest of the test
- to avoid having to temporarily extend the checkScroll() helper function to
deal with todo()/todo_is etc.
- because getting that part of the test to complete without timing out (which
would be one of its natural failure modes, because the expected events would
be missing) would require faking even more scroll events
- because we already have the todo() tests that are telling us the we didn't
*store* any scroll position in the first place, so there's no point in trying
to actually restore anything
For the GeckoView saveAndRestoreState test, we now spin the event loop once
before setting the scroll position in order to give APZ opportunity to settle
down after the initial page load.
Differential Revision: https://phabricator.services.mozilla.com/D15690
--HG--
extra : moz-landing-system : lando
Nobody within mobile or toolkit is currently using it.
Differential Revision: https://phabricator.services.mozilla.com/D15328
--HG--
extra : source : 531c402060ecc2bc3d1119ecaf3b49b29e03e3cc
extra : histedit_source : 0e86b12909c5f76605304a0a0ff4088031a7b8b9
Let SessionStoreUtils be a WebIDL namespace, rather than a XPCOM service
Differential Revision: https://phabricator.services.mozilla.com/D9776
--HG--
rename : toolkit/components/sessionstore/nsISessionStoreUtils.idl => dom/chrome-webidl/SessionStoreUtils.webidl
rename : toolkit/components/sessionstore/nsSessionStoreUtils.cpp => toolkit/components/sessionstore/SessionStoreUtils.cpp
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
1. Add successorTabId to the Tab type, so that it will be returned in, e.g.,
browser.tabs.get calls
2. Extend or create the following methods on the browser.tabs API:
- update: add successorTabId as an optional property on the provided
updateProperties object
- moveInSuccession: new method that manipulates tab successors in bulk
Differential Revision: https://phabricator.services.mozilla.com/D9272
--HG--
extra : moz-landing-system : lando
Add an optional previousTabId property to the onActivated event,
which is present if the previously activated tab is still open.
Differential Revision: https://phabricator.services.mozilla.com/D9271
--HG--
extra : moz-landing-system : lando
Currently, some "input" event dispatchers in our script dispatch "input" event
with UIEvent. This is completely wrong. For conforming to HTML spec, Event
is proper event. Additionally, for conforming to Input Events, InputEvent
is proper event only on <textarea> or <input> element which has a single line
editor.
For making us to maintain easier, this patch adds new API, "isInputEventTarget"
to MozEditableElement which returns true when "input" event dispatcher should
use InputEvent for the input element.
Finally, this makes some dispatchers use setUserInput() instead of
setting value and dispatching event by themselves. This also makes
us to maintain them easier.
Note that this does not touch "input" event dispatchers which dispatch events
only for chrome (such as URL bar, some pages in about: scheme) for making
this change safer as far as possible.
Differential Revision: https://phabricator.services.mozilla.com/D12247
--HG--
extra : moz-landing-system : lando
Jan Henning
Brindusan Cristian
Andreea Pavel
James Willcox
Oana Pop Rus
Delphine Lebédel
prathiksha
Myk Melez
Cosmin Sabou
Alphan Chen
Francesco Lodolo (:flod)
Ciure Andrei
Kris Maglione
Dylan Roeh
Ehsan Akhgari
Sylvestre Ledru
Emilio Cobos Álvarez
Hiroyuki Ikezoe
Michael Kaply
Mark Banner
Bogdan Tara
Shane Caraveo
Tooru Fujisawa
Ryan Hendrickson
Gabriele Svelto
Masayuki Nakano
Lina Cambridge
Narcis Beleuzu