Bug 1354020 causes that IMM-IME on Windows 7 doesn't work with --no-remote. Although I think that this issue is OS or IME bug, when default window proceduce by RegisterClass is DefaultWindowProcW, Google Japanese IME doesn't work.
I am not sure why this issue occurs when lpfnWndProc is DefWidnowProcW and DDE isn't started. But for workaround, we should revert a part of bug 1354020 changes.
MozReview-Commit-ID: BkxlZnm8mIh
--HG--
extra : rebase_source : 21c1d86fb5628dbd726a15e5057a536271cfb26d
This is straightforward, with only two notable things.
- `#include "nsXPIDLString.h" is replaced with `#include "nsString.h"`
throughout, because all nsXPIDLString.h did was include nsString.h. The
exception is for files which already include nsString.h, in which case the
patch just removes the nsXPIDLString.h inclusion.
- The patch removes the |xpidl_string| gtest, but improves the |voided| test to
cover some of its ground, e.g. testing Adopt(nullptr).
--HG--
extra : rebase_source : 452cc4a08046a1adb1a8099a7e85a1917de5add8
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
Since our platform requirement is Windows 7+, we don't need GetProcAddress for gesture APIs. But nsWinGesture still uses GetProcAddress for Win7+ API.
MozReview-Commit-ID: 1COJqM4NJTD
--HG--
extra : rebase_source : d915c1f74f6f3f10287ae6d08892499c3d3e8da6
Built pdfium_ref_x86.dll and pdfium_ref_x64.dll from google source tree. Use
them to generate an EMF as the reference.
MozReview-Commit-ID: GoaxU6nWXYM
--HG--
extra : rebase_source : 441d72cd409e105337eed7d763a29ef329ba2d58
When removing our Windows message loop pumping code in the content
process, a11y code on the MTA thread must have some way to wake up the
main thread. The main thread could be blocked either on a conditional
variable waiting for a Gecko event, or it could be blocked waiting on
a Windows HANDLE in IPC code (doing a sync message send). In the
former case, we wake it up by posting an event to the main thread. In
the latter case, we continue to use the asynchronous procedure call
mechanism.
MozReview-Commit-ID: FN6KWaGo9Zl
This patch also adds logging into ResolveJunctionPointsAndSymLinks to help diagnose issues that
might arise if the resolution fails or the path is not usable for some reason.
nsXPIDLStrings are marked as VOIDED upon initialization. Most of these local
nsXPIDLString variables are immediately set via getter_Copies(), which will
either assign a string value (using Adopt()) or do SetIsVoid(). These can be
trivially converted to nsString, which will get the same treatment.
The patch suitably converts the remaining nsXPIDLString local variable as well.
--HG--
extra : rebase_source : 5fff9f2c6844559198f601853f8db08564add7d5
This removes about 2/3 of the occurrences of nsXPIDLString in the tree. The
places where nsXPIDLStrings are null-checked are replaced with |rv| checks.
The patch also removes a couple of unused declarations from
nsIStringBundle.idl.
Note that nsStringBundle::GetStringFromNameHelper() was merged into
GetStringFromName(), because they both would have had the same signature.
--HG--
extra : rebase_source : ac40bc31c2a4997f2db0bd5069cc008757a2df6d
billm reports that the runnable in this code is firing a lot, and since we
don't support XP/Vista we're not benefiting from this overhead.
MozReview-Commit-ID: Bpw1E9DxPpD
--HG--
extra : rebase_source : 580ef086e8d9ce12c42724c6671d9de87038beb4
To make the HeadlessCompositorWidget work under Windows as well as Linux, I had
to change the way that I hooked it into the existing CompositorWidget system.
Under GTK, the CompositorWidgetInitData and CompositorWidgetDelegate types
provided the information needed by the headless compositor widget already (the
widget client size). On Windows, however, the definitions of these types
differ, and the client size information is simply retrieved from the platform
APIs when needed.
After this patch, CompositorWidgetDelegate is renamed to
PlatformCompositorWidgetDelegate, and a new base class called
CompositorWidgetDelegate is added with "AsPlatformSpecificDelegate()" and
"AsHeadlessCompositorWidget()" methods. In non-headless mode, widgets use
AsPlatformSpecificDelegate() to access the Windows- and GTK-specific delegate
APIs. In headless mode, AsHeadlessCompositorWidget() is used to access the
singular CompositorWidget implementation for headless. Meanwhile, the
CompositorWidgetInitData IPDL type is made into a union which always contains a
headless-specific HeadlessCompositorWidgetInitData struct and under GTK and
Windows also contains an {X11,Win}CompositorWidgetInitData struct.
This also includes a small patch to ensure that the GPU process and
hardware-accelerated compositing are always disabled under headless mode. These
features weren't activated by default in the Linux environments I tested in, but
did end up activating (and then promptly crashing Firefox) when I tested on
Windows.
MozReview-Commit-ID: CocPoHBDV7H
--HG--
extra : rebase_source : 4581fa63aa3a9f32a8dc2672015a35b9be01b20f
Currently, TSFTextStore::GetIMENotificationRequests() tries to return notification requests for focused text store. However, if there is sEnabledTextStore, all notifications will be sent for it. Therefore, TSFTextStore::GetIMENotificationRequests() should return notifications for sEnabledTextStore without checking focused text store in the thread manager.
For example, we try to keep active composition even if we're being inactivated because Windows steals focus from us when our main process becomes busy but user may want to continue to compose the composition after our process becomes available.
Additionally, if TSFTextStore::GetIMENotificationRequests() doesn't return IMENotificationRequests::NOTIFY_DURING_DEACTIVE, sEnabledTextStore will be broken by NOTIFY_IME_OF_BLUR which will be sent by IMEStateManager::OnChangeFocusInternal(). However, when we're being activated, NOTIFY_IME_OF_FOCUS won't be notified because focused remote process keeps having IMEContentObserver. Therefore, sEnabledTextStore won't be recreated and IME becomes unavailable.
Therefore, while sEnabledTextStore is not nullptr, TSFTextStore::GetIMENotificationRequests() needs all notifications even if it loses focus in the thread manager.
MozReview-Commit-ID: CC6gJIpHxUO
--HG--
extra : rebase_source : 02559fe8fea81b4247ef27043fc1d995981a9ba4
"intl.tsf.hack.ms_japanese_ime.do_not_associate_imc_on_win10" should be unnecessary anymore because it failed to avoid the crash of MS-IME for Japanese but causing other regression. Therefore, this patch removes it completely.
MozReview-Commit-ID: 91jjxfIYReW
--HG--
extra : rebase_source : d261f5bf77c14c41562495574d87364a7bb2d4fc
This parameter isn't used by any implementation of onDispatchedEvent,
and keeping the parameter makes later refactorings in this bug more difficult.
MozReview-Commit-ID: 90VY2vYtwCW
WebKit's Speedometer benchmark updates textbox to emulate text input. So it also updates caret position with focus. And, nsCaret always gets current blink time when reseting caret via LookAndFeel.
When profiling speedometer benchmark, GetCaretBlinkTime somestimes show profiling stack. This API gets data from kernel mode, so this isn't faster.
So, we should cache caret blink rate.
And when changing this rate via control panel, WM_SETTINGCHANGE is posted. So we should update this cache via this message.
MozReview-Commit-ID: IEIi25RvR1g
--HG--
extra : rebase_source : 4bc506acd67f2737cf44dc2a667c938efc7b4024
The fix for bug 1373079 neglected the detail of OpenThemeData
that it can return null if no match is found for the specified
class name. The set of matching class data sections varies with
the default and the classic theme, and the classic theme doesn't
have matches for a few of the values that we try to get. This
causes us to pass a null theme to subsequent functions, which of
course breaks the layout.
MozReview-Commit-ID: 5LaR0qZlOzd
--HG--
extra : rebase_source : ba97163e5dfdd7127d550be54524e93f12195ffb
SetParent removes the widget from the old parent widget and then sets its new one. We were incorrectly using the new parent widget when we needed the old one.