Testing for cache differences via assertions on try revealed that
we need to special-case buttons in our cache, since they can have
two different values for aSizeReq. Visual inspection of the code
reveals that this is the only aWidgetType value that has this
problem. I'm not sure how future-proof we want to try to be with
this. If anything else starts varying in this parameter then we
might unwittingly introduce caching problems, but I don't know
how likely that is.
MozReview-Commit-ID: 3kaJ01oJe3
--HG--
extra : rebase_source : 9a9c15f38eee7c59cd73e7fe42a0f581e0adeac5
See commit (1) for more detail about the bug.
This patch caches the expensive parts of GetMinimumWidgetSize,
which are when we call GetDC and ReleaseDC. The exits before this
cached section don't have their results cached partly because
they don't seem to show up in profiles, and partly because we
don't necessarily have a theme part at that point, which means
we would need to have a more complicated caching scheme directly
involving the aWidgetType.
MozReview-Commit-ID: 886N4tTHVVk
--HG--
extra : rebase_source : 31c4750088c26d140813419c63277a330472b84e
Both GetWidgetBorder and GetMinimumWidgetSize are showing up
in some profiles (see bug for more details.) This is the first
patch in a series of patches which cache the results of these
functions.
Because aWidgetType can map to multiple theme parts, in order to
cover as much as possible with our cache we decided to cache
based off of the theme class and the theme part, which are derived
from the aWidgetType and misc. other state. (Assumption: the
widget border and minimum widget size should not changed based on
the theme "state" (the value that accompanies the "part".))
The total cache size for these, if we use plain arrays, is 18KB.
We could reduce this by some amount by using a sparse dynamically
sized cache or by just using aWidgetType and discarding the
overloaded values, which are few. I don't have a great intuition
for how much we care about saving a few KB, or how much time this
could cause us to lose on L1 and L2 cache misses. Accordingly it
might be more optimal to go with something else, and I am open to
criticism/suggestions.
MozReview-Commit-ID: 4LG9BnaRG7l
--HG--
extra : rebase_source : 6d3ecf11e02a863f5528fb3ec2417eb1a246574c
Starting from 52, NativeKey::HandleCharMessage() ignores all control characters. However, some keyboard layout utilities may send WM_CHAR message whose wParam is '\r' for emulating pressing Enter key. For supporting such utilities, we should dispatch Enter keypress event when HandleCharMessage() receives such event.
Note that this patch does NOT support a pair of WM_KEYDOWN and WM_CHAR whose wParam is '\r' but the WM_KEYDOWN isn't VK_RETURN. If there is such case, we need to support it too. However, it needs a lot of code changes. So, we shouldn't support it until such bug is filed actually.
MozReview-Commit-ID: CWyvBtLmXgg
--HG--
extra : rebase_source : 6e9b27dc2fb9eb75626cdd5ab339d348a7be3040
Also propagate the removal outwards to remove other unused functions.
MozReview-Commit-ID: 9aqcbBA0Mf1
--HG--
extra : rebase_source : 9ce961ee0129f81e5c8d8a8df1a27ee6ff8012c7
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
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
Currently, IMEStateManager always sets input context as set by current process even when it needs to adjust IME state when a tab parent for current focused IME process is removed. Then, input context for the widget is marked as for main process but the widget still have IME focus of a remote process.
For fixing this mismatch, IMEStateManager should set ORIGIN_CONTENT even when the tab parent is being destroyed.
MozReview-Commit-ID: C10YOAtkET4
--HG--
extra : source : 9430d123b19e0ac551c6048bb044fcfa22d13e45
One thing to note here is that the Scale function on gfxRect has a
different implementation than that in gfx::Rect which is replacing it.
The former just scales the width/height directly whereas the latter
scales the XMost/YMost and recomputes the width/height.
MozReview-Commit-ID: 5FImdIaNfC3
--HG--
extra : rebase_source : 98662d2a52ff9652ec60b066641a07c6d5ee8e08
Most of this patch is updating a few places that use gfxMatrix to use
the equivalent-but-differently-named functions on MatrixDouble:
- Translate/Rotate/Scale get turned into PreTranslate/PreRotate/PreScale
- Transform(Point) gets turned into TransformPoint(Point)
- gfxMatrix::TransformBounds(gfxRect) gets turned into
gfxRect::TransformBoundsBy(gfxMatrix).
- gfxMatrix::Transform(gfxRect) gets turned into
gfxRect::TransformBy(gfxMatrix).
The last two functions are added in this patch as convenience wrappers
to gfxRect instead of Matrix.h because we don't want Matrix.h to "know"
about gfxRect (to avoid adding gecko dependencies on Moz2D). Once we
turn gfxRect into a typedef for RectDouble these will be eliminated
anyway.
MozReview-Commit-ID: BnOjHzmOSKn
--HG--
extra : rebase_source : cf1692d1f0d44a4b05d684a66678739181a426d5
Currently, it's not been managed yet that whether an event is posted to at least one remote process. So, for managing the state, BaseEventFlags should have a new bool flag and WidgetEvent and BaseEventFlags should have helper methods for it.
Additionally, this fixes a bug of nsGUIEventIPC.h. In a lot of ParamTraits, static_cast<Foo> is used for using base class's ParamTraits. However, it causes creating temporary instance with copy constructor. Therefore, WidgetEvent::MarkAsPostedToRemoteProcess() call in ParamTraits<mozilla::WidgetEvent>::Write() didn't work as expected.
MozReview-Commit-ID: DdafsbVfrya
--HG--
extra : rebase_source : 94205f3a7b36455c3c9f607c35866be033e627c1
Currently, we have 2 bool flags (and optional 2 bool flags with related purpose) for managing propagation state between parent process and remote process. However, it's really complicated. Actually, setting these flags and referring the flags is usually follow explanation.
So, for making simpler, WidgetEvent and BaseEventFlags should have some utility methods for making them as self documented code.
This patch moves WidgetKeyboardEvent::mIsReserved to BaseEventFlags::mIsReservedByChrome. That allows us to manage the cross process event propagation state in same place.
MozReview-Commit-ID: IXEDQJ4GpAZ
--HG--
extra : rebase_source : 5b63ac4f1d15e40e8bfc88423e336de28caa8ab6
WidgetKeyboardEvent::mInputMethodAppState was used by B2G for managing keyboard event propagation state between chrome process and IME process. Therefore, we can remove it now.
MozReview-Commit-ID: 7BwvzE8VjIR
--HG--
extra : rebase_source : 99e19fee6af0be1de19bd6c23e57e7dbf83a4a9c
This requires:
- Moving the constructors of ProfilerMarkerPayload and its subclasses into the
.h file so they are visible even when ProfilerMarkerPayload.cpp isn't
compiled.
- Similarly, using a macro to make StreamPayload() a crashing no-op when the
profiler isn't enabled. (It is never called in that case.)
--HG--
extra : rebase_source : 7aad2fdb1bd4e49782024dba6664e8f992771520
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
1. Convert PDF to EMF via PDFViaEMFPrintHelper.
2. Replay EMF on printer DC.
MozReview-Commit-ID: 8YTcaZ2Y1rO
--HG--
extra : rebase_source : 7b5e718c7fe5dbeee13bbd7a0c958cd285d0833f
1.PDfium would be built into the xul (bug 1368948) so PDFiumEngineShim could
call functions directly. However, I still keep loading dynamic library for
debugging purpose. Create a new preference for storing the library file path.
2.Remove redundant define and typedef which are written in PDFium head file.
3.Include an appropriate head file from PDFium.
4.Remove non-used PDFium APIs.
5.Use the singleton pattern to retrieve the instance of PDFiumEngineShim.
6.Don't destroy the library inside PDFiumEngineShim::CloseDocument because the
library has to deal with multi-document.
MozReview-Commit-ID: 97ZBFp1qU8V
--HG--
extra : rebase_source : a60ee37906a94788e0baabbb95bd8848eca096af
