Граф коммитов

101 Коммитов

Автор SHA1 Сообщение Дата
Simon Giesecke cb0734d274 Bug 1613985 - Use default for equivalent-to-default constructors/destructors in widget. r=jmathies
Differential Revision: https://phabricator.services.mozilla.com/D66012

--HG--
extra : moz-landing-system : lando
2020-03-16 10:56:57 +00:00
Bogdan Tara c60fd3fdd2 Backed out 4 changesets (bug 1613985) for causing build bustages CLOSED TREE
Backed out changeset fba0caac746c (bug 1613985)
Backed out changeset 8605d7a19107 (bug 1613985)
Backed out changeset 41e858fbf235 (bug 1613985)
Backed out changeset 847433cf1e0a (bug 1613985)
2020-03-16 12:41:41 +02:00
Simon Giesecke 2d961c08ab Bug 1613985 - Use default for equivalent-to-default constructors/destructors in widget. r=jmathies
Differential Revision: https://phabricator.services.mozilla.com/D66012

--HG--
extra : moz-landing-system : lando
2020-03-16 09:14:12 +00:00
Emilio Cobos Álvarez 256c124f94 Bug 1609996 - Reorder some includes affected by the previous patches. r=froydnj
This was done by:

This was done by applying:

```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
         from subprocess import Popen, PIPE, check_output, CalledProcessError

         diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
-        args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+        args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']

         if not output_file:
             args.append("-i")
```

Then running `./mach clang-format -c <commit-hash>`

Then undoing that patch.

Then running check_spidermonkey_style.py --fixup

Then running `./mach clang-format`

I had to fix four things:

 * I needed to move <utility> back down in GuardObjects.h because I was hitting
   obscure problems with our system include wrappers like this:

0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94              ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94     MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94                                ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)

   Which I really didn't feel like digging into.

 * I had to restore the order of TrustOverrideUtils.h and related files in nss
   because the .inc files depend on TrustOverrideUtils.h being included earlier.

 * I had to add a missing include to RollingNumber.h

 * Also had to partially restore include order in JsepSessionImpl.cpp to avoid
   some -WError issues due to some static inline functions being defined in a
   header but not used in the rest of the compilation unit.

Differential Revision: https://phabricator.services.mozilla.com/D60327

--HG--
extra : moz-landing-system : lando
2020-01-20 16:19:48 +00:00
Emilio Cobos Álvarez aa3a695712 Bug 1609996 - Remove mozilla/Move.h. r=froydnj
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'

Further manual fixups and cleanups to the include order incoming.

Differential Revision: https://phabricator.services.mozilla.com/D60323

--HG--
extra : moz-landing-system : lando
2020-01-20 16:18:20 +00:00
Henri Sivonen 8f73b57bca Bug 1600561 - Handle eCompositionCommitAsIs in ContentCacheInParent::OnCompositionEvent. r=masayuki
Differential Revision: https://phabricator.services.mozilla.com/D55417

--HG--
extra : moz-landing-system : lando
2019-12-02 15:27:29 +00:00
Ryan Hunt 0eeced87be Bug 1534395 - Rename TabParent to BrowserParent. r=nika
This commit renames TabParent to BrowserParent.

Differential Revision: https://phabricator.services.mozilla.com/D28133

--HG--
rename : dom/ipc/TabParent.cpp => dom/ipc/BrowserParent.cpp
rename : dom/ipc/TabParent.h => dom/ipc/BrowserParent.h
extra : rebase_source : d2706b9f42177d8de16068b7b1d088a44b8720a4
extra : histedit_source : a617ddac45c58050ef799116a67d2d983f2a8f6d%2C1d1dabd8761a32d548a6fbf1027be960698f6a5e
2019-04-09 16:38:15 -05:00
Sylvestre Ledru 265e672179 Bug 1511181 - Reformat everything to the Google coding style r=ehsan a=clang-format
# ignore-this-changeset

--HG--
extra : amend_source : 4d301d3b0b8711c4692392aa76088ba7fd7d1022
2018-11-30 11:46:48 +01:00
Emilio Cobos Álvarez fffb25b74f Bug 1465585: Switch from mozilla::Move to std::move. r=froydnj
This was done automatically replacing:

  s/mozilla::Move/std::move/
  s/ Move(/ std::move(/
  s/(Move(/(std::move(/

Removing the 'using mozilla::Move;' lines.

And then with a few manual fixups, see the bug for the split series..

MozReview-Commit-ID: Jxze3adipUh
2018-06-01 10:45:27 +02:00
Masayuki Nakano 6e70ab6b93 Bug 1422230 - part 2: ContentCacheInParent should allow to query content relative to composition string even after sending eCompositionCommit(AsIs) event but not yet handled in the remote process r=m_kato
Currently, ContentCacheInParent uses selection when it handles query content
event whose input offset is relative one after sending eCompositionCommit(AsIs)
event but it's not yet handled by the remote process.  However, in this case,
selection may not be modified with committed string.

So, when mPendingCommitCount is not 0, ContentCacheInParent should compute
absolute offset with the latest composition string information.  For doing
this, it needs to keep storing mCompositionStart until eCompositionCommit(AsIs)
is handled in the remote process actually.

MozReview-Commit-ID: 2Dc69HNIbvh

--HG--
extra : rebase_source : 4be432ad363022e4b3f2e3c82c8d229dc9af889d
2018-01-12 15:05:24 +09:00
Milan Sreckovic bd27b86da3 Bug 1423559: Use BaseRect access methods instead of member variables in widget/ r=mstange
MozReview-Commit-ID: AqnztoUbsmk

--HG--
extra : rebase_source : 76a232a08b42ed73b4922c03bc0f2e9d1769203b
2018-01-10 11:14:16 -05:00
Masayuki Nakano 600d0e1cd9 Bug 1423456 - ContentCacheInParent::OnEventNeedingAckHandled() shouldn't decrement mPendingCompositionCount when it receives eCompositionCommit(AsIs) from the remote process but the composition has already been committed by a request to commit composition r=m_kato
After fixing bug 1420849, remote process started to ignore composition events
after it synthesizes eCompositionCommit event after requesting to commit
composition.  However, remote process still keeps returning composition events
when it receives from the main process.  So, if the main process has already
sent eCompositionCommit(AsIs) event when it's requested to commit composition
from the remote process, ContentCacheInParent::OnEventNeedingAckHandled()
receives both eCompositionCommitRequestHandled and eCompositionCommit(AsIs)
events for *a* composition.  Therefore, mPendingCompositionCount may be
decremented twice for a composition.  This causes hitting MOZ_DIAGNOSTIC_ASSERT.

So, ContentCacheInParent need to manage if sent composition events are ignored
or not.  Then, ContentCacheInParent::OnEventNeedingAckHandled() stops
decrementing mPendingCompositionCount when it receives eCompositionCommit(AsIs)
events which are ignored by the remote process.

This patch manages it with |mIsChildIgnoringCompositionEvents| and changes
|bool mIsPendingLastCommitEvent| to |uint8_t mPendingCommitCount| for
making ContentCache be able to manage multiple pending commit events if
its remote process is too busy.

MozReview-Commit-ID: CYQDeZXl7TJ

--HG--
extra : rebase_source : 6de1e2f1302d556d45d19c73b4d1ea3f86b65373
2017-12-06 15:07:41 +09:00
Masayuki Nakano 8418b1b497 Bug 1420849 - Make PuppetWidget discard composition events after requesting commit composition and synthesizing eCommitComposition event until new eCompositionStart event comes r=m_kato
When ContentCacheInParent::RequestIMEToCommitComposition() returns true,
the remote process will synthesize eCompositionCommit event.  This causes
destroying TextComposition event in the remote process (by
IMEStateManager::DispatchCompositionEvent()).  Then,
IMEStateManager::DispatchCompositionEvent() will recreate new TextComposition
instance when it receives new composition event.  Then, it may request
to commit composition to the main process via PuppetWidget accidentally.

So, after PuppetWidget::RequestIMEToCommitComposition() synthesizes
eCompositionCommit, PuppetWidget should discard following composition events
until it receives eCompositionStart since they are unnecessary for the content
and they are for the old composition, i.e., outdated events.

MozReview-Commit-ID: BNRcoYxABpd

--HG--
extra : rebase_source : caea469afeed8cc373aeca33199ac0d570052569
2017-11-27 20:34:01 +09:00
Masayuki Nakano b1a20692e4 Bug 1418747 - ContentCacheInParent needs to initialize mPendingCommitLength with 0 when it's created r=m_kato
ContentCacheInParent::mPendingCommitLength is never initialized until it
receives eCompositionCommit(AsIs) event from widget or receives the latest
content from the remote process when there is a composition.

The bug is, immediately after dispatching eCompositionStart and first
eCompositionChange event, MS Pinyin tries to query the character at caret,
but ContentCacheInParent::HandleQueryContentEvent() tries to resolve
related position of an eQueryTextRect event with the uninitialized
mPendingCommitLength.  Therefore, the query almost always fails and MS Pinyin
gives up to show its candidate window.

This patch just initializes the member with 0.

MozReview-Commit-ID: JyYNqi8hoTa

--HG--
extra : rebase_source : bdc504f83abdbb21e11ea69290908ed501e9a65f
2017-11-27 18:51:01 +09:00
Gabriele Svelto cbb30621ec Bug 1402519 - Remove MOZ_CRASHREPORTER directives from widget; r=froydnj
--HG--
extra : rebase_source : 4472a8d6ce5edf1b5a4665d522a1816020308a43
2017-11-23 10:59:04 +01:00
Masayuki Nakano 02815812a9 Bug 1405832 - part 4: ContentCacheInParent::OnEventNeedingAckHandled() shouldn't crash in release build r=m_kato
For protecting main process, we should stop crashing main process in release
build even when we detect our bug.  However, we should keep crashing with
MOZ_DIAGNOSTIC_ASSER which is enabled only on Night and Developer Edition.

MozReview-Commit-ID: 5BQ46IFzXXj

--HG--
extra : rebase_source : 1a894bb23b6b9f386b19eba95d14cd8db80fb2c6
2017-11-20 23:30:18 +09:00
Masayuki Nakano 07dc211d1a Bug 1405832 - part 3: ContentCacheInParent::RequestIMEToCommitComposition() should call nsIWidget::NotifyIME() via TextComposition::RequestToCommit() r=m_kato
Now, TextComposition::RequestToCommit() manages if it has already requested
IME to commit or cancel composition and this is important for redundant
requests.  Therefore, ContentCacheInParent::RequestIMEToCommitComposition()
shouldn't call nsIWidget::NotifyIME() directly.

MozReview-Commit-ID: 69VpgyK9Jk5

--HG--
extra : rebase_source : 5b86c11669c7a69ceb0a2af155765834621ee968
2017-11-20 23:08:37 +09:00
Masayuki Nakano b07eba4f1e Bug 1405832 - part 1: ContentCacheInParent::RequestIMEToCommitComposition() should increment mPendingEventsNeedingAck itself if it treat the request handled synchronously without actually requesting IME to commit composition r=m_kato
This is a simple bug of ContentCacheInParent.  When
ContentCacheInParent::RequestIMEToCommitComposition() returns true,
PuppetWidget::RequestIMEToCommitComposition() will send
eCompositionCommitRequestHandled pseudo event message back to the main process.
This causes counting down mPendingEventsNeedingAck in
ContentCacheInParent::OnEventNeedingAckHandled().  Therefore, in the normal
path, ContentCacheInParent::OnCompositionEvent() increments it for receiving
the pseudo event message.

However, if the tab parent has already lost focus,
RequestIMEToCommitComposition() returns true without requesting native IME to
commit composition.  So, ContentCacheInParent::OnCompositionEvent() cannot
increment mPendingEventsNeedingAck for coming
eCompositionCommitRequestHandled.  Therefore, RequestIMEToCommitComposition()
needs to increment mPendingEventsNeedingAck by itself when it won't request
IME to commit composition but it returns true.

MozReview-Commit-ID: 4Alwfy8avB

--HG--
extra : rebase_source : 2588221568440beecc2b992910fa53729b8abe1c
2017-11-20 22:20:02 +09:00
Masayuki Nakano 8830e5ebb9 Bug 1409656 - Append log of ContentCacheInParent::RequestIMEToCommitComposition() in the latest 2 sets of composition events to app notes of crash report when ContentCacheInParent::OnEventNeedingAckHandled() meets unexpected state and crash itself r=m_kato
This is a follow up patch of bug 1408086.  The previous patch starts to append
log of 2 sets of composition events to app notes of crash report when
ContentCacheInParent::OnEventNeedingAckHandled() meets unexpected state and
crash itself.  However, now, we know the unexpected state occurs when TabParent
receives eCompositionCommitRequestHandled message from its remote process.
The event comes when ContentCacheInParent::RequestIMEToCommitComposition()
returns true.  So, we need to know what occurs in the method before the crash.

This patch defines each case of RequestIMEToCommitComposition() with an enum
class, RequestIMEToCommitCompositionResult and make
RequestIMEToCommitComposition() append one of its value to the array.
Then, ContentCacheInParent discards unnecessary log of this when it discards
log of old composition events.  Finally, appends the log to the app notes of
crash report.

MozReview-Commit-ID: 9sJyl4SvUXu

--HG--
extra : rebase_source : f7e90a157d3819523d3d8932d9f8af5d94e2db1f
2017-10-19 00:13:42 +09:00
Masayuki Nakano 929e66153e Bug 1408086 - Append log of the latest 2 sets of composition events when ContentCacheInParent::OnEventNeedingAckHandled() meets unexpected state and crash itself r=m_kato
We have a lot of crash reports in OnEventNeedingAckHandled() due to unexpected
state (hit MOZ_RELEASE_ASSERT). However, it's unclear what occurs and we're not
sure there are how many cases to crash because the stack trace is too short
because the method is called when TabParent receives event handled message from
the remote process. I.e., it doesn't show what happens immediately before the
crash.

This patch puts 2 sets of composition events to app notes of crash report when
it needs to crash.  This *might* make damage to the performance.  If so, after
fixing the crashes, we should back this out.  Fortunately, we have a lot of
reports from either Nightly or Beta.

MozReview-Commit-ID: 9tDrEIf72MG

--HG--
extra : rebase_source : 523c183466740e08d6c8cc3836b6b52310c1e53a
2017-10-13 02:50:47 +09:00
Chris Peterson 45aa2a8e8e Bug 870698 - Part 2: Replace Append("") with AppendLiteral(""). r=erahm
MozReview-Commit-ID: CrkIP4iHP1U

--HG--
extra : rebase_source : 5dc4e91a3f1860773c199f1abf3f66479218834a
extra : intermediate-source : ba51cc79847f2b43ba616f4a5d2bbc6958ca9f6d
extra : source : 1fda2fa990cc918c748ffa14fcc5dbe13fe3bdc3
2017-09-03 22:14:11 -07:00
Chris Peterson 9f4c1f5278 Bug 870698 - Part 1: Replace Assign("") with AssignLiteral(""). r=erahm
MozReview-Commit-ID: A0u9PP49OW3

--HG--
extra : rebase_source : 7d5286959f510eb4b7df1b7e32d5b9b58719c48b
extra : intermediate-source : f552b4a78236c42bc09030b3eb008725a3edb9c8
extra : source : 26ac4a1014f6661a70e3bf9f552407e12c2c3981
2017-09-03 22:12:56 -07:00
Kartikaya Gupta ba4b3b9101 Bug 1384233 - Remove SizePrintfMacros.h. r=froydnj
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.

MozReview-Commit-ID: 6s78RvPFMzv

--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
2017-07-26 16:03:57 -04:00
Masayuki Nakano 22aa198848 Bug 1380652 - ContentCacheInParent::RequestIMEToCommitComposition() shouldn't handle the request synchronously when its TabParent has already sent eCompositionCommit(AsIs) event of the composition r=m_kato
If ContentCacheInParent::RequestIMEToCommitComposition() returns true after its TabParent has already sent eCompositionCommit(AsIs) event, ContentCacheInParent::OnEventNeedingAckHandled() will receive both eCompositionCommit(AsIs) and eCompositionCommitRequestHandled for a composition.  Then, that causes making mPendingCompositionCount decreased twice.  That causes the crash.

So, even if its TabParent already lost focus, it should return false after its TabParent sent eCompositionCommit(AsIs).

MozReview-Commit-ID: 6OylQtc8kgC

--HG--
extra : rebase_source : 9d8f2ab2b25f129ddbca75fcc8fb4bc7c3a96e56
2017-07-21 21:22:23 +09:00
Masayuki Nakano f303a1f631 Bug 1379448 - ContentCacheInParent::FlushPendingNotifications() should do nothing if aWidget is nullptr r=m_kato
Due to the fix of bug 1376424, ContentCacheInParent::FlushPendingNotifications() may be called when aWidget is nullptr. In this case, it doesn't need to do anything.  So, it should ignore the call.

MozReview-Commit-ID: Fj3J76v6Xuk

--HG--
extra : rebase_source : 18c722628a3ae8fa50beca3908d5e732cec404d9
2017-07-10 17:33:26 +09:00
Masayuki Nakano cac05f3ef3 Bug 1377672 - part4: ContentCacheInParent::RequestIMEToCommitComposition() should ignore too late requests r=m_kato
Requests to commit/cancel composition came from remote process with sync message.  So, it may be too late.  E.g.,

* If the process already sent new composition start but is not handled by the remote process yet.
* If the process already send commit message but it's not handled by the remote process yet.
* If focus was already moved to different process.

In the former 2 cases, the remote process should wait eCompositionCommit(AsIs) events for clearing TextComposition.  Therefore, the requested should be treated as it's handled asynchronously.

In the last case, the remote process should commit composition with latest composition string in the main process because if the remote process commits composition with "current" composition string in it, user may lost some inputted text.

MozReview-Commit-ID: 18BUoZZq7HS

--HG--
extra : source : fd1585ad670a87d8b1ef8908931f3d4037751475
2017-07-05 19:55:18 +09:00
Masayuki Nakano d6e921676c Bug 1377672 - part3: IMEStateManager::NotifyIME() should ignore notifications and requests which comes from unexpected process r=m_kato,smaug
IME should receive notifications and requests only from proper process.  E.g., IME shouldn't commit composition by a request which came from previous focused process.

This patch makes that IMEStateManager::NotifyIME() takes pointer to TabParent optionally.  If the request or notification came from remote process, it should be non-nullptr.  Then, this makes it ignore notifications and requests from unexpected process.

Note that this patch also touches some gfx headers because they use |ipc::| but compiler is confused at the ambiguousness between |mozilla::ipc::| and |mozilla::dom::ipc::|.

Finally, this patch changes the NS_ASSERTION in IMEHandler::OnDestroyWindow() to MOZ_ASSERT because the orange caused by the NS_ASSERTION was not realized since there was already an intermittent orange bug caused by different NS_ASSERTION.

MozReview-Commit-ID: 9CgKXQRJWmN

--HG--
extra : source : f3b5711908870c5e0e852a399a07e0ae721a12f1
2017-07-06 00:47:40 +09:00
Masayuki Nakano 53e33d996d Bug 1376417 - part2: ContentCache should adjust composition start offset when querying content with relative offset r=m_kato
When IME commits composition and restarts composition immediately, query event with relative offset doesn't work as expected until the commit is handled in the remote process.

Therefore, this patch makes ContentCacheInParent store the last commit string length until it's handled in the content.  Note that ContentCache doesn't need to store all commit string lengthes which have not been handled in the remote process yet because it's important and possible to return next character of commited composition only when there are not 2 or more pending compositions.  Even if there are, i.e., the remote process is too busy, ContentCacheInParent doesn't have necessary character rect.

MozReview-Commit-ID: 8gBr8kO4JcF

--HG--
extra : rebase_source : f4748928c07ee284a5c312b89291e3a4fb8f790d
2017-06-29 18:31:09 +09:00
Masayuki Nakano 71bb543ee5 Bug 1376424 - part1: TabChild should notify TabParent of "request to commit composition" handled r=m_kato
The problem is, only when requesting IME to commit or cancel composition is handled synchronously, TabParent does not send the dispatched eCompositionCommit(AsIs) event to the remote process.  Therefore, TabParent (and ContentCacheInParent) never receives  the message from the remote process.

This patch makes TabChild notifies TabParent of eCompositionCommitRequestHandled special event message after TabChild dispatches eCompositionCommit into the DOM tree.  Then, ContentCacheInParent should decrease mPendingCompositionCount and mPendingEventsNeedingAck as usual composition event messages.

MozReview-Commit-ID: 7ec5HPiE687

--HG--
extra : rebase_source : a9366abf6f8feec2d6ac639fd37f5b5c6ddd9586
2017-06-27 23:41:12 +09:00
Masayuki Nakano a6f874fcf1 Bug 1376424 - part0: Backout the patch for bug 1368554 r=m_kato
TextComposition in the main process is destroyed when the main process sends eCompositionCommit(AsIs) to focused remote process.  Therefore, ContentCacheInParent::mCompositionPendingCount is never 2 or more now.

It may cause ContentCacheInParent::Assign() setting older composition's start offset to current composition's start offset in the main process.

For making uplift the following patch easier, the wrong patch should be backed out first.

MozReview-Commit-ID: IHWc7qZBQtc

--HG--
extra : rebase_source : d3936fa82ed670217b711d15bbb0201a8741501b
2017-06-27 22:02:07 +09:00
Masayuki Nakano ec9ae17b0c Bug 1368554 ContentCacheInParent::mPendingCompositionCount should be decreased when TextCompositin which has dispatched composition events to corresponding remote process r=m_kato
ContentCacheInParent::mPendingCompositionCount is now managed with composition events which TabParent received. However, TextComposition doesn't dispatch composition events after coming request to commit active composition.  Therefore, composition is committed forcibly in a remote process over 255 times, the main process crashes.

It's the safest way to use TextComposition to manage ContentCacheInParent::mPendingCompositionCount.

MozReview-Commit-ID: DEhzYcK1zcW

--HG--
extra : rebase_source : a47891b1d620bbe4e380e73134ec6da5d21f4ea9
2017-06-10 02:42:16 +09:00
Tom Tromey 5f8f360823 Bug 1060419 - make log_print use Printf.h, r=froydnj
MozReview-Commit-ID: BIZ1GQEZ1vs

--HG--
extra : rebase_source : 2f1f0aa12493c44f352d9a7e8683e7bb72d2d75b
2016-12-15 20:16:31 -07:00
Masayuki Nakano 141de4c2d1 Bug 1304620 part.5 ContentCacheInParent should store the latest composition start offset with mCompositionStartInChild r=m_kato
When ContentCacheInParent receives eCompositionStart, it temporarily sets mCompositionStart to selection start offset.  However, if there is a composition in the remote process, the selection start is caret position in the composition string.  Therefore, it's not useful information.  Instead, the composition start offset should be used because around there are a lot of information.

For that, ContentCacheInParent should always store compostion start offset in the remote process with mCompositionStartInChild even if mWidgetHasComposition is false.  And when it receives eCompositionStart, mCompositionStart should be set to mCompositionStartInChild.

MozReview-Commit-ID: DksPNEsi6Ec

--HG--
extra : rebase_source : bcf2946273d24a4c37c33fa18a321660115e3fb6
2016-10-12 21:52:01 +09:00
Masayuki Nakano 610b4b4a2e Bug 1304620 part.4 ContentCacheInParent::mCompositionStart should be set to better value for mWidgetHasComposition state r=m_kato
ContentCacheInParent::mCompositionStart was set to ContentCacheInChild::mCompositionStart without any check.  However, that's clearly wrong approach.  For example, when the remote process handles some composition events after eCompositionCommit(AsIs) in the parent process, mCompositionStart is valid offset even after mWidgetHasComposition is set to false.  Similarly, even after parent process sends eCompositionStart, the remote process may send invalid offset for mCompositionStart due to no composition in it.

For solving this issue, ContentCacheInParent should check mWidgetHasComposition.

If it's true and coming offset is valid, let's use it (even if mPendingCompositionCount is 2 or bigger since widget shouldn't use WidgetQueryContentEvent when there are some pending events).

If the coming offset is invalid but mWidgetHasComposition is false, let's use selection start instead because HandleQueryContentEvent() can work around selection start offset only.

Otherwise, i.e., mWidgetHasComposition is false, we should always set mCompositionStart to invalid offset.

MozReview-Commit-ID: IONU0Cbhpil

--HG--
extra : rebase_source : 05ae9eb0e7a0bb63b65be7a54103eb798274c8ff
2016-10-12 22:05:09 +09:00
Masayuki Nakano 7a5e29e854 Bug 1304620 part.3 The start offset of TextComposition instance in the parent process shouldn't be updated with older composition in the remote process r=m_kato
When ContentCacheInParent receives content information from the remote process, it notifies TextComposition of the latest composition start offset in the remote process.  However, the information may be older composition's, i.e., the composition was already committed in the process but is still being handled by the remote process.  TextComposition shouldn't work with such obsolete information.

Note that TextComposition instance is created and destroyed when WidgetCompostionEvent is handled by IMEStateManager.  Then, TextComposition instance guarantees that all following composition events for a composition are sent to same EventTarget (including TabParent).  So, TextComposition is always synced with a composition in widget.

MozReview-Commit-ID: 78NuvpE2rPx

--HG--
extra : rebase_source : 3ffbf2513750f4b940bfedd19a8b191f28611115
2016-10-12 22:03:16 +09:00
Masayuki Nakano 06d6d7a752 Bug 1304620 part.2 ContentCacheInParent should manage if there is pending composition in the remote process r=m_kato
If the remote process is busy or user restarts composition too quickly, there could be 2 or more compositions in ContentCache.  For managing such case, ContentCacheInParent should manage the pending composition count which is increased at dispatching eCompositionStart event to the remote process and decreased at receiving eCompositionCommit(AsIs) event from the remote process.

MozReview-Commit-ID: KbTsK20NEZD

--HG--
extra : rebase_source : 428b14646ccde190b446b5c820e0e84866a855f2
2016-10-12 17:09:02 +09:00
Masayuki Nakano e9727adbec Bug 1304620 part.1 Rename ContentCacheInParent::mIsComposing to mWidgetHasComposition r=m_kato
For making the meaning of ContentCacheInParent::mIsComposing clearer, let's rename it to mWidgetHasComposition.  It becomes true when the parent process sends eCompositionStart to the remote process and false when the parent process sends eCompositionCommit(AsIs).  So, it represents if the widget (i.e., the native IME handler in the chrome process) has composition.

MozReview-Commit-ID: 5k05IXMgJxw

--HG--
extra : rebase_source : 69be70f22fb9b9dd6125ce390026b0740bd6de8f
2016-10-12 16:42:28 +09:00
Nicholas Nethercote 34dcc7b852 Bug 1299384 - Use MOZ_MUST_USE with NS_warn_if_impl(). r=erahm.
This change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.

In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.

> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));

In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.

> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");

This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
  be true" sense used in assertions.

A common variation on the side-effect-free case is the following.

> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");

--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
2016-09-02 17:12:24 +10:00
Masayuki Nakano e48dbcc546 Bug 1291082 part.3 ContentCache::TextRectArray::GetUnionRectAsFarAsPossible() should avoid crash by itself r=m_kato
ContentCache::TextRectArray::GetUnionRectAsFarAsPossible() should avoid crash by itself even if it's caller's bug. This makes parent process more stable, that is what one of the purpose of e10s is.

MozReview-Commit-ID: qKAfvm6eZw
2016-08-17 00:15:44 +09:00
Masayuki Nakano 598dee428f Bug 1257446 part.1 ContentCache should store previous character of selection r=m_kato
This patch makes ContentCache store previous character's rect of selection anchor and selection focus because if caret is at end of a line, IME may query the last character of the line.

MozReview-Commit-ID: 5X1K8KtrYfl

--HG--
extra : rebase_source : 403e4c993b48a832d50b4f44738c5b5c6d5ce085
2016-07-22 20:47:51 +09:00
Masayuki Nakano d5bace6236 Bug 1257446 part.0 ContentCacheInParent::HandleQueryContentEvent() should log the cause of failure when it makes the event's input offset absolute r=m_kato
MozReview-Commit-ID: JVGHPQ5gC3G

--HG--
extra : rebase_source : 77d541f21b78b4270c109f2a4e9db59c19129e03
2016-07-12 17:44:44 +09:00
Masayuki Nakano ddf5f8fb25 Bug 1291082 ContentCacheInParent::GetUnionTextRects() shouldn't use mTextRectArray when it's empty r=m_kato
This must be able to reproduce with some IMEs which creates 0 length composition string.  In such case, mTextRectArray isn't available, but mTextRectArray.GetUnionRectAsFarAsPossible() always assumes that it's valid and has at least one rect.  Therefore, it can meet this crash.

Therefore, this patch makes that ContentCacheInParent::GetUnionTextRects() not use mTextRectArray when it's not valid nor doesn't have rects.

MozReview-Commit-ID: 2yLMo4lxI3Z

--HG--
extra : rebase_source : 3ef3f2c6ba6473fd3eefbd5c909c1ef6c51c76af
2016-08-02 12:02:14 +09:00
Masayuki Nakano 1373da05f3 Bug 1286489 TSFTextStore.cpp and ContentCache.cpp shouldn't put \n, \r and \t to log file directly r=m_kato
MozReview-Commit-ID: 630lZINQteb

--HG--
extra : rebase_source : 9841cfdb199d1a7964d1ad4516d9862f498b0f39
2016-07-13 18:16:04 +09:00
Masayuki Nakano 3bba9b37d5 Bug 1284422 part.9 Remove "ContentCache(InParent|InChild)?: " from log of ContentCache.cpp since the classes are not in same process under current design r=m_kato
MozReview-Commit-ID: LwDBBwfkZKx

--HG--
extra : rebase_source : 1944e40a55bcc3de83fa4a309b0090ec87b766f9
2016-07-05 18:56:18 +09:00
Makoto Kato c603b26d13 Bug 1203871 - Part 5. Use mozilla::Move for rect array. r=masayuki
To optimize copy of text rect array, we should use mozilla::Move.  Also, after using it, we should mark is invalid result into SetEventResult

MozReview-Commit-ID: HH9H7DhK12

--HG--
extra : rebase_source : 4e02ece73583306c386597bc92e203fa147cfcbc
extra : histedit_source : 726621cdaf262b9d173ae19d505575f10563cc36
2016-06-14 16:52:31 +01:00
Makoto Kato 8e42cbc802 Bug 1203871 - Part 3. Use eQueryTextRectArray on ContentCache for e10s. r=masayuki
Use new event to update cotent process's cache.

MozReview-Commit-ID: CexTXW4knMQ

--HG--
extra : rebase_source : 525a8b0a1fe6ef533e06f76ac5156e264b158c70
extra : histedit_source : 2a8c46a64eb5c6a7a05adc28917422c488b2b1c4
2016-03-14 16:03:31 +09:00
Masayuki Nakano e195616e12 Bug 1280182 ContentCache should return non-empty rect as far as possible if query content event is relative to insertion point r=m_kato
ContentCache may store composition string's rects which are inserted by one or more older composition event.  Even in such case, native IME, especially TIP of TSF, expects non-empty rects.

Therefore, if native IME handler uses "insertion point relative query", ContentCache should return non-empty rect as far as possible.  For example, even if query offset or range is not in its rect array of composition string, ContentCache should adjust the offset into the stored range.

MozReview-Commit-ID: 7hcIqxOWFk2

--HG--
extra : rebase_source : 8b1572e01cc56e5596ffba4eac0f7d5818b85a89
2016-06-22 14:16:59 +09:00
Masayuki Nakano 02e3dc2d1b Bug 1275528 part.3 Support selection relative WidgetQueryContentEvent in e10s mode r=m_kato
In e10s mode and during focus is in a remote process, ContentCache handles WidgetQueryContentEvent instead of ContentEventHandler.  Therefore, for supporting selection relative WidgetQueryContentEvent in e10s mode, we need to support it in ContentCache too.

MozReview-Commit-ID: L5d5ilmpetG

--HG--
extra : rebase_source : 46d646677ac0a5803398d18efbfd667bc3bf0c17
2016-06-14 20:54:54 +09:00
Masayuki Nakano f8210c2a4e Bug 1275918 part.2 Update TextComposition::mCompositionStartOffset when it's modified in the remote process r=m_kato
MozReview-Commit-ID: H1SJTWWav6G

--HG--
extra : rebase_source : 6d7d79e7d4d719b720bed4f4c20196079fb8b5fb
2016-06-14 21:06:34 +09:00
Masayuki Nakano 50a7dd324b Bug 1275918 part.1 ContentCache should retrieve the latest composition start offset from TextComposition and send it to the parent process r=m_kato
MozReview-Commit-ID: EoMZtqoMue3

--HG--
extra : rebase_source : c4a60248e765cddeccd1be3607f80358a99dda34
2016-06-13 18:17:58 +09:00