If the mathml.disabled preference is true, treat <math> and other MathML
elements as generic XML elements.
This patch disables the rendering code of MathML however preserves the
namespace so to reduce the breakage.
Original patch by: Kathy Brade <brade@pearlcrescent.com>
MozReview-Commit-ID: A2f2Q2b4eqR
--HG--
extra : rebase_source : 3c8530816727c01b68a831d560bfe16e7b02bd9d
Unfortunately couldn't add all the debug checks that I'd want, since we can't
assert that is not safe to run script in quite a few places :(
MozReview-Commit-ID: 8m3Wm1WntZs
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
This includes, for example :hover.
Also removes the call to IsStyledByServo() in the document constructor, it's not
only unnecessary, but also we call UpdateStyleBackendType() too early.
MozReview-Commit-ID: 4YfCdmLoSxu
Shift+backspace causes a forward delete on some platforms, but not on
Android. The new Google keyboard is sending us shift+backspace, and we
need to handle it normally like a backspace.
This is kind of a long story, stay with me on this.
In bug 990290, a WeakMap was added to any JS scope that loaded an XBL
binding. That WeakMap stored the JS prototypes that are injected into
a bound node's prototype chain.
When a binding is removed, we search the prototype chain for the
JS prototype that we'd added, and remove it.
The XUL prototype cache caches numerous things, including nsXBLDocumentInfo,
which we use to get at the nsXBLPrototypeBinding for a particular binding,
which is then used to generate the class object that's put into the WeakMap.
When the XUL prototype cache is flushed, that means that when a binding
is bound, its definition needs to be reloaded off of the disk. If, however,
there was a pre-existing instance of the binding already being used in a
document, now we were in a funny case.
We were in a funny case, because when attempting to remove a binding, we
would look up the nsXBLPrototypeBinding via the nsXBLDocumentInfo that's
being held within the nsXULPrototypeCache, find (or load off the disk) a
_new_ nsXBLDocumentInfo and generate a _new_ nsXBLPrototypeBinding that
did not match to the one that we'd already stored in the WeakMap. This
would mean that removal would go wrong, and things would break horribly.
This patch makes it so that we prioritize checking the nsBindingManager
for a document for the nsXBLDocumentInfo before checking the
global nsXULPrototypeCache. That way, even if the cache gets cleared,
if the binding was ever used in this document, it'll be in the
nsBindingManager, and we'll get the same nsXULProtoypeBinding that
we'd been using before, and sanity will prevail.
MozReview-Commit-ID: G8iLDbCPRAC
--HG--
extra : rebase_source : 4322965c0b7150b22454651ad7a9461ee76d766b
eKeyDownOnPlugin (mozkeydownonplugin) and eKeyUpOnPlugin (mozkeyuponplugin) should execute if the key combination is reserved by the linked <command> element.
Note that there is no eKeyPressOnPlugin. Therefore, eKeyDownOnPlugin may execute shortcut key handler which is registered as a keypress event handler.
MozReview-Commit-ID: CpjsFW02y26
--HG--
extra : rebase_source : 361be61bc6ff0213e3386427878d2f81321ca0df
If a plugin process posts native key events to the widget, it needs to check if the key combination is reserved by chrome because if it's reserved by chrome, the reserved shortcut key handler should be executed and the event shouldn't be handled by the focused plugin.
This patches add eKeyDownOnPlugin and eKeyUpOnPlugin. nsXBLWindowKeyHandler will listen to them and handle them as normal keydown and keypress or keyup event. Note that these events won't be fired on content in the default event group and won't be sent to the remote process.
MozReview-Commit-ID: H5OKPLtVdr6
--HG--
extra : rebase_source : c6852423e47c40e9953b72061262730f7cce35d7
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
In general, using an AutoJSAPI inited with an object is NOT the same as using
AutoSafeJSContext (or AutoJSAPI inited without an object) and then entering the
compartment of the object: the former will report exceptions to the global of
the object as it comes off the stack, while the latter will not. This only
really matters if we have an object from a window or worker global and hence
might fire error events, or report internal stuff to the web console.
The changes to initing with an object made in this bug are OK for the following
reasons:
1) dom/base/Console.cpp: Always clears its exception before coming off the stack.
2) dom/base/nsDOMClassInfo.cpp: Inits with a non-web global.
3) dom/base/nsFrameMessageManager.cpp: Inits with a non-web global.
4) dom/media/MediaPermissionGonk.cpp: We probably want the caller to notice if
anything here throws.
5) dom/xbl/nsXBLPrototypeBinding.cpp: Inits with a non-web global.
6) dom/xul/nsXULElement.cpp: Inits with a non-web global.
7) extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp: Inits with a non-web global.
8) ipc/testshell/XPCShellEnvironment.cpp: Inits with a non-web global.
Jonathan Kingston
Emilio Cobos Álvarez
Bobby Holley
Eric Rahm
Tom Tromey
Chris Peterson
Andrew McCreight
Lee Salzman
Boris Zbarsky
Jonathan Watt
Nicholas Nethercote
Olli Pettay
Jim Chen
Cameron McCormack
Mike Conley
Makoto Kato
Kyle Huey
Terrence Cole
Carsten "Tomcat" Book
Geoff Brown
Christoph Kerschbaumer
Masayuki Nakano