If the echo-overlay-title-overflow text is too long, it's wrapped into multiple lines now.
Bug: 55919
Change-Id: Ib1d252ab26be7d73cbf71c6fb19d84b80d8d30c8
Makes Doxygen think the whole function is deprecated,
switched them to "@param $var type deprecated"
Change-Id: I1536396258ee62c5bf81a5eb0542656d6d754818
If a user is mentioned in an area that does not have a section
title (for example, the lead section of a talk page), use the new
'notification-mention-nosection' message, to avoid an awkward and
incorrect "[[Page#|]]".
Bug: 52507
Change-Id: I40628b76c460c79008053222c9780bb23549731d
So we can link to multiple edits at once. This should not
change any existing behavior since 'prev' is used if nothing
is set.
Change-Id: If79e041d1443d8360abdf60b513ce8c7c0c7e1f8
Cache groups should only be used when it is worth to have the
module(s) in a separate request. Echo is relatively small and
stable in terms of cache combination, not worth it to force
its modules to be in a separate http request as all other modules.
Change-Id: I198b5664d662c93c593d048efcfaf4aac765a6b9
Apparently three wrongs make a right: hiding the overlay still worked.
* '#pt-notifications a' click event handler was not correctly checking
for events comig from inside the overlay due to a missing dot before
class name
* But if it were correctly checking, it would not be hiding the
overlay pokey (just its body) due to a copy-paste error
* Instead the clicks were handled by the 'body' click event handler,
which did not correctly check for events coming from
'#pt-notifications a'
I made things right again. The user-facing behavior is the same.
Change-Id: I02aba0e25ba4d81b234b327f120e0e2ff13d117c
Otherwise a new copy will be created every time the user opens and closes
the popup, and jQuery will hold on to each one forever (because it has
events bound), leaking a minuscule amount of memory.
Change-Id: I70c713be839f826fc27d07b04260c166f9052020
Not all installations will have a user with the id of 2,
like jenkins. At some point User::getOption is called, which
requires loading the user from the database, except it
doesn't exist. At which point the user id is reset to 0,
so it becomes an anonymous user, breaking the test.
Since the MediaWiki test runner automatically
creates a test user, we can safely assume that there is
a user with the id 1.
The other failure was due to that $wgUser may not
always be 127.0.0.1. The test now directly just
calls $wgUser to avoid issues if another test has
altered the global state.
Change-Id: Iacf904d04f1ff5aaf584cb98c3083ef6d7d89cea
