This API is deprecated (callers are supposed to be using
nsISound::playEventSound instead) and there are no callers remaining in
mozilla-central, or references to the strings for the API. Let's remove
dead code.
OnUpdateComposition() may be called without new range instance by some TIPs
when they starts to modify composition string. At this timing, TSFTextStore
should append a pending action for dispatching keyboard event into the queue.
Without this patch, OnUpdateComposition() creates incomplete pending action
for composition update and then, MaybeDispatchKeyboardEventAsProcessedByIME()
appends pending action for dispatching keyboard event from another point
immediately (e.g., from SetText()), then, finally, the caller of
MaybeDispatchKeyboardEventAsProcessedByIME() appends another pending action
for composition update with proper composition string. Therefore, the
first pending action for composition update clears composition string before
actually updating it with new composition string. In other words, new
pending action for dispatching keyboard event splits a pending composition
update. So, this patch prevents the splitting.
MozReview-Commit-ID: 9pYO9pm3Vh9
--HG--
extra : rebase_source : a8fb903174c0f1af61a71175dbbf01b7b1c5cb53
TSF doesn't send WM_KEYDOWN nor WM_KEYUP to us while it handles a key message
with ITfKeystrokeMgr::KeyDown() or ITfKeystrokeMgr::KeyUp(). Therefore,
TSFTextStore needs to store handling key event message during calling
those methods and if it does something, we need to dispatch eKeyDown event
or eKeyUp event before dispatching any events.
However, we shouldn't dispatch WidgetKeyboardEvent during a document lock
because TSF/TIP do not assume that document is broken during a document lock.
Therefore, TSFTextStore needs to put it as a pending action into the queue.
So, this patch wraps this with
TSFTextStore::MaybeDispatchKeyboardEventAsProcessedByIME(). It checks if
there is a document lock when it's called. If it's locked (and not yet
dispatched keyboard event for the handling key message), it adds pending
action to dispatch keyboard event later. Otherwise, (and not yet dispatched
one), it dispatches keyboard event directly.
MozReview-Commit-ID: 9rJTJykVLyf
--HG--
extra : rebase_source : 4f8297b2b9fe2905e4cd1f64086fcdbe3d0b6035
On Windows, VK_PROCESSKEY key message is sent if the key event is handled by
IME (in IMM mode or IMM-IME). Therefore, we can set
WidgetKeyboardEvent::mKeyCode to NS_VK_PROCESSKEY and
WidgetKeyboardEvent::mKeyNameIndex to KEY_NAME_INDEX_Process simply when
we receive VK_PROCESSKEY.
MozReview-Commit-ID: 9B8Q7rwfXYD
--HG--
extra : rebase_source : f1ed228b295e6c4bd41192bc773b8118a28db6bc
On Windows, VK_PROCESSKEY key message is sent if the key event is handled by
IME (in IMM mode or IMM-IME). Therefore, we can set
WidgetKeyboardEvent::mKeyCode to NS_VK_PROCESSKEY and
WidgetKeyboardEvent::mKeyNameIndex to KEY_NAME_INDEX_Process simply when
we receive VK_PROCESSKEY.
MozReview-Commit-ID: 9B8Q7rwfXYD
--HG--
extra : rebase_source : a15105e3b6acf1f1911a8299911353dc4179e2c0
Mostly just convert nsInt{Rect,Region} to LayoutDeviceInt{Rect,Region}.
One exception is to change the parameter of nsWindow::OnResize from
nsIntRect to LayoutDeviceIntSize, because it really only needs that.
MozReview-Commit-ID: 963Mzd5Wed6
--HG--
extra : rebase_source : efae039d26feb98a3591a7cd46c30ce4f052d70b
We still get occasional messages for the internal OLE Main Thread window.
Also, the PeekMessage call allows internal windows messages to be processed for
things like GDI.
This gtest assumed the current working directory ($OBJDIR/_tests/gtest/) was in the DLL LoadLibrary path. That is no longer true with this bug's patches, so the gtest must specify the absolute path to the PDFium DLL to load it.
MozReview-Commit-ID: 5TXj6A9Tb9w
--HG--
extra : rebase_source : b097ae0c3430767e9ff16632ee96fd8739a902bf
extra : histedit_source : 1f13fa04c29039f8aeae05028d0a20ede5ee794b
Windows default behavior will trigger the System menu bar when F10 is released.
Among other things, this causes the System menu bar to appear when a web page overrides the contextmenu event.
We *never* want this default behavior, so eat this key (never pass it to Windows).
MozReview-Commit-ID: 4fWOuj4mWvW
--HG--
extra : rebase_source : 45d38ba19b2f23aca74a60819c7d93af2ffa167d
Although we haven't any bug reports caused by this, this is a really old bug.
When we implement TSFTextStore, we decided to use queue of dispatching
events and flush it when document lock is unlocked. When we implement the
queue, we got this regression.
When TSFTextStore::SetText() is called with different range from current
selection range, TSFTextStore::SetSelectionInternal() add
PendingAction::SET_SELECTION into the queue first for replacing existing
text or inserting text into different position if there is no composition.
Then, TSFTextStore::InsertTextAtSelectionInternal() inserts text at the new
selection range.
When TSFTextStore::FlushPendingActions() is called after that, eSetSelection
should be dispatched and then, new text is inserted wit a set of composition
events. However, we forgot to dispatch creating eSetSelection event.
So, this patch just dispatches the event.
MozReview-Commit-ID: Hw8FTB1R5kR
--HG--
extra : rebase_source : 8a119f1f48b167d9423fc89ce0efc722313c3732
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
AccessibleNode::GetParentObject is a non-overriding final virtual function. GetParentObject is a common virtual function in many DOM classes, but AccessibleNode does not derive from any base classes that define virtual GetParentObject or have any derived classes of its own.
WebCryptoTask::CalculateResult and CallCallback are non-overriding final virtual functions that mirror virtual function names in the CryptoTask class, even though WebCryptoTask does not actually derive from CryptoTask.
nsWindowBase::GetWindowHandle is a non-overriding final virtual function. The only other function called GetWindowHandle is MouseScrollHandler::EventInfo::GetWindowHandle, which is not related to the nsWindowBase class.
MozReview-Commit-ID: 4ldSAyP3ZpP
--HG--
extra : rebase_source : cd6fea309c042183db59653ed39e1e63b70c6a63
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
The renaming problem is, when I try to convert 2nd or later clause of
composition string with Japanist 10, it shows candidate window below the
start of composition string first, then, it moves candidate window to
below the selected clause. This is caused by our bug of the hack in
TSFTextStore::GetTextExt().
First, we compute wrong minimum modified
offset of mContentForTSF. It stores last composition string when it's
initialized. Then, when a part of composition string is modified, it
sets minimum modified offset with the last composition string. However,
we don't update it when we receive notifications from content which means
all dispatched composition events are handled in content and
ContentCacheInParent stores character rects at least in this time. So,
this patch adds TSFTextStore::Content::OnCompositionEventsHandled() to
update the last composition string.
Next, TSFTextStore::GetTextExt() always adjusts acpStart to start of
composition string when acpStart is larger than composition start.
However, this causes this remaining problem. If ContentCacheInParent
stores character rects of even older composition string, we should use
it as far as possible. This must not be problem in most cases since
most Chinese characters and Japanese Kana characters have same width.
This touches share code of the hack between any TIPs. However, this must
not be risky because this patch just reduces amount of adjusting acpStart
offset in safe range.
MozReview-Commit-ID: KlDeaGa26UG
--HG--
extra : rebase_source : 6d906f9810b8e067018f7ff3ab2fd31f5bef49f6
Similar to ATOK, Japanist 10 requests all or part of composition string.
If we return TS_E_NOLAYOUT in this case, you'll see candidate window at
top-left of the screen.
For avoiding this issue, we should not return TS_E_NOLAYOUT to Japanist 10
when the query range is in composition string.
MozReview-Commit-ID: 2OPafUO5PQC
--HG--
extra : rebase_source : bd7a594d8d3540374d61860651b69528aa6e3793
TIP name of ATOK Passport's ATOK 31.1.2 is just "ATOK", not "ATOK " + release
year. Therefore, TSFStaticSink::IsATOKActiveInternal() returns false when
new ATOK is active. This patch updates it.
Additionally, this patch adds GUID list of new Japanese TIPs with comment.
They should be useful when somebody needs to add hack for them.
MozReview-Commit-ID: 6L5SjWEK6i0
--HG--
extra : rebase_source : e3ac9eb1377ee9143a4e2e9fa2ce4be98983bb4b
