The logger code for clicktracking is only needed after something has
been clicked, so we don't need it in init.
* Move EventLogging initialization into Logger.js
* Add ext.eventLogging dependency server-side if needed
Change-Id: I46ff3c62b05c24dd2bb18a1574df17f9d2823125
If users are likely to open the flyout whenever they have unseen
notifications, we should preload some more resources to make those
intial openings faster instead of lazy-loading everything.
On the server-side, we will increment the MediaWiki.echo.unseen metric
whenever we serve a page when the user has unseen notifications. Then on
the client we will increment MediaWiki.echo.unseen.click if they opened
the flyout while having unseen notifications.
By comparing the two graphs, we can determine how likely users are to
click on the flyout whenever they have unread notifications, and how
useful preloading extra resources will be.
Change-Id: I14e9aa7f03d6ef275042b8a2c4cb0e5b5a64c0d7
There is no need to load the entire of Echo's ui module (especially
since that includes ooui widgets and their styles) on every page load.
There's only need to load the entire module if and when a user clicks
the Echo notification badge.
Also, make the echo.dm model accept an external fetchNotifications
promise so we can send the API request alongside loading the echo UI
and "feed" it into the DM for processing.
CSS adjusted to make the "jump" between the nojs and the js buttons
seem less jumpy.
Bug: T112401
Change-Id: I516e655ffd198511d694489a0702c5c713a5fd68
We cannot count on the user_newtalk flag being cleared since that
happens in a deferred update.
Bug: T107655
Change-Id: Ie954ed7c5a4e784c3feb86288943a56cfb9c23c0
MobileFrontend has its own implementation of the notifications
flyout, so don't load any of Echo's code. We do still need
ext.echo.nojs on Special:Notifications though.
Bug: T112571
Change-Id: If4d84810070ccd48a8007a3ff80733a7db30fdb3
We don't really need it to render the no-JS version
of the notification badges (the only rule we were missing
was background-repeat: no-repeat;) and it significantly
increased the amount of render-blocking CSS.
This means we do need to call setupOOUI() ourselves
in order for our get_class( OOUI\Theme::singleton() ) hack
to keep working.
Bug: T112401
Change-Id: I148f8ac19dfe62cc84abe03e1a2ff00683d515c1
Remove the behavior of the SelectWidget 'choose' and instead wrap
the notifications with their primary url links. That way, the click
handler returns to browser native response, and we gain automatic
behavior for ctrl+click, middle click, and regular click.
CSS had to be adjusted as well.
Bug: T112004
Change-Id: If10a4d3be71a8cf3ce966f15b922da0b9a2ddcc7
Make the popup header the pending element to give the user a visual
indication that the notification widget is being updated, but don't
clear the notifications before loading more from the database.
Bug: T112186
Change-Id: If2b724fab07ef5b7caf5cab3e44fe326470ac0e7
The flyout is now part of the personal tools, so Modern's styling of
`#p-personal li a` now affects it. Override that for links in the flyout
so it doesn't look super silly.
Bug: T111825
Change-Id: Ie67ff2d7803362bd7214bade27383282620799b9
Otherwise it causes flashes due to colors changing in skins that don't
use it, like MonoBook
Bug: T111821
Change-Id: I03acdbcbfa3912b439a18187d52944931e94506a
The alignment of the buttons was done haphazadly before, using
padding. This should be done better; we should calculate the buttons
width to be 50% of the width of the popup.
Since the popup accepts a width config, we know what its value is,
and can calculate the proper width. The width was added to the
variables.less file for continued use.
* Added popupWidth config variable to the badge widget
* Added OO.ui.ButtonGroupWidget to place the buttons in for
consistency and styling
* Added calculated width styles to both footer buttons
* Added corrections for MonoBook
Change-Id: Iad2c947da06241e9303cf1f35574177a0f602bbb
