A number of the crash stacks here involve CheckForLegacyFamilyNames. I think what's happening in these
cases is that we've found a font family record via the mOtherFamilyNames table (which means it was the
result of a legacy-name or localized-name search already). That family is locked in CheckForLegacyFamilyNames,
but then if we find another version of the name in one of its faces, we may end up finding the same record
within AddWithLegacyFamilyName and trying to lock it recursively.
Cleaning up the locking in gfxFontFamily (we don't need to hold a write-lock in CheckForLegacyFamilyNames,
read-lock is sufficient) and suppressing the use of CheckForLegacyFamilyNames for family records that
were created via that codepath in the first place should prevent this happening.
Depends on D145970
Differential Revision: https://phabricator.services.mozilla.com/D145971
Callers that use the family's list of fonts need to hold a read lock for as
long as they're accessing the list.
Alternatively, the work can be moved into a gfxFontFamily method that locks
internally.
Differential Revision: https://phabricator.services.mozilla.com/D145924
It turns out the only caller of this method is one obscure edge-case in gfxDWriteFont,
so it should simply be an external API that makes no assumptions about locking.
Differential Revision: https://phabricator.services.mozilla.com/D144792
We use a recursive-mutex in gfxPlatformFontList as some of its methods may be called from
classes like gfxFontEntry that are used both from layout code (which does not explictly
lock the font-list) and internally by font-list code that is already holding the lock.
Differential Revision: https://phabricator.services.mozilla.com/D143869
This doesn't in itself make them thread-safe, but it provides a basis to do so by avoiding
dependence on the Preferences service at textrun-construction time.
The FontPrefs record is inert once constructed, so one approach to worker-thread use would
be to make it refcounted, and have the worker hold a strong reference to the record it's using,
so that it won't be affected if the main thread handles a pref-change and replaces its
FontPrefs. Alternatively, maybe we can just protect access with the same lock as other uses
of the font list, once that is in place (bug 1756474).
Differential Revision: https://phabricator.services.mozilla.com/D140914
This is useful for the following parts, as UniqueFileHandle is a cross-platform
type which can also be used to support transferring HANDLEs between processes.
This change requires fairly sweeping changes to existing callsites, which
previously did not require owning access to the handle types when transferring.
For the most part these changes were straightforward, but manual.
Differential Revision: https://phabricator.services.mozilla.com/D126564
This is useful for the following parts, as UniqueFileHandle is a cross-platform
type which can also be used to support transferring HANDLEs between processes.
This change requires fairly sweeping changes to existing callsites, which
previously did not require owning access to the handle types when transferring.
For the most part these changes were straightforward, but manual.
Differential Revision: https://phabricator.services.mozilla.com/D126564
Prior to bug 1715501, we were relying on the UpdateFontVisibility() method
to take care of this, but since making this a per-visibility-setting array,
that no longer happens so we need to explicitly clear them here.
Differential Revision: https://phabricator.services.mozilla.com/D128780
There is also a mozilla::intl::Locale in intl/locale/MozLocale.h. This naming
collision was causing crashes in debug builds where the wrong destructor ended
up being called. This patch renames the intl/locale/MozLocale.h class to
MozLocale.
I've filed Bug 1736017 to move callers of the MozLocale version to the
unified intl/components/Locale version.
Differential Revision: https://phabricator.services.mozilla.com/D128593
gfx/2d/SourceSurfaceD2D1.cpp(201,20): error: variable 'options' set but not used [-Werror,-Wunused-but-set-variable]
D2D1_MAP_OPTIONS options;
^
gfx/thebes/gfxDWriteFontList.h(269,13): error: variable 'hr' set but not used [-Werror,-Wunused-but-set-variable]
HRESULT hr = S_OK;
^
gfx/thebes/gfxGDIFontList.cpp(1020,12): error: variable 'cmapLoaded' set but not used [-Werror,-Wunused-but-set-variable]
bool cmapLoaded = false;
^
gfx/thebes/gfxMacPlatformFontList.mm:1771:10: error: variable 'isStandardFace' set but not used [-Werror,-Wunused-but-set-variable]
bool isStandardFace = false;
^
gfx/thebes/gfxPlatformFontList.cpp(1064,18): error: variable 'rejectedFallbackVisibility' set but not used [-Werror,-Wunused-but-set-variable]
FontVisibility rejectedFallbackVisibility = FontVisibility::Unknown;
^
gfx/vr/service/OculusSession.cpp(1329,12): error: variable 'bNewController' set but not used [-Werror,-Wunused-but-set-variable]
bool bNewController = false;
^
Differential Revision: https://phabricator.services.mozilla.com/D126454
This does not in itself change user-visible behavior, but is a foundation for bug
1715507 where we will make the behavior per-context instead of global. This is basically
just plumbing, passing a pointer to the presContext that's asking for fonts to be
resolved all the way down to the gfx code that handles the font list and looks up
fonts.
For the immediate goal of making font visibility work per-context, it would be
sufficient to pass the desired visibility level in to the font-selection methods.
However, passing the actual presContext down (and not just its visibility level)
will enable us to report back via the dev console when a font is blocked (see bug
1715537), so the approach here provides the basis for that upcoming enhancement.
Depends on D124194
Differential Revision: https://phabricator.services.mozilla.com/D124195
This does not change existing behavior, but will be required once font visibility
is no longer simply a global setting. The data cached in these members depends on
the font visibility level, so currently we just flush it if the visibility pref is
modified. But in future we may be using multiple levels at the same time (in
separate contexts), so we want to maintain separate per-level caches here.
Differential Revision: https://phabricator.services.mozilla.com/D124194
This does not in itself change user-visible behavior, but is a foundation for bug
1715507 where we will make the behavior per-context instead of global. This is basically
just plumbing, passing a pointer to the presContext that's asking for fonts to be
resolved all the way down to the gfx code that handles the font list and looks up
fonts.
For the immediate goal of making font visibility work per-context, it would be
sufficient to pass the desired visibility level in to the font-selection methods.
However, passing the actual presContext down (and not just its visibility level)
will enable us to report back via the dev console when a font is blocked (see bug
1715537), so the approach here provides the basis for that upcoming enhancement.
Depends on D124194
Differential Revision: https://phabricator.services.mozilla.com/D124195
This does not change existing behavior, but will be required once font visibility
is no longer simply a global setting. The data cached in these members depends on
the font visibility level, so currently we just flush it if the visibility pref is
modified. But in future we may be using multiple levels at the same time (in
separate contexts), so we want to maintain separate per-level caches here.
Differential Revision: https://phabricator.services.mozilla.com/D124194
This seems to be what Chrome does on Windows, and should do the right
thing in other OSes.
On macOS we can do something better and look up the language-dependent
font. That requires further work, but shouldn't probably block this (as
long as system-ui is turned off by default at least).
Differential Revision: https://phabricator.services.mozilla.com/D120714
Alias -apple-system to it, and put it behind a pref for now. This is
pretty boring (read: uncontroversial hopefully) code. The follow-up work
is modifying StaticPresData to look up the fonts using system APIs,
probably. Maybe a bit more work if on macOS they can't be named.
Differential Revision: https://phabricator.services.mozilla.com/D119984
Jonathan Kew
Jens Stutte
Nicklas Boman
Dan Minor
Butkovits Atila
Sandor Molnar
Nika Layzell
Cristian Tuns
Noemi Erli
Mike Hommey
Emilio Cobos Álvarez
Iulian Moraru
Csoregi Natalia