We can't add it to the base image because rebuilding the base image
breaks Valgrind due to non-deterministic package version installation
(read the bug for the ugly backstory).
MozReview-Commit-ID: ARKJZfNCRFc
--HG--
extra : rebase_source : 6a36b1289d121367c89c986f86faf1e34a38a906
extra : source : 66c7af8b26544e79b39b7180cb7338bbc2642064
Currently, NativeKey::DispatchPluginEventsAndDiscardsCharMessages() calls nsWindowBase::DispatchPluginEvent() and nsWindowBase::DispatchPluginEvent() does nothing when windowless plugin doesn't have focus. However, this is unclear when other developers read the code of DispatchPluginEventsAndDiscardsCharMessages() and it causes unnecessary virtual calls. So, it should try to dispatch plugin events only when a windowless plugin has focus.
For making the check safer, nsWindowBase should expose the method to check it as ShouldDispatchPluginEvent(). Unfortunately, we cannot mark this method as const due to PluginHasFocus() needs to be not const method, though. Then, for loops in DispatchPluginEventsAndDiscardsCharMessages() should check it at each try.
This change helps to log the behavior (working on bug 1297013) without noise.
Additionally, this patch renames the method to MaybeDispatchPluginEventsForRemovedCharMessages() because it doesn't remove any char messages anymore.
MozReview-Commit-ID: F14Lcx47M6U
--HG--
extra : rebase_source : 64b6da75590c99299f75358023844762198136d6
NativeKey removes odd WM_CHAR messages which are caused by ATOK or WXG if the user tries to do "Kakutei-Undo" (meaning "undo the last commit") after dispatching eKeyDown event.
However, NativeKey should remove them from the queue first because there are some problems:
* If focus is moved during dispatching an eKeyDown event, we'll fail to remove the messages from the queue.
* If dispatching eKeyDown advance native event loop due to entering to a modal loop or dosing synchronous XHR, the message pattern is broken before removing the odd messages from the queue.
After removing the odd char messages, NativeKey should store them with mRemovedOddCharMsgs because NativeKey needs to dispatch them to focused windowless plugin.
Note that this patch also fixes a bug of the loop to remove the odd WM_CHAR messages. Old code removes only one WM_CHAR messages, but we need to remove all WM_CHAR messages before WM_KEYUP. This must be a regression.
MozReview-Commit-ID: I60bcIx2SFS
--HG--
extra : rebase_source : 19d0e70d9f39e6d0476c62def5e0a2dc1e0ab444
NativeKey is now removing and storing following char messages when it's created for a keydown message. Therefore, IsFollowedByNonControlCharMessage() just refers the stored messages and it's enough fast. So, we can get rid of mIsFollowedByNonControlCharMessage.
MozReview-Commit-ID: 542A2sHNXeC
--HG--
extra : rebase_source : e748c9855c3cf2d45609f94f9ccc8d43d29dc447
GetFollowingCharMessage() is now called only when removing following char message. Therefore, it does not need to have the optional argument indicating if removing the found message.
MozReview-Commit-ID: 7P39wyfSC1
--HG--
extra : rebase_source : a38bb961df1bc03adc21295bc39e4e9c16e864f2
While dispatching an event, focused widget may be changed. In such case, NativeKey shouldn't continue to dispatch remaining events (eKeyPress events) for preventing to dispatch to input text in unexpected website.
MozReview-Commit-ID: 7geuqks0LQK
--HG--
extra : rebase_source : 3e6c82e1eb0e27115fe93b1a3b4a155914fd06f7
In some cases, we may receive following char message of WM_*KEYDOWN *during* dispatching an eKeyDown event. In such case, NativeKey shouldn't dispatch eKeyPress event twice (one is caused by receiving WM_*CHAR message, the other is caused by post dispatching eKeyDown event code).
This patch makes NativeKey consume following WM_*CHAR messages before dispatching eKeyDown. Therefore, the former case will never occur.
For doing that, NativeKey stores following WM_*CHAR messages in mFollowingCharMsgs and uses it when it needs to dispatch eKeyPress events for each WM_*CHAR message.
MozReview-Commit-ID: 6QNvlwVVlTz
--HG--
extra : rebase_source : c33b5a1ac503326d51ef78f4f8a09c9a63df7871
Some PowerVR SGX540 devices running Android 4.0 were crashing when
uploading texture data with glTexSubImage2D. This was unearthed by a
Skia upgrade which removed what should have been an unnecessary OpenGL
call. This reinstates the OpenGL call which prevents the crash, but at a
GLContext level rather than in Skia.
MozReview-Commit-ID: Dub8VSs2Dzd
--HG--
extra : rebase_source : 7584b2a71656c78055d1a3cd1410c2a1bd8e70b3
Mark some errors as OOM as that's what they are.
MozReview-Commit-ID: 2YEgBjqzMEm
--HG--
extra : rebase_source : 2ae43c8252f93adf9d4b0f86de96875152f739a1
Warnings were provided earlier on and got removed. So we instead make it consistent across all decoders.
MozReview-Commit-ID: 53obtEClq98
--HG--
extra : rebase_source : f2e22e0d8ff33e8198b39f5a955b8f233a97daa6
Only time this error can occur is if we failed to allocate memory.
MozReview-Commit-ID: A37SQnraC54
--HG--
extra : rebase_source : b05dcdaf1c91d2f94255cd870872ec80e23c81c7
* Only allows setting the log file at runtime if not set by an Env Var
* LogModulePrefWatcher will watch logging.config. prefs and call into Logging.cpp to set the log file, sync or timestamp
* Log files set by pref will have a -main.PID or -child.PID suffix
* If the logging.config.clear_on_startup pref is true, prefs will be reset upon restart.
MozReview-Commit-ID: CWJujX4jm2A
