(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
The problem happened only on themed widget. The problem was triggered by Bug 888870. It just added Windows 8.1 support. When high contrast mode was enabled on Win 10, background color problem happend on themed widgets. There were 2 patterns.
- After hover the menu item, its background color remained highlighted
- After hover the menu item, its background color became black
From it, the problem seemed to be caused by background color drawing of themed widgets. nsNativeThemeWin::DrawWidgetBackground() does the background color drawing. AssumeThemePartAndStateAreTransparent() controls skipping background color drawing of themed widgets. If AssumeThemePartAndStateAreTransparent() was removed, the problem was addressed. From it, how DrawThemeBackground() works seems to be changed on high contrast mode since since Win8.1. To address the problem, the patch remove the skipping on high contrast mode since since Win8.1
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
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
One thing to note here is that the Scale function on gfxRect has a
different implementation than that in gfx::Rect which is replacing it.
The former just scales the width/height directly whereas the latter
scales the XMost/YMost and recomputes the width/height.
MozReview-Commit-ID: 5FImdIaNfC3
--HG--
extra : rebase_source : 98662d2a52ff9652ec60b066641a07c6d5ee8e08
Most of this patch is updating a few places that use gfxMatrix to use
the equivalent-but-differently-named functions on MatrixDouble:
- Translate/Rotate/Scale get turned into PreTranslate/PreRotate/PreScale
- Transform(Point) gets turned into TransformPoint(Point)
- gfxMatrix::TransformBounds(gfxRect) gets turned into
gfxRect::TransformBoundsBy(gfxMatrix).
- gfxMatrix::Transform(gfxRect) gets turned into
gfxRect::TransformBy(gfxMatrix).
The last two functions are added in this patch as convenience wrappers
to gfxRect instead of Matrix.h because we don't want Matrix.h to "know"
about gfxRect (to avoid adding gecko dependencies on Moz2D). Once we
turn gfxRect into a typedef for RectDouble these will be eliminated
anyway.
MozReview-Commit-ID: BnOjHzmOSKn
--HG--
extra : rebase_source : cf1692d1f0d44a4b05d684a66678739181a426d5
It appears that neither Chrome, Safari or Edge support this feature,
and it's causing web-compat issues for us, e.g. bug 1373417.
MozReview-Commit-ID: AP5LMgL6QmR
We have to use the system scale here for consistency because GetThemePartSize and GetThemeMargins will always assume the system scale and callers of GetGutterSize will adjust the size using GetThemeDpiScaleFactor.
This patch will also fix an existing bug where native-themed elements are not scaled when layout.css.devPixelsPerPx has a non-default value on Windows 7.
MozReview-Commit-ID: ILHiOrkTPoT
--HG--
extra : rebase_source : 130dd313ed478d1fe8a9b88ce2705df985c817c3
I did my best to remove as much stuff as possible in this patch. The starting
point was to remove all the IsVistaOrLater() and IsWin7OrLater() calls, but I
also grepped for various strings and found some other removable stuff that way.
I may have still missed some things.
Notable things done by this patch.
- It removes numerous blocklist entries.
- It removes CanComputeVirtualKeyCodeFromScanCode(), because it's always true
now.
- It removes ShowXP{Folder,File}Picker(), even though these were available as
fallbacks on Vista+. The "when platform is built without the longhorn SDK"
condition in the comment above nsFilePicker::ShowXPFolderPicker() sounds like
it won't ever happen any more.
- It removes the config.trim_on_minimize preference. This requires adding a
bool sHaveInitializedPrefs variable; previously the lack of pref
initialization was indicated by the tri-state sTrimOnMinimize variable having
the value 2.
Notable things *not* done by this patch.
- ClearThemeRegion() still exists. The comment suggests that it is XP/Vista
only, but the code suggests otherwise. jimm thinks the comment is wrong.
- The comment in WinWakeLockListener::Callback() suggests that the StartTimer()
call is no longer needed to block the screen saver. I'm uncertain about this
and so I think it's best left to a follow-up.
--HG--
extra : rebase_source : f46645907d237423fd6115ab1b4725b023a0dce3
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
