This boilerplate at the beginning of most files is an anti-pattern from
very early 2011 frontend experiments (I take full blame), where I didn't
understand (or had confidence in) the load order of scripts. I won't
remove it all at once, as that requires careful review of dependencies.
But this one file seemed like low-hanging fruit. The "ext.echo.dm"
contained a file that lazy-created `mw.echo` as empty as empty object,
and `mw.echo.config` as `{ maxPrioritizedActions: 2 }`.
The "ext.echo.init" module loaded on every page already does the same.
Remove this file and depend on that module instead. The same modules
will be downloaded, in the same way, and in the same order as before.
What changes is that the order of execution is now defined instead of
implied, thus making the dm-version of it redundant.
In practice, while fragile, the load order was already consistently
running init before dm. I found this through code coverage analysis in
Chrome DevTools, <https://phabricator.wikimedia.org/F28421786>.
Change-Id: Iaed7cf0e47479ce8ce76aee1bfe479d82b4f61ed
Colours were previously defined only in the monobook- and vector-specific
styles, but with the same styles in each, and appear to work consistently
accross all tested skins (modern, timeless, cologneblue, anisa,
hassomecolours...). Given the UX importance of these colours, better to
apply them as the default for all skins and leave it to any others for
which this doesn't work to resolve any issues on their end.
bug: T181142
Change-Id: Idc22881d6c51aa12adc9a053ce08adfdf0fad2b0
This leads to broken styling in OOUI 0.30, and is only
a marginal improvement in the Apex theme.
Bug: T215509
Change-Id: Id7d000be7c9dcd50e050f067c6f1fbdc06f332af
Selector was set on the element's class, not the icon carrying
pseudo class, resulting in a hard to predict
double opacity application. Also changing default opacity to
WikimediaUI Base values.
Bug: T207542
Change-Id: I1f45e721ee30acfd6261edcbc9d81cf92c7217a3
Fix the regressions from being able to wrap items on narrow screens
in I2102f6d33979b. We don't want wrapping in affected cases.
Bug: T208930
Change-Id: I748d5b455bef15067205b49824386d2ab5dfdc07
This will prevent these requests from being blocked by browser plugins
like Privacy Badger and AdBlock.
I believe this eliminates the last foreign requests in the front end, so
we should clean up and simplify the now largely unused hierarchy of
API-related classes.
Bug: T121930
Change-Id: I74c22514409ad7e206a413306065a0c62d2e793d
Add a markasreadwiki parameter, and use cross-wiki API proxying to mark
the specified notification(s) as read on the originating wiki.
This allows notifications to be marked as read when the primary link is
followed, even if the primary link points to a different wiki.
Bug: T179765
Change-Id: Id7e1e11997173e1578e33cd189dc0f93a5e4ba63
* Move revision ids out of configuration and into MWEchoEventLogging
class. Because the EchoInteraction schema is used both server and
client, we have to duplicate the revision id.
* Use EventLoggingSchemas attribute to register client-side schema in
extension.json instead of a hook.
* Check if EventLogging is enabled in MWEchoEventLogging instead of
$wgExtensionFunctions.
* Pass only whether the EchoInteraction schema is enabled to the
client-side instead of all of $wgEchoEventLoggingSchemas.
Change-Id: I968294f96cedac19dc9d8f53df14fecfb666ceee
The only place that reads the config variable is in ext.echo.logger,
which uses OO.getProp() to do so. If that property doesn't exist,
`undefined` will be returned, which we can force to boolean false.
Bug: T118488
Change-Id: Iac352b133950f6f2e4b88950c1fcd0c893284fd9
This avoids needing any dependencies on EventLogging in the module
definition, as well as allowing the extra dependencies to be lazy-loaded
as necessary.
Change-Id: I49b5be4be4f55cd4e27064247463b2ddb8e81296
Replace the handle with a button widget.
Also remove the unused PendingElement mixin.
Bug: T178387
Change-Id: Iec3afea6c6a8fdb49e17750af7bada42b7ed4b70
