`nsRange` registers mutation observers to adjust the range when content
changes. However, there are some cases where we adjust the start and/or
end offsets but don't notify selection listeners (i.e. we don't call
`nsRange::DoSetRange` to set the new range points, contrary to what the
comment above `nsRange::DoSetRange` says). This patch makes us call
`nsRange::DoSetRange` in those cases. The patch adds a testcase in
test_selectevents.html, and changes a few unexpected-pass cases in
test_composition_text_querycontent.xul that this patch fixed.
MozReview-Commit-ID: 73D8RYMS3MS
--HG--
extra : rebase_source : da0cc3073e4b8ad23c6f6eab42da5aa8b269cae9
When the start node is a non-container node (i.e. <br>), and the start
offset is 0, we should not include a newline character for the node. For
example, for this range,
> <br/>hello
> \___/
the start node/offset is (<br/>, 0) and end node/offset is ("hello", 1).
The calculated range offset should be 0, and the range length should be
2: 1 for the <br/> newline character plus 1 for "h".
The patch also ensures this behavior for pre-mode nsContentIterator, for
both start and end node adjustments. For start nodes, we include any
non-container nodes with offset 0 in the range. For end node, we exclude
any non-container nodes with offset 0 from the range.
MozReview-Commit-ID: Lt2tCLbapq7
--HG--
extra : rebase_source : 7d86b6cf04581f1cd71fa85f8c8586541b3a84e9
The fix for bug 1373079 neglected the detail of OpenThemeData
that it can return null if no match is found for the specified
class name. The set of matching class data sections varies with
the default and the classic theme, and the classic theme doesn't
have matches for a few of the values that we try to get. This
causes us to pass a null theme to subsequent functions, which of
course breaks the layout.
MozReview-Commit-ID: 5LaR0qZlOzd
--HG--
extra : rebase_source : ba97163e5dfdd7127d550be54524e93f12195ffb
Ideally, we definitely want APZ in remote popup browsers for the sake of
responsiveness. However, there are currently some serious painting and
checkerboarding issues that make APZ popups unsuitable for release
populations.
Once these issues are addressed, we should enable the preference by default.
But given the relative lack of testing, and the issues we've seen so far, we
should keep the preference so that we can disable it with a hotfix if further
issues arise.
MozReview-Commit-ID: GOZRdsmLNZR
--HG--
extra : rebase_source : ce0f2ca029d951a9c65ec1482e065b6695793133
SetParent removes the widget from the old parent widget and then sets its new one. We were incorrectly using the new parent widget when we needed the old one.
1. Pause the Exoplayer when navigating to another page and resume playback when navigating back.
2. Fix the OOM issue.
MozReview-Commit-ID: 5UGmBzpObsb
--HG--
extra : rebase_source : f8f268612687669e1b31881465600b02b3531c55
This avoids a fatal assertion for some key events when focus isn't on a text
input.
MozReview-Commit-ID: Hqr6LNW61Kn
--HG--
extra : rebase_source : adc954fc355044c91dc34e9e689a745da95e78c9
Most of the names passed to nsIStringBundle::{Get,Format}StringFromUTF8Name
have one of the two following forms:
- a 16-bit C string literal, which is then converted to an 8-bit string in
order for the lookup to occur;
- an 8-bit C string literal converted to a 16-bit string, which is then
converted back to an 8-bit string in order for the lookup to occur.
This patch introduces and uses alternative methods that can take an 8-bit C
string literal, which requires changing some signatures in other methods and
functions. It replaces all C++ uses of the old methods.
The patch also changes the existing {Get,Format}StringFromName() methods so
they take an AUTF8String argument for the name instead of a wstring, because
that's nicer for JS code.
Even though there is a method for C++ code and a different one for JS code,
|binaryname| is used so that the existing method names can be used for the
common case in both languages.
The change reduces the number of NS_ConvertUTF8toUTF16 and
NS_ConvertUTF16toUTF8 conversions while running Speedometer v2 from ~270,000 to
~160,000. (Most of these conversions involved the string
"deprecatedReferrerDirective" in nsCSPParser.cpp.)
--HG--
extra : rebase_source : 3bee57a501035f76a81230d95186f8c3f460ff8e
Defining the default draw target avoids the previous mix of cairo
and d2d layers, which would trigger an assertion when capturing
a page with the widget layers.
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
Andrew Osmond
Wes Kocher
Jim Chen
Ryan Hunt
Dão Gottwald
Benjamin Smedberg
Haik Aftandilian
Doug Thayer
Kris Maglione
David Parks
David Anderson
Milan Sreckovic
James Cheng
Blake Kaplan
Nicholas Nethercote
Brendan Dahl
Farmer Tseng
Carsten "Tomcat" Book
Josh Aas
Masayuki Nakano
Wei-Cheng Pan
Kartikaya Gupta
Eugen Sawin
Botond Ballo
Erica Wright