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
We move the XPConnect() singleton accessor to nsIXConnect to make it available for consumers outside of XPConnect. Most of the consumers of the singleton accessor just need the nsIXPConnect public interface, except for the IsShuttingDown() member which this patch adds to nsIXPConnect as well.
Differential Revision: https://phabricator.services.mozilla.com/D5151
We move the XPConnect() singleton accessor to nsIXConnect to make it available for consumers outside of XPConnect. Most of the consumers of the singleton accessor just need the nsIXPConnect public interface, except for the IsShuttingDown() member which this patch adds to nsIXPConnect as well.
Differential Revision: https://phabricator.services.mozilla.com/D5151
Implemnt notification backend by Windows Toast API that is from Windows 8+.
Original patch is me and add some features by eoger.
Differential Revision: https://phabricator.services.mozilla.com/D3003
--HG--
extra : rebase_source : 0368f269e9adb2347621500b7c9d62c172a71e39
WriteBitmap will be used for Toast implementation, so it should be moved to
WinUtils.
Differential Revision: https://phabricator.services.mozilla.com/D3002
--HG--
extra : rebase_source : b418288b52e14f62122f56dbc40e771c73fd6414
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
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
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 : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
The patch at bug 1478391 comment 6 changed the way the math in Scrollbarbutton*
worked, which pretty surely caused this.
Restore the original order and math to be the same as before bug 1478391.
MozReview-Commit-ID: CK3iOqeX2NW
Even with this patch, the setting change doesn't affect media queries in sub
frames due to bug 1478212. But the bug is a pre-existing issue, for example
system color settings don't affect contents in sub frames either. So we can
land this patch as it is.
Note that there is no way to write an automation test for this unfortunately.
MozReview-Commit-ID: L2Knhp1IjrU
--HG--
extra : rebase_source : 3487a13d0466b68419e55610c8ce3e384df28e64
This builds on bug 1428676 and introduces StyleAppearance, which replaces the
NS_THEME_* constants.
Really sorry for the size of the patch.
There's a non-trivial change in the gtk theme, which I submitted separately as
bug 1478385.
Differential Revision: https://phabricator.services.mozilla.com/D2361
MozReview-Commit-ID: DiSmMWK7Krp
IsComposited() does not reflect Visual selected by GLContextGLX::FindVisual()
which is used by WebRender which leads to shaped window rendering with WebRender.
IsComposited() is replaced by mHasAlphaVisual variable which is explicitly
set when we have an alpha visual and we don't need to use shape X11 extension.
MozReview-Commit-ID: 1kDLwkUyHte
--HG--
extra : rebase_source : 3a60fe8fd66f9e89bfcc729fe5e1fa9e1ce8920d
Check for null TextComposition pointer, which can apparently happen
during regular usage.
MozReview-Commit-ID: 6nKjyBVL2vF
--HG--
extra : rebase_source : 68d8ff37612f6908b3983993fc73d19e9c0b0e50
Also remove mozilla.widget.use-argb-visuals which is useless since we don't allow transparent
toplevel windows.
MozReview-Commit-ID: 2ep3daeLZTG
--HG--
extra : rebase_source : 9ca5f2d0ded6dec1827caf2cb87e81fcb9b11792
Add a new config attribute to GtkCompositorWidgetInitData to allow transfer
the shape option from nsWindow. Also when shape is requested don't use XRender
or Shm widgets - only X11Image is supported now.
MozReview-Commit-ID: ElxnGQpLOry
--HG--
extra : rebase_source : 03552fc4103f6b22c512c07fe37102701998ed94
Derived routines for shape bitmap mask form nsWindow.cpp,
at WindowSurfaceX11Image we compose a final RGBA image and then create
the shape mask from image alpha channel.
Also the implementation is slightly simplified as it's meant as a fallback only.
MozReview-Commit-ID: 6VtGcsVKlcv
--HG--
extra : rebase_source : e8b96d68082ae687e376bc89c79f88f9c34cdc15
widget/windows/WinUtils.h is getting unwieldy and contains a combination of
both header-only and non-header-only code. I thought I'd take the opportunity
with this patch to create a new file for self-contained, header-only utility
functions, with the hope that we can eventually migrate some stuff out of
WinUtils into WinHeaderOnlyUtils in the future.
--HG--
extra : rebase_source : 6c874f78fc7113d1f7011fcd57ad9d024edb6761
aWidgetType is a NS_THEME_* constant. What this code is comparing is not.
This was exposed by a patch of mine converting -moz-appearance to be an enum
class.
MozReview-Commit-ID: 9BsbYk04vop
This patch fixes redrawing of the popup element by removing the scale factor
from the invalid regions because the wl_surface_damage multiplies it with the
scale factor too.
Also we set scaling factor of the wl_surface right after we create it to avoid
flickering when the compositor switches from unscaled to scaled surface.
MozReview-Commit-ID: 1eGoFu87wtF
--HG--
extra : rebase_source : 08abe86889e34865f3eed0f3979b4a584cc74adb
I mistranslated the boolean success value of the old initListBuild
method. Simplifying it to just use a promise rejection should be
equivalent and simpler, since this is only run from the update
method of WindowsJumpLists, and the call sites for that don't do
anything afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D2244
--HG--
extra : moz-landing-system : lando
This adds a WEBRENDER_QUALIFIED feature that's set whenever the webrender could
be used on a machine regardless of whether it's actually being used.
MozReview-Commit-ID: Eke6PMKQOnx
--HG--
extra : rebase_source : 977d371c12c9e8ab3273d6e65655e0378c22c226
This removes an unused gfxConfig check and changes Maybe<FeatureStatus>
into FeatureStatus as none of the callers were using None.
MozReview-Commit-ID: Kep6nYpDI3B
--HG--
extra : rebase_source : d7f71dd9b358bfd2c57380d7bc194d6002a50cb9
Key of TextCompositionArrary to search composition on widget is native IME
context. However, if TextInputProcessor dispatches composition events via
TextEventDispatcher, TextEventDispatcher::InitEvent() sets native IME context
of dispatching composition events to pseudo IME context (that's raw pointer
of TextEventDispatcher and process ID).
IMEStateManager::DispatchCompositionEvent() looks for existing TextComposition
with native IME context stored in WidgetCompositionEvent before dispatching
an event. However, after dispatching it, it looks for remaining TextComposition
instance with widget stored in WidgetCompositionEvent. Then,
TextCompositionArrary::IndexOf(nsIWidget*) will look for an instance with
the result of nsIWidget::GetNativeIMEContext() and this never returns actual
native IME context. Therefore, IMEStateManager::DispatchCompositionEvent()
always fails to remove TextComposition instance from the array even after
a test composition is finished.
This patch moves nsIWidget::GetNativeIMEContext() to nsBaseWidget to refer
nsBaseWidget::mTextEventDispatcher makes it return pseudo IME context if
TextInputProcessor has input transaction. Therefore, IMEStateManager becomes
always removes TextComposition from the array when every composition ends.
MozReview-Commit-ID: H1PCtPjBYJR
--HG--
extra : rebase_source : cbb3f3aae9954d65135d3840be8974fa30c4f7ff
Currently, we expect editing operations in
GeckoEditableSupport::OnImeReplaceText to cause synchronous text change
notifications. However, under e10s, text change notifications can be
asynchornous. The new code keeps track of active OnImeReplaceText calls,
and look for async text changes before replying to the calls.
MozReview-Commit-ID: INM3JLmQebK
--HG--
extra : rebase_source : ff5b728ef437fcd78e4e7eced9c9a537d4698dce
I initially tried to avoid this, but decided it was necessary given the number
of times I had to repeat the same pattern of casting a variable to void*, and
then casting it back in a part of code far distant from the original type.
This changes our preference callback registration functions to match the type
of the callback's closure argument to the actual type of the closure pointer
passed, and then casting it to the type of our generic callback function. This
ensures that the callback function always gets an argument of the type it's
actually expecting without adding any additional runtime memory or
QueryInterface overhead for tracking it.
MozReview-Commit-ID: 9tLKBe10ddP
--HG--
extra : rebase_source : 7524fa8dcd5585f5a31fdeb37d95714f1bb94922
We're already committing jump lists on mIOThread, and I see
no errors or problems with initting on mIOThread either, so
I think this is okay. Had to restructure some things to
make using a Promise simple, and to avoid dispatching to
mIOThread from within mIOThread (since we can only dispatch
to a LazyIdleThread from the owner thread).
MozReview-Commit-ID: 1imBF8Jzmn6
--HG--
extra : rebase_source : 4f912e819cec898910e72d95311e3924714a3090
LSBUtils closes a file descriptor twice, once with fclose and then again with
close. It also does this on a background thread, during startup, which means
it tends to race with main thread code which opens files.
This patch fixes that, and also removes a work-around for the issue in the
MemMapSnapshot code.
MozReview-Commit-ID: JdDHt9ayFEl
--HG--
extra : rebase_source : 2000ede41108d6312734d8df7db98272b33528fa
extra : amend_source : 1443a596fab3e3126a22d44787adaf5e12e4587c
Some odd mouse drivers try to activate a window which the mouse driver wants to
scroll its content (such window is typically under the mouse cursor when mouse
wheel is turned). However, this is illegal behavior and such odd mouse drivers
try to activate our popup windows which won't be activated without such apps.
We prevented this odd focus behavior with fixing of bug 953146. However, it
did NOT stop notifying widget listener of activating nor inactivating the
windows. Therefore, that caused a lot of reflow for supporting
-moz-window-inactive pseudo class.
This patch makes nsWindow::DealWithPopups() consume WM_ACTIVATE message before
nsWindow::ProcessMessage() because nsWindow::ProcessMessage() notifies widget
listener of activating and inactivating window even when focus move from and to
our popup window. So, in other words, this patch stops notifying widget
listener of activating and inactivating window when focus moves from/to
a popup window.
MozReview-Commit-ID: 2dyq07zHZKp
--HG--
extra : rebase_source : 8075a3ead73a5f2892a1a1a8e71252e574200bf4
When user removes all composition string of MS Pinyin, MS Wubi, MS ChangJie and
MS Quick with Backspace key, IME commits last character temporarily and
restart composition to replace the last character with empty string when
user tries to remove last one character.
This causes flicking composition string because the additional composition
selects the character and it may be painted immediately before removed, and
also editor will have unnecessary undo transaction.
Therefore, as same as bug 1208043, TSFTextStore::RecordCompositionStartAction()
should restart last composition in such case. Fortunately, we implemented
similar code for bug 1208043, however, unfortunately, we don't have preceding
pending compositionstart in this case. Therefore, this patch makes
pending compositionend store start offset of composition. Then, we can
restart composition only with information stored by pending compositionend
action. Additionally, this patch renames the method checking pending
actions for self-describing the new meaning.
MozReview-Commit-ID: 1RyuacxEbky
--HG--
extra : rebase_source : 1c8ecc0b63114ae65c77cd76cb85a21d2716442c
TextEditor modifies composition string or selected string when first
eCompositionChange event is received. However, TextComposition dispatches
eCompositionChange event ("text" event of DOM) only when composition string
becomes non-empty if current composition string is empty. So, when IME
dispatches only eCompositionStart and eCompositionCommit events for removing
selected text, TextEditor does nothing. This hacky behavior is used by
MS Pinyin on Windows 10 at least.
For supporting this behavior, we need to make TextComposition dispatch
eCompositionChange event when eCompositionChange(AsIs) event is fired
even before dispatching eCompositionChange event.
Although from point of view of web apps, the hacky composition should be
merged into the previous composition if it's possible but it's out of scope
of this bug.
MozReview-Commit-ID: 7QfeBJamGTU
--HG--
extra : rebase_source : 8de1353021f2961ae9f8bdf17ddded1058175339
Use wl_keyboard_listener and keymap event to get key mapping on Wayland. Weston simple-im.c example
is used as a reference implementation and actual key modifiers are derived from Wayland/GDK code from
gdkkeys-wayland.c.
MozReview-Commit-ID: 9fMwCvxkYy0
--HG--
extra : rebase_source : 21212cadfa7b1e8bacec2d6fb6970d2aaba7b3f6
VSync on Wayland is a bit tricky as we can get only "last VSync" event signal with
CLOCK_MONOTONIC timestamp or none (if application is hidden/minimized).
That means we should draw a next frame at "last Vsync + frame delay" time and also
approximate next VSync event when we don't get any.
MozReview-Commit-ID: FI3Z4nkmDNK
--HG--
extra : rebase_source : 8a0f6148990cf4e7ad26ff287eadff87cb0215fc
Currently, if an event is consumed in the main process, EventStateManager
does not send it to remote process. However, this is unexpected behavior
for some WidgetKeyboardEvent dispatchers. OS sometimes has consumed native
key events before sending applications. For example, Alt key on Windows
should activate menu bar of focused window but Alt key may be consumed before
focused window receives the event. In such case, we mark Alt keyboard event
as "consumed before dispatch", and chrome treat it like as its preventDefault()
is called in web content. (Note that for compatibility with other browsers,
the consumed state is not exposed to web content. So, Event.defaultPrevented
returns false in web content.)
Therefore, we need to treat "consumed" state and "cross process forwarding"
state separately. This patch makes calling WidgetEvent::PreventDefault()
always stops cross process forwarding for backward compatibility. Additionally,
for the special case mentioned above, this patch makes
WidgetEvent::PreventDefaultBeforeDispatch() take additional argument,
|aIfStopCrossProcessForwarding|. If this is CrossProcessForwarding::eStop,
the event won't be sent to remote process as same as calling PreventDefault().
Otherwise, CrossProcessForwarding::eHold, PreventDefaultBeforeDispatch() call
does not change "cross process forwarding" state. I.e., if the event's
StopCrossProcessForwarding() and PreventDefault() are not called until
EventStateManager::PostHandleEvent(), the event will be sent to remote process
as usual.
MozReview-Commit-ID: IQGWJvXetxV
--HG--
extra : rebase_source : 4ccdd500e80b8fe29e469ac3b85578e1c07c8358
Different from Windows and macOS, we cannot check if active keyboard layout
works as "IME" actually. Therefore, this patch add the telemetry probe
to the dispatcher of eCompositionStart. However, composition string is also
used by some Wester keyboard layouts which have dead keys. So, the meaning
of the result is deferent from the other platforms, but it must be useful
information which IM (e.g., fcitx, ibus) is used by most users.
MozReview-Commit-ID: A7vYuGtcrRw
--HG--
extra : rebase_source : 1f0948b58b999eee4b539d7db05d455b34f4be72
This patch adds a telemetry probe to collect Input Source ID or Bundle ID of
IME when an IME open mode is selected by user. Input Source ID includes
input mode of IME, but Bundle ID does not so. In most languages, we need
to collect the former, but only for Japanese IME, we need to collect the
latter because non-Japanese IME's input mode is "how to input characters".
So, the input mode is important. However, Japanese IME's input mode is
"to input which type of characters". So, Japanese IME user may use multiple
input modes but we need only the IME mode. If we'd collect number of
each input mode users of Japanese language, it'd be difficult to count
how many users actually used typical Japanese IME since somebody may use
only a mode, some others may use only different modes.
So, this patch collects Input Source ID when non-Japanese IME is open and
Bundle ID when Japanese IME is open.
MozReview-Commit-ID: CltLrWVGyRk
--HG--
extra : rebase_source : 752dd00c4e43bda9586ed3ba498636bf5069ead2
We always struggle with a lot of IME bugs on Windows. Currently, any IME
vendors should've already released TIP for TSF rather than legacy IMM-IME
since IMM-IME is not available on UWP apps. Additionally, due to API
limitation, it's difficult to get human-friendly name of IMM-IME. So, let's
collect only TIP names of TSF on Windows. This must be enough.
Note that we cannot get common-English name even though the API to retrieve
TIP name taking language code. Therefore, a TIP may be collected with
different name, e.g., one is Japanese name and the other is English name.
If we collect GUIDs of TIP, we can avoid this issue. However, it's
difficult to collect both GUID and human-friendly name since Telemetry
key is up to 72 characters.
Currently, I give up to avoid this duplicated issue. Perhaps, this is not
so serious issue since most TIP users must match language of TIP and their
system language settings. Therefore, this patch collects Locale ID of
TIP and description of it. Locale ID is necessary because some TIPs may be
named same name for different languages. For example, both Japanese and
Hangul IMEs of Microsoft are named as "Microsoft IME".
MozReview-Commit-ID: IeSxfeqS62a
--HG--
extra : rebase_source : b269ce3c41f7a998193972afb31183a61d3948be
Summary:
document.addEventListener("shadowrootattached", e => {
// Do stuff with composedTarget.
});
I didn't bother to add tests for the event itself since this is going to get
tested in bug 1449333, but I can look into writing a chrome mochitest if you
want.
Test Plan: See above.
Reviewers: smaug
Bug #: 1470545
Differential Revision: https://phabricator.services.mozilla.com/D1777
MozReview-Commit-ID: 55cVMSsznMS
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
I'm replacing non-failing calls to NS_NOTREACHED with MOZ_ASSERT_UNREACHABLE, but this NS_NOTREACHED fails when running the browser/base/content/test/general/browser_tab_dragdrop2.js test because mContainer is unexpectedly *not* null. This is bug 1469183.
This patch DOES NOT fix the cause of the assertion failure. It just replaces this failing NS_NOTREACHED with NS_ERROR because I can't replace with a fatal MOZ_ASSERT_UNREACHABLE.
MozReview-Commit-ID: KeVjvKGihxZ
--HG--
extra : rebase_source : dc08a8e15d1e98cda0fa755be43c6d06910bfbe8
extra : intermediate-source : 562cc0bfc636f29b1708acd3284567bb8492e030
extra : source : 4f14f18eccd6bb18ed92f1d39a265a30ccdd21a1
|name| is too generic but the scope is too wide in test_keycodes.xul.
So, let's rename it to |currentTestName|.
MozReview-Commit-ID: JvEDhRhKYCU
--HG--
extra : rebase_source : 15e06fabddeddb8e79198aa9f135e2951976aa8e
When AltGr key is pressed, following messages come:
1. WM_KEYDOWN for ControlLeft
2. WM_KEYDOWN for AltLeft
3. WM_SYSKEYUP for ControlLeft
4. WM_KEYUP for AltLeft
In these key sequence, KeyboardEvent.key value of keydown event at #2 and keyup
event at #4 should be "AltGraph". This patch fixes the key value and
adding new test into test_keycodes.xul to check the behavior with
SynthesizeNativeKey().
MozReview-Commit-ID: JZ6WednB8la
--HG--
extra : rebase_source : 596371ede89e90c23f7e842b26ec8155b911fe60
Users can emulate AltGr key with pressing both Ctrl key and Alt key on Windows
since AltGr is represented as so in Windows and physical keyboard may not have
AltRight key.
If user emulates AltGr key, we should set MODIFIER_ALTGRAPH to a set of
keyboard events for printable keys only when the key press produces
character(s) or a dead key. For example:
1. ControlLeft keydown event should make ctrlKey true.
2. AltLeft keydown event should make altKey true (not AltGraph state).
3. ctrlKey and altKey of printable keydown, keypress and keyup events should be
set to false, but getModifierState("AltGraph") should return true.
4. AltLeft keyup event should make altKey false.
5. ControlLeft keyup event should make ctrlKey false.
(If AltLeft key is pressed first, altKey of AltLeft keydown is true and
both altKey and ctrlKey of the following ControlLeft keydown are true as
usual.)
MozReview-Commit-ID: 8Km8GXPDQw1
--HG--
extra : rebase_source : f4924f075c68361c8ce563910280ea24774c519f
KeyboardLayout::InitNativeKey() takes |const ModifierKeyState&| as its
argument with NativeKey reference and it calls some internal methods with
the given ModifierKeyState without any changes. Additionally, its caller
is only NativeKey::InitWithKeyChar() and its called with given NativeKey
instance's mModKeyState. So, removing the redundant arguments from
some methods makes them clearer what they compute with.
So, this patch does not change any behavior.
MozReview-Commit-ID: 3w9Ee7PMU05
--HG--
extra : rebase_source : b724a18d5a14672e60ffa5fb9feca5c11dac42a3
By the proposal from Google, <https://github.com/w3c/uievents/issues/147>,
Chromium treat AltRight key as "AltGraph" modifier if the keyboard layout
has AltGr key.
When AltRight key is pressed with a keyboard layout which has AltGr key,
modifiers should as following:
1. "keydown" for ControlLeft:
ctrlKey: true, altKey: false, getModifierState("AltGraph"): false
2. "keydown" for AltRight:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): true
3. Some "keydown", "keypress" and "keyup" events:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): true
4. "keyup" for ControlLeft:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): true
5. "keyup" for AltRight:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): false
So, only when the preceding "keydown" event for ControlLeft, ctrlKey should
be set to true as usual. However, after AltRight key is pressed actually,
we should treat "AltGraph" modifier is true and both ctrlKey and altKey
should be set to false for web apps can handle text input normally.
So, MODIFIER_ALTGRAPH and MODIFIER_CONTROL/MODIFIER_ALT should not be set
at the same time.
This patch makes ModifierKeyState have only MODIFIER_ALTGRAPH or
MODIFIER_CONTROL/MODIFIER_ALT.
Additionally, this patch makes VirtualKey::ShiftState treat "AltGraph" as a
modifier. So, now, VirtualKey needs to convert ShiftState to index value when
it accesses its mShiftStates array. Therefore, this patch adds
VirtualKey::ToIndex() and make each VirtualKey method use it before
accessing mShiftStates.
Note that this patch also fixes bug of WinUtils::SetupKeyModifiersSequence().
The constructor of KeyPair takes 2 keycode values, but the second virtual
keycode can have scancode to distinguish if the key is left or right.
However, WinUtils::SetupKeyModifiersSequence() never sets scancode to
KeyPair. Therefore, it fails to dispatch AltRight key event.
MozReview-Commit-ID: 7ealxJH9KlZ
--HG--
extra : rebase_source : 761bc4416222def020a0731d6ae7940ef074ebe0
For setting AltRight key's key value to "AltGraph" if it should work as so,
we need to know if current keyboard layout has AltGr key. Unfortunately,
Windows doesn't provide such information but we retrieve all input characters
from each key when a keyboard layout is loaded. So, when we load a keyboard
layout, we can mark if current keyboard layout has AltGr key with checking
at least one key inputs different character(s) when AltGr key is pressed.
MozReview-Commit-ID: 8GI3phSVTUS
--HG--
extra : rebase_source : f1622615f03740609984da6d216391e23cae6796
Currently, TSFTextStore::GetTextExt() won't return TS_E_NOLAYOUT error when
ATOK retrieves text rect of all of the composition string.
However, if user converts 2nd or later clause, ATOK retrieves text rect after
start of the character of selected clause. Returning TS_E_NOLAYOUT in this
case causes candidate window being positioned temporarily below first character
of the composition string.
For avoiding the flicker of the candidate window, TSFTextStore::GetTextExt()
shouldn't return TS_E_NOLAYOUT when ATOK retrieves text rects *in* the
composition string.
MozReview-Commit-ID: Cp17HmP2QGK
--HG--
extra : rebase_source : bdd2d2867cccdcf1fe39612ca2f52872d472cb7a
Old ATOK referred native caret position to decide its candidate window position.
However, at least ATOK 2016 does not need to refer it. Additionally, if we
create native caret for ATOK 2016, the candidate window position, ATOK 2016
refers the native caret only when we cannot return expected rect. Therefore,
only immediately after modifying composition string, the position is different
from actual position by a couple of pixels and that looks like flicks the
candidate window.
So, we should stop creating native caret for ATOK 2016 (as same as ATOK 2017).
MozReview-Commit-ID: LsmVXCmRIzc
--HG--
extra : rebase_source : 30b7d15cb23e567b14e1231909aa5a17bdf909a6
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : dd000a05bfc2da40c586644d33ca4508fa5330f6
When only a part of window is updated we need to clip that drawing.
We use image surface for that as WindowSurfaceX11Image does.
MozReview-Commit-ID: 13znE1ZszB8
--HG--
extra : rebase_source : a236799fa33d73037913df94c0d5e619c5d3c47e
Right now we use the "tab-child-created" notification to attach
GeckoEditableSupport to a PuppetWidget in the child process. However,
"tab-child-created" is not fired for all instances of PuppetWidget
creation, and attaching GeckoEditableSupport at this stage can also
cause race conditions.
This patch makes us listen to "content-document-global-created" instead,
but attach GeckoEditableSupport to the PuppetWidget the same way.
MozReview-Commit-ID: 8IAtzuvlK4K
--HG--
extra : rebase_source : 50e4f05bccd06d301a2c2b1464666e5e1a58b3b2
Right now we coalesce notifyIMEContext calls but only for legacy
reasons. With the current code we don't want to coalesce calls, in order
to be properly notified of blurring and focusing.
MozReview-Commit-ID: 6N2jhyyBKui
--HG--
extra : rebase_source : 0a488a726b834da4f6124092426638f4be368d43
Right now we always notify Java of input blur. However, when input is
rapidly blurred and then focused again, we don't want to generate the
unnecessary blur notification, in order to avoid unwanted effects such
as the keyboard flashing.
MozReview-Commit-ID: AL6aLAHqNpD
--HG--
extra : rebase_source : c0a6a731f95f997a7a8e19eacdb635f99d21ebf5
Some InputContext members are not forwarded through
PBrowser::SetInputContext.
MozReview-Commit-ID: C1bGYq4w8zT
--HG--
extra : rebase_source : 1481f08c7593fe9dceb3b96bbfe480a1c58ecf9d
In the case where an inactive scrollframe's scrollbar gets dragged, the
main thread layerizes the scrollframe and dispatches both a
SetTargetAPZC message and a AsyncDragMetrics message using post-refresh
observers. However, the post-refresh observers are registered such that
the SetTargetAPZC message gets sent first, and APZ will start
processing the drag block immediately upon receipt of that event. This
means that the APZC might not have the correct drag metrics when it
processes those input events. For correct behaviour, we want the
AsyncDragMetrics message to reach APZ first in this scenario, and this
patch accomplishes this by allowing the post-refresh observers to be
registered in the opposite order.
MozReview-Commit-ID: 6LzyYYG1t6F
--HG--
extra : rebase_source : 2e3ebaa4fd776c8ad17e8225d70ec4a18eee67e0
It's based on a solution by Takuro Ashie <ashie@clear-code.com>
MozReview-Commit-ID: FqcdUJQJLdl
--HG--
extra : rebase_source : d4ed4d66439a3693a2f4d5e6a4037ed62969d64f
Currently, TabChild discards eKeyDown and eKeyPress events which are marked as
"repeated" and were dispatched after the latest eKeyDown event comes into the
process. However, keyboard layout utils may generate native key events
as "repeated" even if each native key is important to input proper text.
So, TabChild shouldn't decide if coming keyboard event is skippable only with
mIsRepeat. For solving this issue, this patch adds
mMaybeSkippableInRemoteProcess to WidgetKeyboardEvent and makes
TabChild::SkipRepeatedKeyEvent() check
WidgetKeyboardEvent::CanSkipInRemoteProcess() instead.
On Windows, there are two ways to generate keyboard input messages. One is
using SendMessage() or PostMessage(). The other is SendInput() API. In both
ways, utils can make their input as repeated key messages.
The former case must be safe for this issue since such utils need to set 31st
bit of lParam to 1 explicitly.
On the other hand, in the latter case, the utils probably need to append
KEYEVENTF_KEYUP into KEYBDINPUT::dwFlags. Otherwise, only first call is
treated as non-repeated event.
So, when given message does not came from physical key operation, NativeKey
should set WidgetKeyboardEvent::mMaybeSkippableInRemoteProcess to false
even if WidgetKeyboardEvent::mIsRepeat is true.
MozReview-Commit-ID: 3rinrOjx8Tf
--HG--
extra : rebase_source : 26b6d869260176fc7ef535323b83001bb4b725c2
nsGeoPositionCoords will convert NaNs returned from the location providers to null properties of the JavaScript Coordinates object.
MozReview-Commit-ID: Cmuf2aO0ClD
--HG--
extra : rebase_source : cbccead609ff53a3e5f1bcf7698eba7382220ce5
extra : source : b4ced6e2bab2d17cf642f5850bda5998f635fccb
Refactored StyleComplexColor to support "complex" blending between
background (numeric) color and foreground color (currentColor).
Made explicit the distinction between numeric, currentColor and a
complex blend in Gecko and Stylo.
This is to support SMIL animation, for example, of the form:
<animate from="rgb(10,20,30)" by="currentColor" ... />
MozReview-Commit-ID: IUAK8P07gtm
--HG--
extra : rebase_source : d3648101c6f65479b21e6f02945731cd5bb57663
When runnables are posted to the main thread's event loop, the event
loop notifies any thread observers that this has been done. The app
shell registers itself as just such a runnable, and posts messages to
the native event loop that processing native events needs to be done.
On Windows, this posting takes an extra reference to the app shell, to
keep it alive until the message is processed by the native event loop,
since app shell code needs to be invoked during that processing. The
processing releases this extra reference, so everything stays balanced.
Except that it's possible for messages to be posted to the native event
loop, and then browser shutdown happens. Those messages are not
processed and the associated references taken are not released. This
imbalance means that in debug builds, we appear to be leaking the app
shell, and that leaking results in intermittent oranges.
This intermittent orange has manifested itself in a variety of ways over
the years, depending on how big the app shell itself was (since that
changes the number of bytes leaked) and how many leak-checked things the
app shell was holding on to. This bug is merely the latest
manifestation; the last serious work on analyzing the phenomenon and
fixing it was done in bug 1220517.
The solution proposed in that bug was that we simply stop the extra
reference counting; when the app shell is destroyed normally, we
shouldn't be processing the native event loop any more anyway. So even
if the native event loop is holding (freed) pointers to the app shell,
we'd never execute the callback and perform a use-after-free. Reading
through the code suggests that this *ought* to be the case, but the
potential for shooting ourselves in the foot seems awfully high.
In any event, this is not a problem unique to Windows; we have seen this
same sort of thing happen on OS X. See nsAppShell::ProcessGeckoEvents
in widget/cocoa/nsAppShell.mm.
Here we propose a slightly different solution: we keep track of the
number of native event callbacks we have scheduled, incrementing when we
schedule, and decrementing when we actually run one. When the app shell
is destroyed, we simply set the number of outstanding events to zero,
and we prohibit the callback from accessing the app shell if there are
no outstanding events. This solution is analogous to dropping the extra
reference counting, but avoids potential badness if we do wind up
processing native events after the app shell is destroyed.
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
We expose the relevant APIs on textarea and input elements anyway
(chromeonly). The QIs will throw on a non-input or non-textarea element, but
none of these consumers expect that to happen.
Thomas Wisniewski
Hiroyuki Ikezoe
Jonathan Kew
Gijs Kruitbosch
Martin Stransky
Gabriele Svelto
Margareta Eliza Balazs
Jan Henning
arthur.iakab
Ehsan Akhgari
Xidorn Quan
Paolo Amadini
Nicholas Nethercote
ozoder
Kris Maglione
Landry Breuil
Andrew Swan
shindli
Noemi Erli
Edouard Oger
Makoto Kato
Cosmin Sabou
Olli Pettay
Mantaroh Yoshinaga
Randall Barker
Nicolas Silva
Andreea Pavel
Henri Sivonen
Ting-Yu Lin
Tim Nguyen
Geoff Brown
Masayuki Nakano
Neil Deakin
L. David Baron
James Willcox
Kyle Machulis
Masatoshi Kimura
Jonathan Watt
Boris Zbarsky
Narcis Beleuzu
Jan de Mooij
Bogdan Tara
Kartikaya Gupta
Jeff Muizelaar
Jim Chen
Emilio Cobos Álvarez
Csoregi Natalia
Sebastian Hengst
Aaron Klotz
Brian Hackett
Gurzau Raul
Jan Horak
Stephen A Pohl
Doug Thayer
Robert Bartlensky
Tiberius Oros
Jed Davis
Bas Schouten
Brian Grinstead
Dão Gottwald
Ciure Andrei
Matt Howell
Dale Harvey
Samuel Thibault
Alex Gaynor
Jeff Gilbert
Chris Peterson
sotaro
Andi-Bogdan Postelnicu
Takuro Ashie
Joel Maher
Coroiu Cristina
Dan Glastonbury
Ting-Yu Chou
Miko Mynttinen
Mats Palmgren