Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

PSA: To see LAYOUT_WARNING(), add this to your .bash_aliases file: export NSPR_LOG_MODULES="layout:2"

21 views
Skip to first unread message

Daniel Holbert

unread,
Jul 29, 2015, 6:35:27 PM7/29/15
to dev-tec...@lists.mozilla.org
Hi Gecko layout hackers,

erahm has added new macros:

LAYOUT_WARNING("Something's broken");
LAYOUT_WARN_IF_FALSE(booleanCondition, "Condition better be true");

These warnings are opt-in -- so, they're silent by default. Gecko
developers who have an interest in layout code can & should opt in to
seeing these warnings (in debug builds) by setting the following
environmental variable (e.g. in your ~/.bash_aliases file):

export NSPR_LOG_MODULES="layout:2"

DETAILS:
These are basically identical in semantics to NS_WARNING /
NS_WARN_IF_FALSE -- they're to be used when something happens that's
possibly worrisome (but might also be normal/expected, given
pathological content). Unlike the NS_ versions, these LAYOUT_ macros
are opt-in, so that our test suites (which do contain a lot of
pathological content) don't spam zillions of lines for these warnings
failing.

The macros are defined here:
http://mxr.mozilla.org/mozilla-central/source/layout/base/LayoutLogging.h

USAGE RECOMMENDATION:
Generally, I think we should still prefer the NS_WARNING variants for
new code, so that bug reports are more likely to have useful contents if
someone pastes in their debug-build terminal output from around when the
bug happened. We should only fall back to these LAYOUT_ variants after
we've determined that a NS_WARNING is *both* useful to us &
spammy-during-usage-that-we-care-about (test suites / normal browsing).

~Daniel

Eric Rahm

unread,
Jul 29, 2015, 6:47:15 PM7/29/15
to
Also note: I plan on adding support for setting log levels at runtime through some rudimentary mechanism (probably prefs). This means a user will be able to turn on a specific log at runtime (in this case "layout").

Hopefully when this lands it will make the case for NS_WARNING somewhat less compelling, but I agree that in the meantime it can certainly be useful.

-e
0 new messages