ATOK 2016 and newer may show candidate window at odd position temporarily
when user converts a word quickly (e.g., keep pressing space bar).
For avoiding this flicker, we should keep hacking GetTextExt() result for
ATOK 2016 and later even after Windows fixes TS_E_NOLAYOUT bug.
We should get feedback from each CJKT testers at least one cycle after Win10
RS5 is released. Until then, we should not stop hacking GetTextExt() result
in late Beta nor Release builds.
Microsoft Pinyin and Microsoft Wubi (Simplified Chinese TIPs) work better on
Windows 10 Build 17643 or later (i.e., TS_E_NOLAYOUT bug is fixed). However,
they sometimes do not show candidate window, perhaps, the reason is something
stateful bug in them. Therefore, we still need to hack the result of
GetTextExt() until they fix this bug.
Currently, TSFTextStore::MaybeHackNoErrorLayoutBugs() checks pref to enable
hack first, then, check if active TIP is the target of pref. This was intended
to save comparison cost of GUIDs. However, we don't need to worry about the
cost and that was not makes sense since all prefs are true by default.
So, this patch makes the big if-elseif blocks with switch-case with
TSFStaticSink::ActiveTIP(). Then, each case block starts to check if
- if Windows still TS_E_NOLAYOUT bug of GetTextExt().
- if corresponding pref is true.
Note that this duplicates some code for making the code look easier.
E.g., eMicrosoftOfficeIME2010ForJapanese case is duplicated from
the eMicrosoftIMEForJapanese case. eMicrosoftPinyin and eMicrosoftWubi case
is duplicated from the eMicrosoftChangJie and eMicrosoftQuick case.
As we know, GUID comparison is not cheap if it's required a lot. Unfortunately,
we need to check it more in TSFTextStore::MaybeHackNoErrorLayoutBugs() and
it's called a lot. So, even though mapping from GUID to TIP is expensive,
we should do it only once. Note that most users won't change IME during a
browser session, so, running this expensive method once must be reasonable.
On the other hand, we don't allow to make damage to start up performance,
we should avoid to do it as far as possible. For example, when we need to
check if active TIP is a specific TIP, we should check current language.
This patch was written entirely by the following script:
#!/bin/bash
if [ ! -d "./.hg" ]
then
echo "Not in a source tree." 1>&2
exit 1
fi
find . -regex '.*\(ref\|crash\)test.*\.list' | while read FILENAME
do
echo "Processing ${FILENAME}."
# The following has four substitutions:
# * The first one replaces the *first* argument to fuzzy() when it doesn't
# have a - in it, by replacing it with an explicit 0-N range.
# * The second one does the same for the *second* argument to fuzzy().
# * The third does the same for the *second* argument to fuzzy-if().
# * The fourth does the same for the *third* argument to fuzzy-if().
#
# Note that this is using perl rather than sed because perl doesn't
# support non-greedy matching, which is needed for the first argument to
# fuzzy-if.
perl -pi -e 's/(fuzzy\()([^ ,()-]*)(,[^ ,()]*\))/${1}0-${2}${3}/g;s/(fuzzy\([^ ,()]*,)([^ ,()-]*)(\))/${1}0-${2}${3}/g;s/(fuzzy-if\([^ ]*?,)([^ ,()-]*)(,[^ ,()]*\))/${1}0-${2}${3}/g;s/(fuzzy-if\([^ ]*?,[^ ,()]*,)([^ ,()-]*)(\))/${1}0-${2}${3}/g' "${FILENAME}"
done
Differential Revision: https://phabricator.services.mozilla.com/D2974
--HG--
extra : moz-landing-system : lando
It doesn't appear these IDL files have had interfaces in them since
before the Netscape import, and were mostly just hanging around
because they contained some IDs needed elsewhere. Move the IDs
somewhere more appropriate and remove files.
MozReview-Commit-ID: AINtTerqHu1
Differential Revision: https://phabricator.services.mozilla.com/D2688
--HG--
extra : moz-landing-system : lando
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
At Windows 10 build 17643, Microsoft fixed the bug of TSF which returns E_FAIL
to TIP when GetTextExt() returns TS_E_NOLAYOUT. With this fix, most TIPs do
not have any problems even if we return TS_E_NOLAYOUT. So, unless active
TIP still needs the hack, the method can skip the hack if running on build
17643 or later.
Note that we still need to support Japanist 10 and Microsoft Office IME 2010.
It confirmed that Japanist 10 has a bug of handling TS_E_NOLAYOUT. On the
other hand, we have not tested Microsoft Office IME 2010 since it's installable
only into Win7 or Win8 and needs to upgrade it to Win10 for testing, but I
do not have the license. After the fix comes into release channel, I'll be
able to test it though (my main environment is Win10 and it was installed
before upgraded). So, we need to be back after Microsoft releases the fix.
MozReview-Commit-ID: 2BzkDvHTKyI
--HG--
extra : rebase_source : ee0261c83c5a1ab7b2aa2a8f476f0c6634e2cf34
The block in TSFTextStore::GetTextExt() which decides whether we should return
S_OK with unmodified character rectangle rather than TS_E_NOLAYOUT is too big.
Additionally, we need to add new condition to check Windows 10's version there.
That makes the large block more complicated. So, we should split the block
off from TSFTextStore::GetTextExt(). Then, we can use early-return-style to
reduce the deep indentations.
MozReview-Commit-ID: J2BJMB1QD0T
--HG--
extra : rebase_source : 3c86b5ed3a83fda1045a6453250e784f11419b97
The '-moz-menulist-button' value currently behavies identically to the
'menulist-button' value. This is not implemented as an alias because later
patches in this patch series will change the behavior of our pre-existing
'menulist-button' value to more closely match what Chrome does.
This copies over the early-exit conditions from MaybeDrawTitlebar which
is the non-WR codepath where this gets drawn. In particular, the
!mIsCoveringTitlebar clause is true when the titlebar is enabled.
MozReview-Commit-ID: 6B7vKYuyrRP
--HG--
extra : rebase_source : b8f73d2c4f9e582bdb018e6aa121e92d54c60334
The '-moz-menulist-button' value currently behavies identically to the
'menulist-button' value. This is not implemented as an alias because later
patches in this patch series will change the behavior of our pre-existing
'menulist-button' value to more closely match what Chrome does.
--HG--
extra : rebase_source : b66bf6427db5be2eb12f4e0aa36d22a4da46555a
This is generally helpful. I'm also seeing much less than 50% of the
wrQualified people in the study getting webrender so this could help
determine why.
MozReview-Commit-ID: 2neTFBytzPz
--HG--
extra : rebase_source : 97b1b1fe80f1a2c574141eaef8ad23499699fb82
The constructor of WidgetCommandEvent takes 2 nsAtom pointers. One is for
specifying event type, the other is for specifying the command. The
difference of these arguments are pretty unclear for other developers and
the former argument is always nsGkAtoms::onAppCommand unless nullptr in
C++ code. So, we can hide the former argument.
Then, we should create another constructor for creating empty command event
from constructor of dom::CommandEvent.
Differential Revision: https://phabricator.services.mozilla.com/D2506
--HG--
extra : moz-landing-system : lando
When resuming composition in a new GeckoView, we wait for the first
paint signal in order to uncover the SurfaceView. This patch makes sure
that we always send the first paint signal.
MozReview-Commit-ID: EZeOR80d8HY
--HG--
extra : rebase_source : f82ab94ef87e5b0651f368918e8cd8a97469c68e
Make sure the window XID is propagated to X server, we can fail otherwise
in GPU process.
MozReview-Commit-ID: BMkLvhs4vRt
--HG--
extra : rebase_source : 34269cbf7e088fd15c090f3abc8ee2d46da307c4
IME (e.g., fcitx) may refer selection colors of widget under window which
is associated with IM context to support any colored widget. So, IME
expects good selection colors which have sufficient contrast between
foreground and background, and also selection background color and
widget background color like GtkTextView. However, some desktop themes
set our widget to different selection colors from GtkTextView which may
be unreadable.
nsTextFrame (which paints composition string) expects that composition
string colors coming from IME are sufficiently readable and background
color of composition string and background color of our editor's default
style (coming from LookAndFeel) have sufficient contrast because
nsTextFrame assmes that composition string colors coming from IME are
decided for the default style.
Therefore, this patch creates SelectionStyleProvider which overwrites
selection style of our widget with selection style of GtkTextView so
that IME can refer selection colors of GtkTextView via our widget.
MozReview-Commit-ID: 5vdcSgoEYv0
--HG--
extra : rebase_source : edf375ac393a72d3e44839a76d5c44b6db12dc63
This makes sure things work under e10s, but also results
in simplified code since we weren't actually using the
features of nsScreenManagerAndroid any more.
MozReview-Commit-ID: 1zghxZuLqr3
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
