We send query text events when flushing IME changes, and sometimes these
events make Gecko commit more pending changes. In that case, we should
try flushing again, so we pick up the new changes.
This patch also makes the process of flushing text changes
transactional, so that if we have to bail due to more pending changes,
nothing will be committed.
Specifically, the PaintWindow() functions in the following classes:
- nsIWidgetListener, and its subclasses nsView and nsWebBrowser;
- nsChildView;
- nsWindow (the one in widget/uikit/);
- nsViewManager.
--HG--
extra : rebase_source : e5e0af18c57f1c44995832b403edc7eee939dc31
In this process, TransformTo() and UntransformTo() are renamed TransformedBy()
and UntransformBy() so calls to them continue to read sensibly.
--HG--
extra : rebase_source : a2a4b36514cc54533757c075fcf2c53ab3020939
extra : source : 826da3dc12baeb84b32be50f4b2c0591ca73ab37
Call sites (all in APZ and related code) were modified accordingly. Some of
these modifications involved changing some matrices stored in APZ to be typed.
--HG--
extra : rebase_source : 6f1cf33a5550987097fcd386c77765d046f5ec34
extra : source : 8f66bdc8e6e86f482a06b9c7a160740026cf24b4
Matrix4x4 remains a typedef for Matrix4x4Typed<UnknownUnits, UnknownUnits>.
No client code needed changing, except for forward-declarations of Matrix4x4
as a class (since it's now a typedef).
--HG--
extra : rebase_source : ecd9470b9defcc55cfb9e7dbd26e928a6219c3e5
extra : source : 0fc99b5490830953f37a4d8769e42dad2d10bc6e
When the queue only contains compositor events, a compositor event
should go to the back of the queue to maintain order.
--HG--
extra : commitid : I7bHvJCe68o
I think the intent of this call is not to copy the flavor data passed
in, but to simply convert it to a friendlier nsCString container for
serializing to an IPC message. Since we won't be retaining references
to the passed-in strings after this function returns, we can make the
elements of our temporary array actually dependent strings, rather than
creating temporary dependent strings that would need to be copied into
the array.
When people write:
array.AppendElement(nsDependentString(...));
(resp. nsDependentCString), it's not clear whether they expect the newly
constructed dependent string to live in the array, or whether they're
just making a nsString-like holder whose contents can be freely copied
into the array's newly-created nsString. Sometimes the latter is what
you prefer, and sometimes the former. In all cases, however, the latter
behavior is what you get.
Let's try to make that behavior more explicit by pre-constructing
nsString elements and then using Assign to show that copying is taking
place. This patch involves no functional change in behavior (it ought
to be epsilon faster due to using AppendElements, rather than repeatedly
calling AppendElement).
This requires adding a new overloading of LayoutDevicePixel::ToAppUnits and a
new PixelCastJustification: LayoutDeviceIsParentLayerForRCDRSF.
--HG--
extra : rebase_source : b6d044619918818815b40c1173aa4e0551db28a1
RestrictedProfiles: The name of the class can be confusing because it handles
guest profiles and restricted profiles. We might even query it from a normal
profile.
--HG--
rename : mobile/android/base/RestrictedProfiles.java => mobile/android/base/Restrictions.java
extra : commitid : BtjvH8aWSlk
extra : rebase_source : 262c9537d7e93658ceea6f94c8481a393ddd3072
