To implement this, use PopupButtonWidget and override to handle hover
in addition to click.
Bug: T128937
Change-Id: I79f5bb5839491516b0a3f77630b481cd6c2cc3da
If we don't do this, the footer becomes slightly taller
when the image loads, which makes the popup clip incorrectly.
Change-Id: Ica84d704692676d884b847f8fe01c49319f04931
We were using momentjs here before (causing bug T123845),
but we switched to using a hack for short timestamps.
This hack didn't call convertNumber(), so we stopped performing
number formatting for languages that don't use Western Arabic
numerals (0-9).
Strictly, that regression "fixed" T123845 because it caused
0-9 to be used in all cases, including the case that that bug
asked for. This patch fixes the regression but preserves the
desired behavior for arwiki, since convertNumber() respects
$wgTranslateNumerals.
Bug: T123845
Change-Id: Ic9acb12f534e0f049e22577afe276f8bf68f691d
This caused notifications on mobile to show notifications for
both alert|message, as the type was always "all".
Bug: T130801
Change-Id: Ice245eb407ca360d8e882c0ba48cb7b3e0ecb851
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
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
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
This is to wrap the mobile notifications in MobileFrontend with
a pendingElement and organize the API calls specifically for the
mixed popup in mobile.
Also added a specific 'ext.echo.ui.mobile' module so we don't
load unnecessary files for mobile.
Bug: T124188
Change-Id: I4a8be19a79b9e38c21907bb9d4123540a648c535
Add a 'mark as unread' to all unread notifications and allow them
to be marked unread. These notifications will no longer be automatically
marked as read when the pages they refer to are visited.
Bug: T73564
Change-Id: I677d3c0399e46fd7c35531df1cc0e61db2d4eb1b
We have a wrapper around logInteraction() called logNotificationImpressions()
that logs impressions uniquely (i.e. logs each notification impression only once),
but in addition to calling that (from NotificationsWidget), we were also manually
calling logInteraction() to log impressions from NotificationBadgeWidget
and NotificationGroupItemWidget. This resulted in two impression events
for every notification, each with different data, one of which is logged
only once and one of which can be logged multiple times.
Remove the manual logImpression() calls and route everything through
logNotificationImpressions(), which is called from only one place:
NotificationsWidget. Add support for logging foreign wikis to
logNotificationImpressions(), as it was previously missing.
This causes us to lose the notification type information in these
events, but that can also be derived after the fact by looking
up the event_id in the echo_event table.
Whether impression logging is even useful is another question,
but it certainly isn't useful if we log duplicate impression
events with different data.
Change-Id: I19b76a4ce796b21e9347dd9392af24918db82e18
