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
Telemetry and some performance profiles show that Msg_NotifyIMEFocus can take
a few seconds to complete, and jank the browser. With bug 1217700, it removes
the necessity of sync Msg_NotifyIMEFocus, so in this patch we make this async
for performance improvement.
MozReview-Commit-ID: 15eUwMJ2Q7H
--HG--
extra : rebase_source : b463e6e881ca5ebec00d0f76e29ca103059b3ddd
From 10.10.3, macOS supprts looking up dictionary by force touch. So we should support it because this is supported by Chrome and Safari.
MozReview-Commit-ID: AcAhieMXOwe
--HG--
extra : rebase_source : 79c55830dfa023165731269780d813956e4e26f2
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
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is only used in ways that nsCStrings can also be used
(i.e. no null checks or implicit conversions to |char*|).
In every case the patch trivially replaces the nsXPIDLCString with an
nsCString. (Also, there are a couple of unused nsXPIDLCString variables that
the patch simply removes.)
This patch refactors the nsThread event queue to clean it up and to make it easier to restructure. The fundamental concepts are as follows:
Each nsThread will have a pointer to a refcounted SynchronizedEventQueue. A SynchronizedEQ takes care of doing the locking and condition variable work when posting and popping events. For the actual storage of events, it delegates to an AbstractEventQueue data structure. It keeps a UniquePtr to the AbstractEventQueue that it uses for storage.
Both SynchronizedEQ and AbstractEventQueue are abstract classes. There is only one concrete implementation of SynchronizedEQ in this patch, which is called ThreadEventQueue. ThreadEventQueue uses locks and condition variables to post and pop events the same way nsThread does. It also encapsulates the functionality that DOM workers need to implement their special event loops (PushEventQueue and PopEventQueue). In later Quantum DOM work, I plan to have another SynchronizedEQ implementation for the main thread, called SchedulerEventQueue. It will have special code for the cooperatively scheduling threads in Quantum DOM.
There are two concrete implementations of AbstractEventQueue in this patch: EventQueue and PrioritizedEventQueue. EventQueue replaces the old nsEventQueue. The other AbstractEventQueue implementation is PrioritizedEventQueue, which uses multiple queues for different event priorities.
The final major piece here is ThreadEventTarget, which splits some of the code for posting events out of nsThread. Eventually, my plan is for multiple cooperatively scheduled nsThreads to be able to share a ThreadEventTarget. In this patch, though, each nsThread has its own ThreadEventTarget. The class's purpose is just to collect some related code together.
One final note: I tried to avoid virtual dispatch overhead as much as possible. Calls to SynchronizedEQ methods do use virtual dispatch, since I plan to use different implementations for different threads with Quantum DOM. But all the calls to EventQueue methods should be non-virtual. Although the methods are declared virtual, all the classes used are final and the concrete classes involved should all be known through templatization.
MozReview-Commit-ID: 9Evtr9oIJvx
This line is subtle enough to not be noticeable with light titlebar fills,
and looks out of place with dark titlebar fills.
MozReview-Commit-ID: D0b4O2wry1F
--HG--
extra : rebase_source : 739adb837f8e756fc9619864877fc6faff31d1cf
CompareCacheHashEntry::mCrit[] is the only case where the nsXPIDLString-ness
was important. The patch adds an explicit SetIsVoid() call to that class's
constructor and changes some null checks to IsVoid() checks.
--HG--
extra : rebase_source : e68befcde4dd098bac2a550bc666eaf3bf1298d7
When Gecko started to support Cocoa widget, we needed to use NSInputManager.
That allowed applications to access only focused IME context. Therefore, commit
composition request handler for Cocoa is designed as handling asynchronosly if
it's requested when the window is not active or is being inactivated.
Additionally, the asynchronous handling isn't perfect. We hit some MOZ_ASSERT()
now in some places. E.g., in SelectedRange(), it doesn't assume that it's
called during deactive.
On the other hand, NSInputManager was alreay obsolete and we already stopped using it
(bug 810225). Instead, we're using NSTextInputContext and it allows applications
to access IME anytime. Therefore, if we make IMEInputHandler handles commit/cancel
composition requests synchronsly, that behaves same as the other platforms. So, we
can get rid of macOS specific issue completely.
MozReview-Commit-ID: X7aWmGq95x
--HG--
extra : rebase_source : a472a03e3ef6f424fe73c2d438b8326bed80278d
It wasn't enough to just check for `mWindow` in `OnResumedCompositor()`,
because the `LayerViewSupport` instance itself could have been released.
This patch now checks for both cases.
MozReview-Commit-ID: hSnFUhtp8m
Wes Kocher
Martin Stransky
aceman
Tom Ritter
Sebastian Hengst
Makoto Kato
Nicholas Nethercote
Eric Rahm
Jessica Jong
Stone Shih
Farmer Tseng
Markus Stange
Henry Chang
James Willcox
peter chang
Carsten "Tomcat" Book
Bill McCloskey
Michael Layzell
Yoshi Huang
Mason Chang
Milan Sreckovic
Chung-Sheng Fu
Masayuki Nakano
Jim Chen
Ryan Hunt
Ryan VanderMeulen
Masatoshi Kimura