The flyout loads no more than 25 notifications
from a given source. Using those in-memory notification
objects to count how many are currently unread (and
update the badge) produces a result of at most 25.
This patch extracts the responsibility or counting the
unread from the Model/Item/Groupitem structure into
a new UnreadNotificationCounter class. It receives
estimated updates from other components and synchronizes
with the server after markRead/markUnread operations
have completed.
Bug: T129726
Change-Id: I9af4defc00dd491ed2b355eb4e85073476e08ce7
Hover effects aren't the only thing that cause link underlining,
the "Underline links" preference can do this too.
We do still need the :hover selectors too, for specificity reasons.
Bug: T130793
Change-Id: I01c0eaee449470380f3bd752e509043c4580fea9
Followup to I7891eb3fb46b3 this should be merged only after
the changes in MobileFrontend in Ie592ca738ac2d82 are merged.
Change-Id: I0f28e0757170e8a5b12075d3e9a2343fea7e7155
We need to use it in more than just the context of mobile, and
there is nothing actually mobile-specific in it. Renaming the
class so it isn't awkward to use elsewhere.
This makes the ext.echo.ui.mobile module unnecessary, but
we leave it in until next patchset so that MobileFrontend
doesn't crash while we wait for the adjustments in
Ie592ca738ac2d8 to be merged.
Change-Id: I7891eb3fb46b350f0b325bf0a2b56b2cd55ff1d7
There is currently a hard cap of badge display count.
We'll want to be able to request a different count for other purposes:
cleaning up old notifications, for example. We want to keep around a
certain amount of motifications (which is higher than the display count)
so we must be able to query a different count.
Change-Id: Id460fd7f46e397d22da49283b30fd12a6bbb0c9f
Add a mw.echo.ui.FooterNoticeWidget that includes a link to
a feedback survey, and three config variables:
* $wgEchoShowFooterNotice: Enable this feature per wiki
(Defaults to false)
* $wgEchoFooterNoticeURL: The URL for the survey
(Defaults to '')
* User preference 'echo-dismiss-feedback-alert': determines
whether the user permanently dismissed the feedback alert.
(Defaults to false)
Bug: T128937
Change-Id: I918a70beaba7b173e764519fe4fe0f780b61082d
Overwrote qqq.json which reverted a bunch of message
documentation changes and broke banana.
This reverts commit 688cedb0b7.
Change-Id: If5934b11706ca7d754b36e42072f2841726db1f7
Both in the order of the cross-wiki bundles themselves, and
in the message in the notification body.
ForeignNotifications tracks timestamps per wiki per section,
and exposes these through getWikiTimestamp(). ApiEchoNotifications
adds these timestamps to the sources manifest, and also sorts
the list of wikis by timestamp (it'd be nicer to do this in
ForeignPresentationModel instead, but then we'd have to create a new
ForeignNotifications instance which causes a duplicated DB query).
NotificationsModel receives the timestamp for its wiki as its
fallback timestamp, and makes getTimestamp() return this value
during the pre-population phase. This causes its parent to
automatically sort it correctly.
Because the timestamp of a wiki depends on the section (alerts vs messages),
we can't put it in the global sources manifest at the top level
of the API response. Instead, get rid of this global sources
manifest and put all the sources data in the foreign notifications
directly. This allows us to specify different timestamps, and also
allows us to get rid of code in EchoApi that was already remapping
the API response to this format.
Bug: T130298
Change-Id: Ie083fbb1ccaf74fbe804633d87ef03c9e71b120f
This involves:
* Making this value no longer admin-configurable.
* Changing getNotificationCountForOutput to return only a single value
Since there is no + in the formatted value anymore, we can actually
use the same value for both.
This is a B/C break, but hopefully worth it to simplify the method
call.
For now, the excess parameter is just marked unused. It could be
removed at some point if the translations are updated.
This must be merged at the same time as:
* Flow - Ibfa56b1af9e8c56b4c5f900e0d487bc09688b2a2
* MobileFrontend - Ibf784b279d56773a227ff261b75f2b26125bbb63 (well, MF
can be merged first)
* translatewiki - I2a4b6938aed49e4101deb6b9351c43656a863490
Also, change 1 to One/one, per Siebrand on the task. This can easily
be dropped/undone if we don't want it.
Also, remove reference to no-longer-existent notification-page-linked-bundle
Bug: T127288
Change-Id: Iabeaae747f99980c0610d552f6b38f89d940b890
FloatableElement incorrectly believes it doesn't need to
position itself when its closest scrollable is the same as
the closest scrollable of the container. This causes
the dotdotdot menu to be placed at the top left of the screen
if the notifications popup is not scrollable. If it is scrollable,
everything works fine. This regression was introduced by I5b5d7936c4d.
Work around this by setting overflow-x: auto; on the popup body.
This is a no-op, but tricks OOUI into thinking that the popup
body is scrollable even when it visually isn't. We can't use
overflow-y for this, because we still need to set overflow-y: auto;
on the popup body to work around a Chrome bug where right-floated
elements don't move over when the scrollbar appears.
Bug: T130153
Change-Id: I8bd8a26a4931444a760d2159779240272c51f966
