It's an annotation that is used a lot, and should be used even more, so a
shorter name is better.
MozReview-Commit-ID: 1VS4Dney4WX
--HG--
extra : rebase_source : b26919c1b0fcb32e5339adeef5be5becae6032cf
Previously, Omnijar::GetReader(nsIFile*) returned nullptr when using
nested jars. This patch makes it return the outer jar reader in that
case, so we don't end up opening the outer jar file again.
We set a null target only from Web Animations API, so make sure
KeyframeEffectReadOnly::ConstructKeyframeEffect() can handle null target
properly.
MozReview-Commit-ID: D6PoV7PGFj3
--HG--
extra : rebase_source : 4ba2d616d6b2cdfe7985ced29e4454e818d076b8
We are currently generating typelib data for all interfaces. Apparently
typelib data is only needed for scriptable interfaces. So let's stop
generating typelib data for interfaces that aren't scriptable.
The impact of this is that some typelibs are dropped from
interfaces.xpt, resulting in ~10kb smaller interfaces.xpt:
* nsIDOMCSSValue
* nsIDOMDOMImplementation
* nsIDOMDOMCursor
* nsIProfilerStartParams
* nsIStreamingProtocolMetaData
* nsIDOMCharacterData
* nsIPrintSession
* nsIDOMDocumentFragment
* nsIDOMProcessingInstruction
* nsIDOMElement
* nsIDOMText
* nsIDOMXULElement
* nsIDOMAttr
* nsIDOMGeoPositionError
* nsIXMLHttpRequestEventTarget
* nsIDOMCSSStyleDeclaration
* nsIDOMCSSStyleSheet
* nsIDOMDocument
* nsIDOMClientRect
* nsIDOMMozNamedAttrMap
* nsIDOMNode
* nsIThreadObserver
* nsIDOMDocumentType
* nsIXMLHttpRequestUpload
* nsISelection
* nsIDOMCDATASection
* nsIDOMDOMRequest
* nsIDOMComment
* nsIDOMEvent
MozReview-Commit-ID: 3LYdNYs7Tum
--HG--
extra : rebase_source : 4ed0e6ef761b165108b8581077f2bf7eddd02274
When PluginInstanceChild receives native key events, it should post the events to the chrome process first for checking if the key combination is reserved. However, posting all key events to the chrome process may make damage to the performance of text input. Therefore, this patch starts to post a key event whose key combination may be a shortcut key. However, for avoiding to shuffle the event order, it posts following key events until all posted key events are handled by the chrome process.
For receiving response from widget, this patch defines nsIKeyEventInPluginCallback. It's specified by nsIWidget::OnWindowedPluginKeyEvent() for ensuring the caller will receive the reply. Basically, the caller of nsIWidget::OnWindowedPluginKeyEvent() should reply to the child process. However, if the widget is a PuppetWidget, it cannot return the result synchronously. Therefore, PuppetWidget::OnWindowedPluginKeyEvent() returns NS_SUCCESS_EVENT_HANDLED_ASYNCHRONOUSLY and stores the callback to mKeyEventInPluginCallbacks. Then, TabParent::HandledWindowedPluginKeyEvent() will call PuppetWidget::HandledWindowedPluginKeyEvent().
MozReview-Commit-ID: G6brOU26NwQ
--HG--
extra : rebase_source : 8140456de278956d2d594e85c7b397ae366b4962
Outer pointers for object aggregation never get used. Having these
always-null pointers around means extra space to store them and extra
instructions to deal with them. Let's just remove them.
js::Class op are often all null. And when they're not all null, they're often
duplicated among classes. By pulling them out into their own struct, and using a
(possibly null) pointer in js::Class, we can save 114 KiB per process on
64-bit, and half that on 32-bit.
* * *
imported patch separate-ClassOps-2
--HG--
extra : rebase_source : bd751bf247e9491c1966a123dbeffa573657dfb1
XPCOMThreadWrapper::GetCurrent() is failing because it's not keeping
AbstractThread::sCurrentThreadTLS up to date. This causes assertion failures
during startup of the GMP stack when dispatching via InvokeAsync to the GMP
thread, which is an XPCOM thread wrapped by the XPCOMThreadWrapper.
We can trivially initialize AbstractThread::sCurrentThreadTLS to be the
XPCOMThreadWrapper on the target thread, since it's thread-local-storage, and
the target thread won't change.
MozReview-Commit-ID: EIEFZppR2PS
This will help identify the cause of some Firefox start-up crashes when JS
initialization fails.
--HG--
extra : rebase_source : 3ed3c5e60f487e0ca11dc13bab93aa820ca8273f
This required reordering a bunch of stuff, so I took the opportunity to do a
big reordering. The new order:
- class CheckStaticAtomSizes;
- class DynamicAtom, class StaticAtom, their methods;
- gAtomTable and related functions;
- ~DynamicAtom() (here because it depends on gAtomTable stuff);
- gStaticAtomTable and related functions;
- exported functions.
--HG--
extra : rebase_source : 5fd4bf9a3f0c628dc3f74c0d8a81aadf48fd6dd7
This avoids the need for some virtual function calls and also will help lead to
distinct representations for dynamic and static atoms.
--HG--
extra : rebase_source : 16bbe6f1e1309ee3e4fab7a0d222e638178a2a9c
This patch changes things so that dynamic atoms and static atoms have distinct
implementations. This is a step towards allowing dynamic atoms and static atoms
to have different layouts in memory, which will allow static atoms to be
represented more compactly.
Specifically, the patch does the following.
- It renames AtomImpl as DynamicAtom and PermanentAtomImpl as StaticAtom, and
the latter is no longer a subclass of the former. This required duplicating
some methods from the former into the latter: ScriptableToString(),
ToUTF8String(), ScriptableEquals(), IsStaticAtom(). (This duplication will
disappear in the future if the representations of dynamic atoms and static
atoms diverge. Indeed, SizeOfIncludingThis() is already different in the two
classes.)
- It replaces all mentions of "permanent"/"non-permanent" atoms with
"static"/"dynamic".
- In ~DynamicAtom() it removes the check that causes gAtomTable to be deleted
when it becomes empty. This will only happen at shutdown and so doesn't seem
useful.
- It documents better various things, especially the basics of the
dynamic/static split, the transmutation of dynamic atoms to static atoms, and
the details of the SizeOf functions.
--HG--
extra : rebase_source : dbf903012e70ebf1a43de1e1088db1bc1b8dd4f4
Also fixes bug 926980 - load ICU data from an archive file.
Stop invoking ICU's autoconf build system. Instead, have hand-authored
moz.build files under config/external/icu to build what we need. In addition,
we'll commit a pre-built copy of the ICU data file (currently icudt56l.dat)
under config/external/icu/data to avoid having to build ICU host tools to
generate it. config/external/icu/data also contains some assembly files
which can generate an object file containing the ICU data file contents
so that the JS shell (or standalone JS builds) can be linked directly to
the data without having to deal with the external data file. This requires
yasm or GNU as.
Various bits of packaging have been updated to account for the ICU data file.
XPCOM initialization now sets the ICU data directory so ICU can locate its
data file.
The update-icu.sh script has been modified to read the list of C/C++ source
files out of the ICU Makefiles and update `sources.mozbuild` files under
config/external/icu, as well as build a local copy of ICU using its
autoconf build system to generate the ICU data file to be committed in-tree.
MozReview-Commit-ID: 8Pfkzqt6S1W
--HG--
extra : rebase_source : 31426cddddb5543e0191059ba2f2eb069abe7727
This patch makes NativeProperties variable-length and reduces static data by
110,336 bytes on 64-bit, and half that on 32-bit.
MozReview-Commit-ID: 2etZ5AnEhgO
--HG--
extra : rebase_source : 6a167b64df7da3c6940114782fe08337f04a694d
The former is only used inconsequentially in tests. The second is not used at
all.
--HG--
extra : rebase_source : 4cfe11f933f1fe8f788e823c5107941085cef92c
The behavior of ::BrowserTabsRemoteAutostart() shouldn't change, meaning that every result remains the same. The new getter can be accessed by JS through Services.appinfo.multiprocessBlockPolicy
MozReview-Commit-ID: 62PpbeJcMCI
There are about 600 of these, at 16 bytes each, and this change makes all of
them shareable between processes
--HG--
extra : rebase_source : b1824f0a022389aeb02d925c4d788e5a671bf782
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. So hopefully
this patch never lands because someone insists of fixing the underlying
problem instead. But if it does land, hopefully the workaround is
only temporary.
MozReview-Commit-ID: 9AkkAUDMln6
--HG--
extra : rebase_source : 76126361de678729344b0e9eaeac1d523f88ebb4
We only ever execute this in one place, so we can just have the main
action do the --regen --cachedir=. mode of operation.
MozReview-Commit-ID: Fis4YBPFjMl
--HG--
extra : rebase_source : f19ac1ad688115c0aee4bf307b72d6207512f702
We can just generate xpidllex.py/xpidlyacc.py in the current directory
rather than one directory higher, and specify this directory as an
include path to xpidl-process.py
MozReview-Commit-ID: KLoGjudc4Y8
--HG--
extra : rebase_source : 8dda268c6490cdfb8b896de9da5b789208584193
