Getting a working local build with the system clang might be tricky, while
building with NDK r17 clang is broken (bug 1484723).
NDK r18-beta1 fixes this, but also made all jvalue* method parameters in jni.h
const,so in order to support building with it we need to adjust our relevant
function types, too.
Differential Revision: https://phabricator.services.mozilla.com/D3832
--HG--
extra : moz-landing-system : lando
Bug 1411879 introduced kPMDataFormatXMLCompress. However, this parameter caused
the saving print settings problem.
Before investigating this reason, this patch will revert this parameter.
Differential Revision: https://phabricator.services.mozilla.com/D3943
--HG--
extra : moz-landing-system : lando
It also converts nsNativeThemeCocoa::GetParentScrollbarFrame into a
local static function rather than a member function, since it doesn't
seem to be necessary that way.
Differential Revision: https://phabricator.services.mozilla.com/D3737
--HG--
extra : moz-landing-system : lando
Since Windows doesn't provide native thin scrollbar variant, this patch
tries to synthesize one by doing the following:
* force to use custom scrollbar, and
* hide the scrollbar button by giving them zero size, and
* cut the thickness of scrollbar by half.
Half thickness is picked randomly, but it seems to work fine. A third
of the size also looks fine, but maybe a bit harder to drag.
Note: Universal Windows Platform apps seem to have an overlay style of
scrollbar by default, but I cannot find any Windows API to render that,
so that may be a builtin component of UWP. We may want to do that at
some point, but this is probably good enough for now.
MozReview-Commit-ID: KfHjy8WdweT
--HG--
extra : rebase_source : 4776fc5e2264c0b9146ca89d40b4e8b952307d0e
So that we can use custom scrollbar for thin scrollbar.
MozReview-Commit-ID: FCHzV5MJbx
--HG--
extra : rebase_source : 4742d2bb1f612ff60890d5c01a4532ee4542624e
The test case in this patch fails without the proper fix in the first patch
in this patch series.
In this patch two new nsIDOMWindowUtils APIs are introduced to change the
system font settins in tests. Currently the APIs work only on GTK+ platform.
Also to work the test case properly we need to open a new XUL window because we
don't propagate font changes into descendant documents yet (bug 1478212).
MozReview-Commit-ID: 4OLxEkEuF8d
--HG--
extra : rebase_source : 683e64f07c4d8820e5499d8c15b90975618559b8
Now nsBaseWidget::NotifyThemeChanged properly notifies to the pres shell.
MozReview-Commit-ID: Kmd68ckHanl
--HG--
extra : rebase_source : 9928f3788f34b05ff91d1d2b11e2cd332f00af76
In these days, it's common to not create a child widget, so if there is
GetXULWindow() check the notifications are not propagated to the proper pres
shell. Even in the case there is a child widget, which means both of the parent
and the child widgets notify to the same pres shell, but NotifySizeMoveDone is
fairly cheap, and the other two notifications (SysColorChanged and ThemeChanged)
are queued and will be processed later together, so it will not be a big deal.
MozReview-Commit-ID: 2t23kVZzXgS
--HG--
extra : rebase_source : 79f8a955a70f19812373e219e2cee29f669a528e
As of bug 1475875, cached screen data is now held by Gecko, so
- we no longer need to cache the screen size (retrieval of which can be
expensive when called en masse, as required e.g. by font inflation) within
GeckoAppShell, and
- we need to trigger a refresh of that data instead when the activity
orientation changes.
MozReview-Commit-ID: JsY6sBCcOih
--HG--
extra : rebase_source : f286f3b01732bd724da3988c4713adb7329a5fae
Correctness improvements:
* UTF errors are handled safely per spec instead of dangerously truncating
strings.
* There are fewer converter implementations.
Performance improvements:
* The old code did exact buffer length math, which meant doing UTF math twice
on each input string (once for length calculation and another time for
conversion). Exact length math is more complicated when handling errors
properly, which the old code didn't do. The new code does UTF math on the
string content only once (when converting) but risks allocating more than
once. There are heuristics in place to lower the probability of
reallocation in cases where the double math avoidance isn't enough of a
saving to absorb an allocation and memcpy.
* Previously, in UTF-16 <-> UTF-8 conversions, an ASCII prefix was optimized
but a single non-ASCII code point pessimized the rest of the string. The
new code tries to get back on the fast ASCII path.
* UTF-16 to Latin1 conversion guarantees less about handling of out-of-range
input to eliminate an operation from the inner loop on x86/x86_64.
* When assigning to a pre-existing string, the new code tries to reuse the
old buffer instead of first releasing the old buffer and then allocating a
new one.
* When reallocating from the new code, the memcpy covers only the data that
is part of the logical length of the old string instead of memcpying the
whole capacity. (For old callers old excess memcpy behavior is preserved
due to bogus callers. See bug 1472113.)
* UTF-8 strings in XPConnect that are in the Latin1 range are passed to
SpiderMonkey as Latin1.
New features:
* Conversion between UTF-8 and Latin1 is added in order to enable faster
future interop between Rust code (or otherwise UTF-8-using code) and text
node and SpiderMonkey code that uses Latin1.
MozReview-Commit-ID: JaJuExfILM9
Since focused+selected tree cells will no longer get an outline, we will start using a different background for the unfocused state.
That background needs to be distinct from Highlight, used on selected and focused items
and also distinct from -moz-appearance: listbox, which is used as the box background.
MozReview-Commit-ID: 7hcnueYlOXR
--HG--
extra : rebase_source : 42bb15e86252d72a3f58831079162d0f4723afc9
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
