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
New Windows devices are coming out that have GPU Device ID strings of
the form
ACPI\VEN_QCOM&DEV_007C&SUBSYS_CLS08998&REV_007C
as reported in the bug description. Since the VEN_ ID is not numeric,
this change interprets the QCOM string so that it can be whitelisted
and then whitelists it.
MozReview-Commit-ID: 2ABRzvHKn6v
--HG--
extra : rebase_source : 6951d3bfc060abc298c93dd31db07715d6857cc5
Currently, TSFTextStore::GetTextExt() refers mComposition for doing its own
hack. However, this means that it refers composition in TIP. However,
query event is computed with content information. So, even if TSFTextStore
dispatched eCompositionCommit event, it may not be handled by content yet.
In this case, we need information relative to last composition string.
So, TSFTextStore::GetTextExt() should refer IsHandlingComposition() and
last composition string information stored by mContentForTSF.
MozReview-Commit-ID: KMqrDmnUldU
--HG--
extra : rebase_source : cea97c9e9117028913cf45e4dc1e83e2b4f102e9
If remote process hasn't handled dispatched commit event yet, TSFTextStore
needs to dispatch query content event relative to latest composition string
information. So, TSFTextStore::mContentForTSF should cache composition start
and composition string length until pending composition events are handled
by content actually.
MozReview-Commit-ID: ARM851nNZGz
--HG--
extra : rebase_source : d4f1ddb197d3168f2db52849b2982779c388e2e8
When composition events are handled by content actually, widget receives
NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED notification. If focused content
is in a remote process, this is notified only when all sending composition
events are handled in the remote process. So, when widget receives the
notification can there is no composition in IME, that means that nobody is
composing composition at that time.
This patch adds TextEventDispatcher::IsHandlingComposition() which returns
false only when nobody has composition and makes TSFTextStore refer this
method because TSFTextStore needs to know if focused content has composition
in any cases.
MozReview-Commit-ID: F1ZZgFJAArD
--HG--
extra : rebase_source : 65e7f592e0ffd1c516e4dab16ab4ca8d7171f954
This patch adds following Microsoft's IMEs into the black list which set
their open state to "closed" when input scope is set to IS_URL and sets
input scope for the URL bar to IS_DEFAULT.
Additionally, this adds a new pref to disable this hack because a lot of
users will affect this hack but perhaps, somebody may not like this if
they use tablet.
The new black listed IMEs:
- Microsoft Bopomofo
- Microsoft ChangJie
- Microsoft Phonetic
- Microsoft Quick
- Microsoft New ChangJie
- Microsoft New Phonetic
- Microsoft New Quick
- Microsoft Pinyin
- Microsoft Pinyin New Experience Input Style
- Microsoft Wubi
- Microsoft IME for Korean (except on Win7)
- Microsoft Old Hangul
MozReview-Commit-ID: BwJKFcu80B8
--HG--
extra : rebase_source : 75aeed04504b476520102984ab6e7875c98b36c8
We call PDFiumParent::Close twice under certain conditions. Once in
PDFiumProcessParent::Delete, and once in PDFiumProcessParent's dtor. So we may
hit MOZ_ABORT which tell us that we are trying to close a closed channel.
This patch prevents hitting this abort by:
1. Only close the channel in PDFiumProcessParent::Delete, remove another call
in PDFiumProcessParent's dtor. (Please see the change in
PDFiumProcessParent.cpp).
2. Remove PDFiumParent::AbortConversion and relative code. We can just use
PDFiumParent::EndConversion instead. When calling PDFiumParent::Close, we
actually close the IPC channel *synchronously*, which means there is no need
to register a callback by PDFiumParent::AbortConversion to receive
actor-destroy callback.
MozReview-Commit-ID: 9i5j6t54J3h
--HG--
extra : rebase_source : 5f74ebc1ecc29e9983c30ca2dd63e0b49bd24a50
This is to make the header file more concise.
MozReview-Commit-ID: 7RFkppBdvbU
--HG--
extra : rebase_source : 781e3cadc60739297f37e826fef5f37a5c60a02d
extra : intermediate-source : 317d238af4025e64b8af61488fada9ec3d0b05c7
extra : source : 59d7baf15160231a53c459a3912e2c1430a1fa0e
While aborting conversion, we need to make sure there is no coversion task
executing in the PDFium process before destroying it.
MozReview-Commit-ID: 3Iqhe8KmYv2
--HG--
extra : rebase_source : 70d9f0b2e2986499e3061823e0c29830aa81d232
extra : source : 753ed705666fd4c55da456fb80604e4552d6bd52
We integrate PrintTargetEMF with the PDFium process to convert PDF into EMF in
this patch.
MozReview-Commit-ID: 5F0setrL94n
--HG--
extra : rebase_source : 1e52adbbe7502ca081c7029a15e4b3f486beb284
extra : source : 28f1671230fa70125e6971c9a287cb0658b89496
To move EMF conversion job to a dedicated process, I will implement a new
PrintTarget subclass, named PrintTargetEMF, to coordinate tasks among the
content process, chrome process and PDFium process. All the code that we
change in nsDeviceContextSpecWin is no longer needed.
MozReview-Commit-ID: GgKZoB92WYE
--HG--
extra : rebase_source : 4b1999bd83306dce162f76bd5e46015113a52e2b
Define ipdl and actor classes. Implementation of actors is added in subsequent
patches.
Control flow:
1. A user starts a printing job.
2. We create a PrintTarget to print web content page by page.
3. When printing pages:
a. PrintTarget, who lives in the chrome process, create a new FileDescriptor
and pass that FD to the content process.
b. The content process renders page contents into the given FD.
c. PrintTarget render that FD, which contains only one page, into a PDF
file.
d. PrintTaget asks PDFium process to convert that PDF file into EMF contents
by *ConvertToEMF*
e. The PDFium process converts the given PDF into EMF contents and send back
EMF contents by *ConvertToEMFDone*
f. PrintTaget playbacks that EMF onto a printer DC. One page is printed!
f. If all pages are printed, then finalize print job; Otherwise, loop back
to #a.
The control flow that we landed in bug 1370488 does not work like the flow
I described above.
In [1], we paint all pages into one single PDF file. After all pages are
rendered into this PDF file, we finalize the current print job, which means the
printing progress dialog is close. *Then* we start to convert that PDF into
EMF and print each EMF page onto printer DC. We can not cancel this conversion
task since the printing dialog is close, there is no UI allow us to do that.
One more serious problem is: since the printing progress dialog is close,
people think that printing is done, but actually it's not.
Except move EMF conversion to a dedicated process, named PDFium process, I will
also fix the behavior we landed in bug 1370488.
[1]
https://hg.mozilla.org/mozilla-central/rev/b611ec2a42bf
MozReview-Commit-ID: JAnmNc3gAVK
--HG--
extra : rebase_source : c64c4d39ccca16271959ade57edc2a8a087141b8
extra : intermediate-source : 6d6cff8961fa14160b624b2879d231b32c61a8f5
extra : source : b172d78e8c1d801e1e28afd8fedb9fcfff77d113
This is to make the naming more consistent with SavePageToBuffer.
MozReview-Commit-ID: 5miYvv9yFFR
--HG--
extra : rebase_source : d0a433e55a1a919a4207aee5f2fee9e75bd0a36e
With the help of these new function, we can serialize/deserialize EMF content
in/out a share memory object.
MozReview-Commit-ID: Dm45xEXmMqS
--HG--
extra : rebase_source : a84834075aa58099104ba9cdaa375da4b973c23b
extra : source : 61f81b148f8b1d1569d7cf279575b38f4570171f
All the functions added in Part 2 are utilities for sharing EMF/PDF contents
between processes.
MozReview-Commit-ID: 3qKosXH56kY
--HG--
extra : rebase_source : 677bf9f30399f28e1e094843448c133b0c2391a7
extra : source : b61b651ed6f668e32176353d346b25d23e2cd932
We will create several new files in the following patches for IPC and a new
subprocess. Several already existed files will be shifted into new build units,
we will meet several compile errors because of it.
This patch fixes those compile error in advance.
MozReview-Commit-ID: 5hd0sNYfBu0
--HG--
extra : rebase_source : d4cca529623586188ffebffd858f53188d12bb50
This is to make the header file more concise.
MozReview-Commit-ID: 7RFkppBdvbU
--HG--
extra : rebase_source : de0a2fc73ea43fedd90b1a0f2ae79d68749a00f7
extra : intermediate-source : 317d238af4025e64b8af61488fada9ec3d0b05c7
extra : source : 59d7baf15160231a53c459a3912e2c1430a1fa0e
While aborting conversion, we need to make sure there is no coversion task
executing in the PDFium process before destroying it.
MozReview-Commit-ID: 3Iqhe8KmYv2
--HG--
extra : rebase_source : c4597de6c13d35024090ec1e851ad1db5b790c7a
extra : source : 753ed705666fd4c55da456fb80604e4552d6bd52
We integrate PrintTargetEMF with the PDFium process to convert PDF into EMF in
this patch.
MozReview-Commit-ID: 5F0setrL94n
--HG--
extra : rebase_source : 3dfc6ce64f4cdc7d5d7e95d1f064d956af909a26
extra : source : 28f1671230fa70125e6971c9a287cb0658b89496
To move EMF conversion job to a dedicated process, I will implement a new
PrintTarget subclass, named PrintTargetEMF, to coordinate tasks among the
content process, chrome process and PDFium process. All the code that we
change in nsDeviceContextSpecWin is no longer needed.
MozReview-Commit-ID: GgKZoB92WYE
--HG--
extra : rebase_source : 16c3a3e730bd2395f98b558962ec8d0a5723198b
Define ipdl and actor classes. Implementation of actors is added in subsequent
patches.
Control flow:
1. A user starts a printing job.
2. We create a PrintTarget to print web content page by page.
3. When printing pages:
a. PrintTarget, who lives in the chrome process, create a new FileDescriptor
and pass that FD to the content process.
b. The content process renders page contents into the given FD.
c. PrintTarget render that FD, which contains only one page, into a PDF
file.
d. PrintTaget asks PDFium process to convert that PDF file into EMF contents
by *ConvertToEMF*
e. The PDFium process converts the given PDF into EMF contents and send back
EMF contents by *ConvertToEMFDone*
f. PrintTaget playbacks that EMF onto a printer DC. One page is printed!
f. If all pages are printed, then finalize print job; Otherwise, loop back
to #a.
The control flow that we landed in bug 1370488 does not work like the flow
I described above.
In [1], we paint all pages into one single PDF file. After all pages are
rendered into this PDF file, we finalize the current print job, which means the
printing progress dialog is close. *Then* we start to convert that PDF into
EMF and print each EMF page onto printer DC. We can not cancel this conversion
task since the printing dialog is close, there is no UI allow us to do that.
One more serious problem is: since the printing progress dialog is close,
people think that printing is done, but actually it's not.
Except move EMF conversion to a dedicated process, named PDFium process, I will
also fix the behavior we landed in bug 1370488.
[1]
https://hg.mozilla.org/mozilla-central/rev/b611ec2a42bf
MozReview-Commit-ID: JAnmNc3gAVK
--HG--
extra : rebase_source : 92276c366e3e8faa9be7a43fa64c2c5c56a7014b
extra : intermediate-source : 6d6cff8961fa14160b624b2879d231b32c61a8f5
extra : source : b172d78e8c1d801e1e28afd8fedb9fcfff77d113
This is to make the naming more consistent with SavePageToBuffer.
MozReview-Commit-ID: 5miYvv9yFFR
--HG--
extra : rebase_source : 5fa0594338ccae196866a1eb2e811e30b41c9290
With the help of these new function, we can serialize/deserialize EMF content
in/out a share memory object.
MozReview-Commit-ID: Dm45xEXmMqS
--HG--
extra : rebase_source : 02b571735de70b499aea30bfdb3c0a35fece3332
extra : source : 61f81b148f8b1d1569d7cf279575b38f4570171f
All the functions added in Part 2 are utilities for sharing EMF/PDF contents
between processes.
MozReview-Commit-ID: 3qKosXH56kY
--HG--
extra : rebase_source : f28b808f7007633fbeea3dbea78c19541bc73667
extra : source : b61b651ed6f668e32176353d346b25d23e2cd932
We will create several new files in the following patches for IPC and a new
subprocess. Several already existed files will be shifted into new build units,
we will meet several compile errors because of it.
This patch fixes those compile error in advance.
MozReview-Commit-ID: 5hd0sNYfBu0
--HG--
extra : rebase_source : 0d85c823e4ead4f09175f2cc83df811b2b4081ec
This does not remove the directives in widget/ContentCache.cpp as those crash
annotations should be temporary and will be removed once bug 1405832 is fixed.
MozReview-Commit-ID: F0STyYDx8F4
--HG--
extra : rebase_source : 737d3e500e1dd066730660fede52226e832305e6
C5038 is a new warning in VS2017, similar to gcc and clang's -Wreorder, which is enabled by -Wall. We should enable C5038 so Windows developers can see these warnings locally instead of when gcc and clang fail with warnings-as-errors on Try.
https://blogs.msdn.microsoft.com/vcblog/2017/07/21/diagnostic-improvements-in-vs2017-15-3-0/
We need to suppress C5038 warnings from Windows Runtime Library header files (wrl.h) included in ANGLE and widget/windows:
z:\build\build\src\vs2017_15.4.2\SDK\Include\10.0.15063.0\winrt\wrl\wrappers\corewrappers.h(515): error C5038: data member 'Microsoft::WRL::Wrappers::Details::SyncLockWithStatusT<Microsoft::WRL::Wrappers::HandleTraits::SemaphoreTraits>::sync_' will be initialized after data member 'Microsoft::WRL::Wrappers::Details::SyncLockWithStatusT<Microsoft::WRL::Wrappers::HandleTraits::SemaphoreTraits>::status_'
...
And suppress C5038 warnings in upstream webrtc code:
media/webrtc/trunk/webrtc/modules/video_capture/windows/BaseFilter.cpp(176): error C5038: data member 'mozilla::media::BaseFilter::mClsId' will be initialized after data member 'mozilla::media::BaseFilter::mState'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(169): error C5038: data member 'mozilla::media::BasePin::mFilter' will be initialized after data member 'mozilla::media::BasePin::mLock'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(170): error C5038: data member 'mozilla::media::BasePin::mLock' will be initialized after data member 'mozilla::media::BasePin::mName'
media/webrtc/trunk/webrtc/modules/video_capture/windows/BasePin.cpp(172): error C5038: data member 'mozilla::media::BasePin::mDirection' will be initialized after data member 'mozilla::media::BasePin::mQualitySink'
MozReview-Commit-ID: BMDVkvQXNoq
--HG--
extra : rebase_source : 0d5ede9530d0d0750b8fffdc1cdfdc646ec8f22a
Currently, widget doesn't show VKB when input context change is caused by JS.
However, if it's caused by an event handler of a user input, user may expect
to open VKB. For example, if a touch event in fake editor causes moving
focus to actual editable node, user expect to show VKB.
Therefore, InputContextAction should declare two causes. One is unknown but
occurred during handling non-keyboard event. The other is unknown but occurred
during handling keyboard event.
However, EventStateManager doesn't have an API to check if it's being handling
a keyboard event. Therefore, this patch adds it first.
AutoHandlingUserInputStatePusher sends event type to StartHandlingUserInput()
and StopHandlingUserInput() of EventStateManager and sUserKeyboardEventDepth
manages the number of nested keyboard event handling. Therefore,
EventStateManager::IsHandlingKeyboardInput() can return if it's handling a
keyboard event.
IMEStateManager uses this new API to adjust the cause of changes of input
context.
Finally, InputContextAction::IsUserInput() is renamed to IsHandlingUserInput()
for consistency with EventStateManager and starts to return true when the
input context change is caused by script while it's handling a user input.
MozReview-Commit-ID: 5JsLqdqeGah
--HG--
extra : rebase_source : 9fcf7687d1bf90eeebbf6eac62d4488ff64b083c
ATOK started to be TIP of TSF since 2011. Older than it, i.e., ATOK 2010 and
earlier have a lot of problems even for daily use. Perhaps, the reason is
Win 8 has a lot of changes around IMM-IME support and TSF, and ATOK 2010 is
released earlier than Win 8.
ATOK 2006 crashes while converting a word with candidate window.
ATOK 2007 doesn't paint and resize suggest window and candidate window
correctly (showing white window or too big window).
ATOK 2008 and ATOK 2009 crash when user just opens their open state.
ATOK 2010 isn't installable newly on Win 7 or later, but we have a lot of
crash reports.
Note that ATOK 2006 is the first version supporting Win XP x64. So, ATOK 2005
must not support x64 apps.
Unfortunately, we cannot block loading DLLs of them. Therefore, IMEHandler
should disassociate IMC from active window when user changes active keyboard
layout to the legacy ATOK and not associate IME with any window when
SetInputContext() is called even with "enabled". Additionally, when user
changes active keyboard layout from the legacy ATOK to one of the other
keyboard layouts, IMEHandler should associate IMC with current window for
new active IME.
MozReview-Commit-ID: RVYwmYxzO7
--HG--
extra : rebase_source : c237a3aca6ceb6a1f7251bd9421e4b905be5bc6c
Some odd touchpad utils give focus to window under mouse cursor when user tries
to scroll the content with swiping or something.
This is really odd behavior because some windows like popup windows doesn't
want focus. However, such ones do actually. For making easier to check such
device's behavior, we should have a pref to emulate such behavior.
MozReview-Commit-ID: 6euwpHn7blf
--HG--
extra : rebase_source : cc23f08f422f25f2851404696e06e069c7936186
This patch will
* Move native print dialog code to the PrintDialogService of widget.
* Toolkit call PrintDialogService instead of calling the native print dialog.
* Change SetWindowText/CreateWindow to SetWindowTextW/CreateWindowW
in order to treat localized string correctly.
MozReview-Commit-ID: DOgp3STaJ4t
--HG--
rename : toolkit/components/printingui/win/nsPrintDialogUtil.cpp => widget/windows/nsPrintDialogUtil.cpp
rename : toolkit/components/printingui/win/nsPrintDialogUtil.h => widget/windows/nsPrintDialogUtil.h
extra : rebase_source : 9b428f528156a70f5a127b1eeec60f6f593387a0
In order to move print native dialog code to windows widget, this patch will
create skeleton of PrintDialogService to windows widget.
Toolkit code(i.e. nsIPrintingPrompotService) will call this PrintDialogService.
Note that this PrintingDialogService suppose running on main process, so we
should call this interface from main process(i.e. nsPrintingPromptService, not
nsPrintingProxy).
MozReview-Commit-ID: 3P6kac9I9W4
--HG--
extra : rebase_source : 5b5ecd104cf4cecd1b68a3d6d4b33aca9fea9548
The functions changed are given signed arguments (that are converted to unsigned).
Changing them to signed resolves the warnings and preserves the original values.
MozReview-Commit-ID: BxIAECFiuQR
--HG--
extra : rebase_source : c48cef46f3ad5a060ad1f33d1c97744bfa8a82d7
inline functions are supposed to be declared in the header file, so the compiler can inline them.
gcc complains about this, but clang/msvc apparently do not.
We also needed to move the DeadKey struct and class into the header, as the function calls a
method on the DeadKey class, and you can't do that on a forward declared class.
MozReview-Commit-ID: 8NxP59AXuZi
--HG--
extra : rebase_source : 9fd74d2c571bdeb4244cb63baf508946a2f19aa6
The intention of these macros here is merely to log a warning and enable
a developer to notice the inconsistency. Pass the result to Unused.
MozReview-Commit-ID: 9IOuwQ3InVm
--HG--
extra : rebase_source : 83f265a5e042dee0c2ad66d45b67906f1b0422aa
This avoids a lot of mismatches between nsAString and char16_t*, thus removing
many getter_Copies() and ToNewUnicode() and get() calls, and generally making
things simpler.
Note: the patch removes GetDefaultPrinterNameFromGlobalPrinters() by simply
inlining it at its two callsites, which is easy with the changed types.
--HG--
extra : rebase_source : 9ab9b3694f093fc9b22c7f8e2394a98674d76c11
All our widgets support it with a constant true.
MozReview-Commit-ID: JMEItUsxYWq
--HG--
extra : rebase_source : e7e0a3f83001813239338bc5b3895252e1fb3ea6
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Removes the XPCOM interface for nsIDOMHTMLCanvasElement, replacing it
with binding class usage.
MozReview-Commit-ID: DQJhqGlY8U6
--HG--
extra : rebase_source : a33146a22ee356a0840bb9fef82d51b2b315f6d7
All our widgets support it with a constant true.
MozReview-Commit-ID: JMEItUsxYWq
--HG--
extra : rebase_source : a2661dce1ac191fdf098e631cd7878f0215643d5
When "mozAwesomebar" is set to inputmode value, that means that the Smart
Location Bar gets focus. In that case, we should notify IME of input scopes
as "URL" because on-screen keyboard for URL has some useful additional keys
but they are not hindrances even when users want to type non-URL text.
On the other hand, MS-IME for Japanese and Google Japanese Input changes their
open state to "closed" if we notify them of URL input scope. A lot of users
complain about this behavior. Therefore, we should notify only them of
"Default" input scope even when "mozAwesomebar" has focus.
MozReview-Commit-ID: DIgqpR7TXQx
This warning is saying the operation may be undefined because the value of
->left is not guarenteed to be the same because of undefined order of operations.
Fortunately, this seems like a typo and we actually meant to assign ->bottom
MozReview-Commit-ID: H5G8fnDwIJP
--HG--
extra : rebase_source : cd6a2463a90b6675b12bb8255fe605937771bee8
When we UnregisterAudioSessionNotification in response to an OnSessionDisconnected
message, we unintentionally decrement the refcount before restoring it. This KungFu
grips us for the duration of that operation.
--HG--
extra : rebase_source : 7c7e786064811d040d23741c143d9eef04edb5e0
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
With this change, we are able to load PDFium engine from different library.
MozReview-Commit-ID: ErAZCPRzRR5
--HG--
extra : rebase_source : f0421af9c70d69564ed8f96d32870314871aabef
The problem happened only on themed widget. The problem was triggered by Bug 888870. It just added Windows 8.1 support. When high contrast mode was enabled on Win 10, background color problem happend on themed widgets. There were 2 patterns.
- After hover the menu item, its background color remained highlighted
- After hover the menu item, its background color became black
From it, the problem seemed to be caused by background color drawing of themed widgets. nsNativeThemeWin::DrawWidgetBackground() does the background color drawing. AssumeThemePartAndStateAreTransparent() controls skipping background color drawing of themed widgets. If AssumeThemePartAndStateAreTransparent() was removed, the problem was addressed. From it, how DrawThemeBackground() works seems to be changed on high contrast mode since since Win8.1. To address the problem, the patch remove the skipping on high contrast mode since since Win8.1
dcWidth and dcHieght are used only once, we do not need to define a local
variable for any of them.
MozReview-Commit-ID: Fw5rHqtUPQN
--HG--
extra : rebase_source : 52b5381319fc6626e7f1ec4111dad70482a092cd
Currently, WindowsEMF::InitForDrawing can be used once. With the change in this
patch, we can call WindowsEMF::InitForDrawing and Playback/SaveToFile in pair
as many times as we want.
MozReview-Commit-ID: 4fbY4Q6i9v5
--HG--
extra : rebase_source : 4df3fc7d8663d7f552c96204a16d73261bfc9dd7
Because UBSan complains about casting -1:
> runtime error: load of value 4294967295, which is not a valid value for type 'nsCursor'
--HG--
extra : rebase_source : 037a96700228ea0d427afa7c25c40490c701cdc4
We'll need it to determine if NV12 D3D11 surface are operationals.
MozReview-Commit-ID: FvsxGhnv7H1
--HG--
extra : rebase_source : 4580819b19aa36d7d26ee7d05934eaaddd17206a
Currently, we initialize TSF modules when there is only message window (this
started from bug 1341915). At this time, QQ Input (Simplified Chinese TIP)
fails to initialize itself.
Therefore, we should put off to initialize TSF modules after creating first
normal window. Then, initialize its IMC and input context for the window.
IMEHandler::InitInputContext() should be called when each normal window is
created. Therefore, calling Initialize() from it can guarantee there is
at least one normal window when Initialize() is called.
MozReview-Commit-ID: IfR4y3pYv6J
--HG--
extra : rebase_source : 3f36acfa65567f140eea9c7fc12d6268aadbd5ef
Additionally, do not call RegisterDragDrop for hidden windows.
MozReview-Commit-ID: Fv8j9FntGGT
--HG--
extra : rebase_source : fccbc576887d000805da8ac915d16fc4fddfeceb
This fixes improper usages of Find where an offset was actually being use for
the boolean ignore case flag. It also fixes a few instances of passing in a
literal wchar_t to our functions where a NS_LITERAL_STRING or char16_t should
be used instead.
This fixes improper usages of Find where an offset was actually being use for
the boolean ignore case flag. It also fixes a few instances of passing in a
literal wchar_t to our functions where a NS_LITERAL_STRING or char16_t should
be used instead.
--HG--
extra : rebase_source : 5de1e9335895d65e6db06c510e8887d27be3390f
extra : source : f762f605dd83fc6331161a33e1ef5d54cafbd08d
* OSX
Make the lock of the type kIOPMAssertionTypeNoDisplaySleep and kIOPMAssertionTypeNoIdleSleep
as a singleton. Won't need to require an extra lock.
* Windows
Add |mRequireForDisplay| to ensure the "audio-playing" won't overwrite the previous
display requirement.
* Android
Add "audio-playing" and "video-playing", and make sure the audio-lock won't be cancel
when receiving "WakeLockDelegate.STATE_LOCKED_BACKGROUND".
MozReview-Commit-ID: 97oNX7H2qij
--HG--
extra : rebase_source : 24fa8b267ad97d668fa55462d1f61ef5c92b632f
According to [1], kIOPMAssertionTypeNoDisplaySleep prevents display sleep and
kIOPMAssertionTypeNoIdleSleep prevents idle sleep.
We should use kIOPMAssertionTypeNoIdleSleep for audio playing, because it won't
need to block the display.
[1] https://developer.apple.com/library/content/qa/qa1340/_index.html
---
On Windows, ES_DISPLAY_REQUIRED forces display on, and ES_SYSTEM_REQUIRED forces
system on working state [2].
[2] https://msdn.microsoft.com/zh-tw/library/windows/desktop/aa373208(v=vs.85).aspx
MozReview-Commit-ID: Izs29PdzQOW
--HG--
extra : rebase_source : d0726131735b9cedf566f937204e585345b9d5e3
For knowing the wake lock usage more clearly, we should use more specific topic name.
In OSX, you can use "$ pmset -g assertions" to check all the wakelock.
In Windows, using "$ powser -energy" to generate the energy report.
MozReview-Commit-ID: rAXnkxTvLc
--HG--
extra : rebase_source : 42ebf204673d3c913739f64c71c24af20d37c95d
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
