| Age | Commit message (Collapse) | Author |
|---|
|
|
|
both reasons at the same time
|
|
|
|
|
|
|
|
# Conflicts:
# indra/newview/llstartup.cpp
|
|
|
|
|
|
storage as well.
|
|
Due to changes in SL-16715
|
|
end-to-end to avoid confusion
|
|
custom floater.
|
|
|
|
failed
also cleaned up some xui warnings
|
|
|
|
token input is now handled and message formatting is improved.
Added beginnings of support for saving slmfa_hash value client side.
|
|
We now present MFA errors to the user during login and prompt them for
an authentication token.
|
|
|
|
|
|
into DRTVWR-515-maint
# Conflicts:
# autobuild.xml (llca)
# indra/llwindow/llwindow.h (SL-13507 vs SL-5894)
# indra/newview/llscenemonitor.cpp (SL-14422)
# indra/newview/llvovolume.cpp (SL-12069)
|
|
|
|
In scope of SL-13740 work, this reverts commit 1935d25c78bf46f0fdc8758b6f215f53d17fd94a.
|
|
This reverts commit bf999f2f84dd26844c60d682f563f982a55e8ee8 due to revert of updater, this will be moved to separate 'epic' instead
|
|
|
|
Add code to login-fail handler to provide release notes URL from
SLVersionChecker handshake event.
|
|
This changeset is meant to exemplify how to convert a "namespace" class whose
methods are static -- and whose data are module-static -- to an LLSingleton.
LLVersionInfo has no initClass() or cleanupClass() methods, but the general
idea is the same.
* Derive the class from LLSingleton<T>:
class LLSomeSingleton: public LLSingleton<LLSomeSingleton> { ... };
* Add LLSINGLETON(LLSomeSingleton); in the private section of the class. This
usage implies a separate LLSomeSingleton::LLSomeSingleton() definition, as
described in indra/llcommon/llsingleton.h.
* Move module-scope data in the .cpp file to non-static class members. Change
any sVariableName to mVariableName to avoid being outright misleading.
* Make static class methods non-static. Remove '//static' comments from method
definitions as needed.
* For LLVersionInfo specifically, the 'const std::string&' return type was
replaced with 'std::string'. Returning a reference to a static or a member,
const or otherwise, is an anti-pattern: the interface constrains the
implementation, prohibiting possibly later returning a temporary (an
expression).
* For LLVersionInfo specifically, 'const S32' return type was replaced with
simple 'S32'. 'const' is just noise in that usage.
* Simple member initialization (e.g. the original initializer expressions for
static variables) can be done with member{ value } initializers (no examples
here though).
* Delete initClass() method.
* LLSingleton's forté is of course lazy initialization. It might work to
simply delete any calls to initClass(). But if there are side effects that
must happen at that moment, replace LLSomeSingleton::initClass() with
(void)LLSomeSingleton::instance();
* Most initClass() initialization can be done in the constructor, as would
normally be the case.
* Initialization that might cause a circular LLSingleton reference should be
moved to initSingleton(). Override 'void initSingleton();' should be private.
* For LLVersionInfo specifically, certain initialization that used to be
lazily performed was made unconditional, due to its low cost.
* For LLVersionInfo specifically, certain initialization involved calling
methods that have become non-static. This was moved to initSingleton()
because, in a constructor body, 'this' does not yet point to the enclosing
class.
* Delete cleanupClass() method.
* There is already a generic LLSingletonBase::deleteAll() call in
LLAppViewer::cleanup(). It might work to let this new LLSingleton be cleaned
up with all the rest. But if there are side effects that must happen at that
moment, replace LLSomeSingleton::cleanupClass() with
LLSomeSingleton::deleteSingleton(). That said, much of the benefit of
converting to LLSingleton is deleteAll()'s guarantee that cross-LLSingleton
dependencies will be properly honored: we're trying to migrate the code base
away from the present fragile manual cleanup sequence.
* Most cleanupClass() cleanup can be done in the destructor, as would normally
be the case.
* Cleanup that might throw an exception should be moved to cleanupSingleton().
Override 'void cleanupSingleton();' should be private.
* Within LLSomeSingleton methods, remove any existing
LLSomeSingleton::methodName() qualification: simple methodName() is better.
* In the rest of the code base, convert most LLSomeSingleton::methodName()
references to LLSomeSingleton::instance().methodName(). (Prefer instance() to
getInstance() because a reference does not admit the possibility of NULL.)
* Of course, LLSomeSingleton::ENUM_VALUE can remain unchanged.
In general, for many successive references to an LLSingleton instance, it
can be useful to capture the instance() as in:
auto& versionInfo{LLVersionInfo::instance()};
// ... versionInfo.getVersion() ...
We did not do that here only to simplify the code review.
The STRINGIZE(expression) macro encapsulates:
std::ostringstream out;
out << expression;
return out.str();
We used that in a couple places.
For LLVersionInfo specifically, lllogininstance_test.cpp used to dummy out a
couple specific static methods. It's harder to dummy out
LLSingleton::instance() references, so we add the real class to that test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Specifically, introduce an LLEventMailDrop("LoginSync"). When the updater
detects that an update is required, it will post to that rendezvous point.
When login.cgi responds with login failure, make the login coroutine wait (a
few seconds) for that ping from the updater.
If we receive that ping and if it contains a "reply" key, make the fail.login
listener respond to the updater with an indication of whether to proceed with
update.
If both login.cgi and the updater concur that an update is required, produce a
new confirmation message for the user and then (once user responds) tell the
updater to proceed. Otherwise, produce the usual login-failure message and
tell the updater never mind.
Introduce LLCoro::OverrideConsuming to provide temporary save/restore of the
set_consuming() / get_consuming() flag. It's a good idea to set the consuming
flag when retrieving data from an LLEventMailDrop.
|
|
Fix crash when no login URIs are found for a given grid
(does not happen after fixing above, but should not crash either).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
parameter logging at DEBUG)
|
|
|
|
|
|
|
|
|
|
crash stats (and add request parameter logging at DEBUG)
|
|
|
|
|
|
|
