This was necessary back when it still contained a lot of xpcom code, but
shouldn't be necessary now that it only contains two objects.
Differential Revision: https://phabricator.services.mozilla.com/D15168
--HG--
extra : moz-landing-system : lando
The VisualViewport events are all nice and shiny, but unfortunately not quite
what is needed for the session store.
Firstly, the spec wants the "scroll" event to be fired only when the *relative*
offset between visual and layout viewport changes. The session store however
records the absolute offset and as such is interested in when *that* changes.
Secondly, again as per the spec the events don't bubble, and with the default
DOMEventTargetHelper implementation they don't escape the VisualViewport during
capturing, either. This means that any event listener must be added directly on
the VisualViewport itself in order to capture any events.
This might have been intended because the events use the same names as the
normal "scroll"/"resize" events, and as such you cannot specify separate event
listeners for VisualViewport and non-VisualViewport "scroll" events if both
events end up being dispatched to the same element (you can only try to filter
after the fact by looking at the originalTarget of the event).
At the same time, the VisualViewport is attached to the inner Window, and so
each time you navigate, you also get a different VisualViewport object.
All of this might be totally fine from the perspective of a page script, because
in that case you won't care anyway about what happens when the current page goes
away.
From the session store perspective on the other hand (especially Fennec's non-
e10s session store design), this is rather unfortunate because we don't want to
have to keep registering event listeners
a) manually for each subframe
b) each time the page navigates
The event target chain problem could be solved by letting the scroll events
escape the VisualViewport during the capturing phase (which the spec doesn't say
anything about), but this would mean that any scroll listener attached to a
window/browser/... that uses capturing will now catch both layout and visual
viewport scroll events.
In some cases this might even be beneficial, but in others (e.g. bug 1498812
comment 21) I'd like to specifically decide which kind of scroll event to
capture. Having to look at event.originalTarget to distinguish the two kinds
might be defensible in test code, but in case this distinction would be needed
in production code as well, given the existence of a C++-based filtering helper
in nsSessionStoreUtils for another use case where (scroll) events need to be
filtered, JS-based scroll event filtering might be a bad idea.
Additionally, in any case this wouldn't solve the fundamental conflict between
the spec and the session store about *when* the "scroll" event should be fired
in the first place.
Hence I'd like to introduce a separate set of events with distinct event names,
which will be dispatched according to the requirements of our internal users
(i.e. currently the session store). To avoid potential web compatibility issues
down the road, for now these events will be dispatched only to event listeners
registered in the system group (allowing *all* Chrome event listeners cannot be
done because checking the Chrome status of each event target might be too
expensive for frequently dispatched events).
Differential Revision: https://phabricator.services.mozilla.com/D14046
--HG--
extra : moz-landing-system : lando
Move js/src/jsapi.h declarations related to promises and job queues into their
own public header file, js/public/Promise.h. Change the compilation units that
need these declarations to #include the new header.
There should be no changes to the actual functionality here, simply moving the
code to a new file, and removing the "JS" prefix from some typedefs which are
now in the JS namespace.
Differential Revision: https://phabricator.services.mozilla.com/D13345
--HG--
extra : moz-landing-system : lando
Fails with clang trunk:
"type of UTF-8 string literal will change from array of const char to array of const char8_t in C++2a"
otherwise
Differential Revision: https://phabricator.services.mozilla.com/D14696
--HG--
extra : moz-landing-system : lando
This backs out the main patch landed earlier in bug 1194856 and the
patch from bug 1225004.
Differential Revision: https://phabricator.services.mozilla.com/D14050
--HG--
extra : moz-landing-system : lando
vpx_mem_set_functions support is only enabled when
MOZ_VPX_NO_MEM_REPORTING is not set. It is currently set unconditionally
when building with the in-tree libvpx. When building with system libvpx,
it is set when the vpx_mem_set_functions can't be found in the system
libvpx library.
Upstream removed the vpx_mem_set_functions function in version 1.5, and
we require at least that version, meaning, in practice,
MOZ_VPX_NO_MEM_REPORTING is now always set.
We might as well remove the define and the code that's conditional to
not being defined.
Differential Revision: https://phabricator.services.mozilla.com/D14517
--HG--
extra : moz-landing-system : lando
We introduce GenericNonExclusivePromise that can be used to explicitly state than non-exclusive use is needed
We temporarily disable the assertion ensuring a promise is used exclusively when needed to allow for things to settle.
Differential Revision: https://phabricator.services.mozilla.com/D14025
--HG--
extra : moz-landing-system : lando
This has benefits both in terms of performance and memory usage. Aside from
the obvious savings of not loading additional JS scripts in every process,
this also allows us to move more of our expensive data collection work to a
background thread, where it doesn't risk janking both parent and content
processes.
MozReview-Commit-ID: 2A593R7bIKB
Differential Revision: https://phabricator.services.mozilla.com/D13872
--HG--
extra : rebase_source : ec634ee3a3b975809f542aa8077ad32236781452
Change nsMacUtilsImpl::GetAppPath() to not depend on the app bundle ending in ".app".
Differential Revision: https://phabricator.services.mozilla.com/D13682
--HG--
extra : moz-landing-system : lando
Replace with just unwrapping the key, since there are no users that return anything else for a delegate.
--HG--
extra : rebase_source : e72b825121ca3493364c9347f65e5dddd1ef53e0
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
nsCRTGlue.cpp has a few data tables that get broken up badly by
clang-format, so just disable the formatting. There are some more
tables in this file, but the arrangement doesn't seem to matter for
them.
The bloat log header is just a little bit of ASCII art, so just ignore
it in formatting so it is easier to read.
MOZ_COLLECT_REPORT uses very wide string constants that get rewrapped
in an ugly way by clang-format, so just disable the formatting for
them.
Depends on D13185
Differential Revision: https://phabricator.services.mozilla.com/D13186
--HG--
extra : moz-landing-system : lando
clang-format doesn't seem to reflow text when a single string constant
is represented as multiple lines of string literals to fit within 80
columns. Instead, if a single string literal is too long, it breaks
off a piece and moves it to the next line, which leads to a bunch of
choppy short string bits. The resulting string literals are still a
bit choppy, mostly because I didn't want to break up the long names of
prefs.
Here's an example of what I mean:
|--- max width --- |
"some long string literal"
"is here but it goes on for multiple lines"
This gets turned into:
|--- max width --- |
"some long string "
"literal"
"is here but it "
"goes on for multiple lines"
My patch manually would turn this into:
|--- max width --- |
"some long string "
"literal is here "
"but it goes on "
"for multiple lines"
The strings in my patch don't always end up at column 80, because the
width is set to work with wherever clang format ends up actually
indenting them.
There are more instances of this problem when MOZ_COLLECT_REPORT is
used, but that can be dealt with in another bug. There are a ton of
them.
Depends on D13184
Differential Revision: https://phabricator.services.mozilla.com/D13185
--HG--
extra : moz-landing-system : lando
Clang format does not always reflow comments correctly to get them
within 80 columns.
The major categories of failures I have noticed in xpcom/ are:
- Comments that are lists. I fixed these by manually getting them so
they'll be within 80 columns after clang-format runs.
- Comments intermixed with lists of things like enums, initializers,
or even fields in a class. It doesn't seem to associate the comment
with the item in the list correctly. The worst cases of these happen
when it changes initializer lists from having commas at the start of
each item to having them at the end. In the initializer comma cases,
I fixed them by making the commas at the end, so clang-format won't
mix things up. For other cases, I often moved the comment for an
item onto its own line, because it was not possible to have both the
comment and the item on the same line and stay within 80 columns.
- One odd case is nsEnumeratorUtils.cpp, where the end of line comment
after a NS_DECL macro confused clang-format and made it stop
realizing that the NS_DECL thing was a complete statement. I also
added a blank line to that file before a declaration because I think
that is better.
Depends on D13183
Differential Revision: https://phabricator.services.mozilla.com/D13184
--HG--
extra : moz-landing-system : lando
Clang format makes this code look pretty bad, but I think it is safe
to just remove it.
Depends on D13182
Differential Revision: https://phabricator.services.mozilla.com/D13183
--HG--
extra : moz-landing-system : lando
Mike Hommey
Michael Froman
Jan Henning
Razvan Maries
Sylvestre Ledru
Ehsan Akhgari
Kris Maglione
arthur.iakab
Jim Blandy
Jonathan Kingston
Cameron McCormack
Andrea Marchesini
Cosmin Sabou
Bogdan Tara
Jean-Yves Avenard
Masatoshi Kimura
Coroiu Cristina
Brindusan Cristian
Emilio Cobos Álvarez
ffxbld
Haik Aftandilian
Jorg K
Brian Hackett
Steve Fink
Nathan Froyd
Tooru Fujisawa
Benjamin Bouvier
Andreea Pavel
Andrew McCreight