The requesting principal is now required for saving content through
nsIWebBrowserPersist, and so drag sessions on macOS need to provide one, just
like drag sessions on Windows already do (see bug 664717).
Differential Revision: https://phabricator.services.mozilla.com/D4673
--HG--
extra : moz-landing-system : lando
The fix in bug 1418793 accidentally removed the onCloseWindow call, which
meant we were setting `.enabled` on taskbar window objects whose windows
were already dead, which was causing crashes.
I've reverted the removal, and also added some nullchecking, because the
C++ component shouldn't make it this easy for consumers to cause crashes.
Differential Revision: https://phabricator.services.mozilla.com/D4559
--HG--
extra : moz-landing-system : lando
This patch removes the 'ScreenOrientationInternal' type from
dom/base/ScreenOrientation.h and moves it into the
HalScreenConfiguration.h header, renaming it simply to 'ScreenOrientation'
in the process. This has several knock-off effects:
- It allows files that needed ScreenOrientationInternal to include a much
smaller header than before
- It greatly reduces the number of headers pulled in when including Hal.h
- It clarifies the role of the type. The 'Internal' part in the name had
nothing to do with it being part of the implementation. The type was public
and called that way only to avoid clashing with the 'ScreenOrientation'
class. Since we moved it into a different namespace it can be renamed
safely.
- It allows a file that was manually re-declaring 'ScreenConfigurationInternal'
type to use the original one
- Finally this fixes a few files which were missing headers they actually
required but that would still build because unified compilation put them into
units that already had those headers thanks to ScreenConfiguration.h
Differential Revision: https://phabricator.services.mozilla.com/D4458
--HG--
extra : moz-landing-system : lando
When building with the NDK clang, which is the easiest way of building locally,
NDK r17 doesn't work for ARM builds because of a broken clang, and while the
NDK r18-beta fixes that problem, for some people it causes a different set of
issues.
Since NDK r15c doesn't have the ndk-version.h headers, switch to a different
way of bridging the differences that allows people to continue building with
r15c locally.
Differential Revision: https://phabricator.services.mozilla.com/D4471
--HG--
extra : moz-landing-system : lando
When any scrollbar color is specified, or scrollbar-width is thin, we
switch to use the fallback rendering.
The change to xulscrollbars.css is for ensuring that the scrollbar is
displayed for scrollbar-width: thin when there is no scrollbar color
specified. It wouldn't affect cases where -moz-appearance takes effect.
This also changes the fallback width of the scrollbars. Since the two
widths was picked rather randomly, I think it should be fine to change
it if a value looks better than the old one, especially on Linux which
is the main usecase for this fallback rendering.
Differential Revision: https://phabricator.services.mozilla.com/D3952
--HG--
extra : moz-landing-system : lando
There are surprisingly many of them.
(Plus a couple of unnecessary checks after `new` calls that were nearby.)
--HG--
extra : rebase_source : 47b6d5d7c5c99b1b50b396daf7a3b67abfd74fc1
This allows JS callers to automatically get the correct types during
interation, without having to explicitly specify them.
Differential Revision: https://phabricator.services.mozilla.com/D3728
--HG--
extra : rebase_source : b708f382d8ea571d199c669bfed5b5a7ca9ffac4
extra : histedit_source : 7df6feb82088c8a5ca45dc28fe4d2b852c177fee
In order to allow JS callers to use nsISimpleEnumerator instances with the JS
iteration protocol, we'll need to additional methods to every instance. Since
we currently have a large number of unrelated implementations, it would be
best if they could share the same implementation for the JS portion of the
protocol.
This patch adds a stub nsSimpleEnumerator base class, and updates all existing
implementations to inherit from it. A follow-up will add a new base interface
to this class, and implement the additional functionality required for JS
iteration.
Differential Revision: https://phabricator.services.mozilla.com/D3725
--HG--
extra : rebase_source : ad66d7b266856d5a750c772e4710679fab9434b1
extra : histedit_source : a83ebffbf2f0b191ba7de9007f73def6b9a955b8
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.
