Skip foreign bundles on 'mark all as read' operation, and mark as
read the items available in the popup.
Bug: T128621
Change-Id: I431b1ea94ab1c4942bd3de38753f113a4e2ae22f
Split and refactor Echo network handling and create a proper API
layer for the UI to use consistently. Split Echo's API methods into
its own module so they can be loaded along with the initialization
script and manage the API requests.
Change-Id: I0526a14bb8cc0d9729a303e24ab6e43259cc86bb
Use 'm' instead of 'minutes', 's' instead of 'seconds', etc, for
shorter timestamp rendering in the notification list.
Bug: T125970
Change-Id: I9479c5406a4bf44ef560bef2c8f204a9f60cafc6
This whole class is a terrible hack, and we should instead implement
a proper facility for what we need in OOUI.
Bug: T128436
Change-Id: I8777a6e36d238dc13c9060b74b7a72c6933082f6
07c5850b changed the widget used for the "mark as read"
menu item from OO.ui.ButtonOptionWidget to mw.echo.ui.MenuItemWidget.
While this makes sense, it also broke its functionality, because
mw.echo.ui.MenuItemWidgets are unselectable so if you click them
the 'choose' event isn't emitted.
However, we also can't make these widgets selectable, because
that breaks the links inside these widgets (the containing MenuSelectWidget
intercepts mouse events and prevents default). So instead,
make mw.echo.ui.MenuItemWidgets only be unselectable if they are
links (have config.url set), so that both use cases work.
Bug: T128432
Change-Id: I8374e3ae61a005ec7d25c2eb95b1391cbb191d60
Use dir=auto instead of wrapping in <bdi>.
They have the same effect, except that the latter produces
strange-looking truncation behavior with LTR body text in an RTL
interface because text-overflow: ellipsis; is set on the <div>,
not on the <bdi> node.
Bug: T127407
Change-Id: Id58a70f5b88a10c827e61d9e16aae1a81938709a
* Transform the action bar to table layout even in non-bundle
notifications.
* Increase the padding on the side for consistency
Bug: T125909
Bug: T125969
Bug: T126686
Change-Id: I26ba5b7a21a1f36774749154d3f95d61254c5ce2
The toggle-collapse process should be applied only when we click the
actual notification content/body and not the bundle items. This will
make it possible to middle-click (or right-click) a bundled item and
open it in a new window without resulting in collapsing the bundle.
Bug: T127416
Change-Id: Iaa06d5db8a1d5f9032874a800cafb6d5a4268876
Zopfli is the most efficient DEFLATE compression algorithm, trading run-time
performance for file sizes that are typically 3-8% smaller than those produced
by zlib with the maximum compression setting. Its output is Deflate-compatible,
so no specialized decoder is needed.
This change was created by running zopflipng against all the PNG files in this
repository. The exact invocation was:
git ls-files --exclude-per-directory=.gitignore -- '*.png' \|
parallel zopflipng -m -y {} {} \;
Files which zopflipng was not able to compress more efficiently were left unmodified.
Bug: T127608
Change-Id: I4bdef5e1b8e9ba63a3f13c7c475274e89f05ddc6
Zopfli is the most efficient DEFLATE compression algorithm, trading run-time
performance for file sizes that are typically 3-8% smaller than those produced
by zlib with the maximum compression setting. Its output is Deflate-compatible,
so no specialized decoder is needed.
This change was created by running zopflipng against all the PNG files in this
repository. The exact invocation was:
git ls-files --exclude-per-directory=.gitignore -- '*.png' \|
parallel zopflipng -m -y {} {} \;
Files which zopflipng was not able to compress more efficiently were left unmodified.
Bug: T127608
Change-Id: I1f01ac23c10d57edb8471f43ba01bf3cc8de5969
This makes the actions more consistent, and also allows for separating
the two behaviors: The one where we need a link to a destination
(User page, diff, etc) and one where we have an action the code needs
to take care of ("Mark as read" or, in the future, volume control, etc)
Also, this allows for adding descriptions to the secondary links in
the dotdotdot menu.
It also fixes the bug where the links did not work.
Bug: T125160
Change-Id: I0ebf3fc62425f86e2e7f1e96b67f8dc34db83efb
Make link-blue a bit bigger, revert a big smaller,
and change the blue used in link-blue.
Bug: T121624
Change-Id: I13d8667b4f2173c587330e1fc4604aa9f5632480
The rules setting the text color on the <a> with
various strong specificity overrides were unnecessary.
Instead, simply set the text color on -header.
This also makes the text color apply if there is no
primary link, because there is no <a> in that case.
Bug: T123756
Change-Id: I02c7d28438678968fa64a59beeac3d8d26cb0702
This will make the "flat" positioning of the bundle items a lot
more consistent and organized.
Bug: T121933
Bug: T123762
Change-Id: I472fcc89e540f1a886168069c547c6dc7e5ce613
Keep padding around the icon at 0.5em on the left and 1em
on the right for now; we'll change this soon to make the
icon centered.
Bug: T123656
Change-Id: I8c04daee460dd72e2358c3aa315110e05a9a5312
As a product decision it was decided that foreign notifications
cannot be 'mark all read' for their internal items.
Bug: T121930
Change-Id: I79292401b69adc4fad601192009296e02e8410b5
Make sure bundles can be marked as read by marking their sub-items
as read in the UI and also in the API.
However, for automatic 'mark as read' action (like the one that happens
when the model is "markReadWhenSeen") make sure to not mark-as-read
the bundles automatically.
Bug: T121930
Change-Id: I9d6bf6904fa3ca6559370e58853d29069f55af9e
The pure black icons which drew too much
attention when they are next to a lighter
text is changed by controlling the opacity
of the icons.
Bug: T119378
Change-Id: I2e6c8d47187621607a915e49cfe5380c744efe56
If an error has occurred while fetching from the API, the
placeholder item should display the API error information.
If the error is specifically a login issue, a specific
error message is displayed.
Also, adjusted the mw.echo.ui.PlaceholderItemWidget to
accept a clickable link; when valid (currently only with
login error) the link is applied so the user can click
the notification and be taken to the login page.
For general notices (like API error or a general 'no
notifications found' message) the link does nothing.
Bug: T121923
Change-Id: I89a43c7c0eb2cf8e63d03704536e0938ab57dd4d
We already output unix timestamp both in user preference timezone as well as
utc, but we only had the user timezone version for TS_MW format.
While we could change the frontend to use the unix timestamp format, I don't see
any reason not to also include the MW format in utc. Frontend can now easily use
that.
Also fixed creation of the moment object. The timestamp was created as UTC, but
the way it got there was wrong: it expects the timezone offset (Z) to be
included in the timestamp, which is not the case (so it just ended up at +0:00,
which was fine, but confusing). I removed the 'Z' and forced it to be
interpreted as utc.
Bug: T121813
Change-Id: I09403615a1ffbde5dd69af9914afdbdd86cbfe4d
We removed the item first from the 'unread' counter and then told
the API to mark it as read. The API, however, wisely first checks
if there is anything *to* mark as read, but by that point, the
unread count is zero, so it gracefully refuses and returns an
empty resolved promise.
That is clearly not the way to go. Remove the read item from its
smart unread counter only **after** it was sent to the API to be
marked as read.
Note: We shouldn't wait for the API promise to resolve to remove
the item from the counter, but the API should run its preliminary
tests before the item is removed.
Bug: T122087
Change-Id: Ia5fc35c7435db8c4742238897da67681cee23c41
Do not send an update to 'seenTime' to remote wikis; only update
the items that are in the local API.
Bug: T121928
Change-Id: I291ecdb53364327dbdcb769c0d93512eeed3ab29
Have the group item expand itself not only when clicking the literal
'expand' button, but also when we click the entire item itself, as
if to open the notification item.
Renamed the expanding method so it is not specific for the button
event alone; also renamed the 'toggleExpand' to 'toggleExpanded',
as it toggles the inner 'expanded' state withot the API request
expansion process.
Bug: T121929
Change-Id: Iac23e06d1c17be4e1c5f63663fb0f81261f50070
Use #888 instead of #666 to match secondary link text
(which is #000 with 50% opacity), both in the flyout and
on the special page.
Bonus: use LESS variables for these colors.
Change-Id: Ifc1182a001e9b25f6ff7c213b6fcde3dc2f0acd2
* Add the ability to use bundled expandable
notification groups
* Display bundled cross-wiki notifications following
the design
Bug: T115419
Bug: T115423
Bug: T115422
Change-Id: I8c3eba6d627c3f06d51d74fc9774e3fc2d02915d
Adds support in the logger code that is unused for now.
Note that I9bf6f4bcd41d8da5 must be deployed before this can be used on
Wikimedia sites.
Bug: T120158
Change-Id: I1968f36e21139975d25231ac25c22a73dea6fd0d
I'm not really sure where to stick the primary link. I could wrap the
entire notification in a <a> tag, but all the text becomes ugly (I
suppose we could hack around it with CSS?). For now I just added it
before all the secondary links.
Change-Id: I4f6add9ecfb367660d1a6346825382ad415bdb77
This is in preparation of adding more item models and widget types,
and in preparation of switching the notification widget away from being
a select widget.
Change-Id: I518fb3d80f4f67d677c21ca5593638269acfa544
This is in preparation for dealing with cross-wiki notifications
where we may need several types of operations to extract bundled
notifications from local and external APIs.
Also, renamed files:
* mw.echo.dm.AbstractAPIHandler -> mw.echo.dm.APIHandler
* mw.echo.dm.APIHandler -> mw.echo.dm.LocalAPIHandler
* All API-related handler files moved to their own folder
for better organization.
Change-Id: Ib730c780ea52c93a6026c5d0b22012b6f39bb50d
This is especially important for combined notifications and
notification lists from different sources; the model list should
be sorted to reflect items by timestamp and unread status.
Note: The dm.List and dm.SortedList now mirror the structures
OO.EmitterList and OO.SortedEmitterList that are awaiting to be
added for oojs in Ib94e4e4a49 and I3fd569691549 respectively.
Once those are available, the dm.List and dm.SortedList can
be removed, and the model can mixin OO.SortedEmitterList instead.
Change-Id: I97e1ecbe5dccc478be527a94f037500f78f74b14
Make sure it's possible to create a combined notification widget
that features both alerts and messages.
Change-Id: I4b3f263039f54430a61acc1a261d8aca8e894a90
This simplifies the operation of the API a bit, but more importantly
this will let us create a demo where we can manipulate the API result
and test various new notification formats while the work on the
backend API responses is ongoing, and also will allow us to have a
constant test for all notifications types, including backwards
compatibility.
Change-Id: I6081329a287cda4f5f1f1604ace5d04ff8d9fe3d
If a notification is already read it is by definition seen. Don't
mark those as unseen. This can actually happen if our seenTime is
invalid (like a cache miss)
Change-Id: Id943691599116597b6c68d2cc40e7b89a25ce05e
In Modern, the hover color for links in the #p-personal bar is
white, which is unhelpful for the buttons in the popup. Override
that style for hover.
Bug: T114080
Change-Id: I8b739f2a46c3eb3ce9f61e92b5025751047a451d
* Fix typo that caused logInteraction() to never do anything
* Fix incorrect context parameter passed by NotificationBadgeWidget
* Consistently use mw.Echo.Logger.static.context.* constants for the
context parameter everywhere
Bug: T114833
Change-Id: I140e4222169ad9e78c6bf016d9765828513adcbb
Making padding equal on either side, and use display:block
to avoid extra space underneath.
Bug: T115052
Change-Id: Icddb755cfe8892422661712d35eda4f01441207d
We have to account for the placeholder item, which doesn't have a
getModel method. We should ensure the real items and the placeholder
item implement a common interface so we don't need these kinds of
checks all over the place.
Bug: T114853
Change-Id: Iff6f0e85fb7737e09a34e72038b6b41681d95595
This browser test checks that mentions go to alerts and talk page
messages go to messages popup. This also upgrades the MW-Selenium
version in Echo tests to 1.6.1.
Depends on MW-Selenium version 1.6.1 (See T114061)
Bug: T113081
Change-Id: I40a17500cdfb838420c04dc0b9268ba56515cc2c
There was CSS trying to counteract this, but it wasn't strong
enough to override Modern's styles.
Bug: T114080
Change-Id: I96d9b32353fbabc8f720ecb869904639009c894f
Don't just remove it when all notifications are read, but when all
specifically talk notifications are read even if there are other
unread notifications in the popup.
Change-Id: I5aa65a4060d64f374b47fe91d8e53c92ded5fab2
We've corrected this behavior for updating seenTime but not for setting
the notifications as read if the widget is configured as
'markReadWhenSeen' which produced unexpected issues with updating alerts.
This is fixed in this commit.
Change-Id: I4d2420a81d2b8409749ad1621b2d56bdd14e8c6e
Modern has duplicated styles for `#p-personal li a` and
`#p-personal li a:hover`, so duplicate our styles too to make sure they
fully override Modern.
Bug: T114080
Change-Id: Ib3da29532e9f0939379f3988a629bd6b7b1fabb8
OOUI now uses absolute positioning for these icons, which breaks
the centered text model we'd like to use. Longer-term we should
use a different widget for these buttons, or perhaps a widget of
our own, but for now let's hack around that by undoing the
absolute positioning.
Change-Id: I8cc1fd69eeedde00facec80d82a21d5cc5610992
Whether the button should appear or not is updated when the badge
is updated, based on having unread notifications. But during construction
the button should be hidden.
When we do update the badge, the button should only appear if there
are unread messages and if the current widget is not 'markReadWhenSeen'
to avoid having the button 'flash' while notifications are marked
read.
Bug: T113629
Change-Id: I002db9e3d8990b5a2cd67bf5d120b1c7eb454362
The new oouified echo popup makes the tests invalid; this commit
rewrites those tests.
Also by doing this commit we are upgrading to Selenium 1.4.
Change-Id: I26215558768d55be449276c55b4b745c3a458ecb
And add a FIXME for our existing metric possibly being wrong if the API
request finishes before the ext.echo.ui module is loaded.
Change-Id: I918187dd276193b7602f60527b423ca06cb7e2d0
The notifications can be populated from the popup and outside of it.
We should update the seen time only if the request came from the popup
itself, and only if it is still open by the time the api request
has finished.
Bug: T113645
Change-Id: Id91ddabb85fd582be1890ea420d0559e0cdca167
The popup automatically updates itself every time it is opened.
If there are unseen notifications, they should be updated when the
next fetch happens, which means we must take off that class so
that the animation doesn't repeat itself.
Change-Id: Ib4173631efa1c5a3a3509e0797e60397397bd009
If the popup is open, whatever is coming in is immediately 'seen',
so we shouldn't flash the badge as red.
Bug: T112823
Change-Id: I9fe78ed11506de3c82043141f994e1ca96c5880b
The orange bar is replacing the 'talk' link; when it is removed, it
should actually be replaced back to being a regular 'talk' page
and not be completely removed from the page.
Change-Id: I930d321952e85ee79acbbd162ab763b4eea63ff1
We really only care about measuring the timing of the first click,
because that is the one that loads OOjs UI and fires an API request.
Bug: T113387
Change-Id: Ib37d31b07c45d546c75251a57a848e3ae0f4bf1b
We need the button to remain a standalone <a> element so it preserves
the exact same styling as the output we're getting from the PHP. the
only way to do this is to create the widget as the entire <li> and then
replace the original.
Bug: T112218
Change-Id: Ib6fd4369d46cb7f37b14675d63bbce9950abcd48
The status changed internally but was never passed to the API.
This commit fixes that mishap.
Bug: T112826
Change-Id: I1a6d2a871eae837860eb1f21df28134d5e747cd7
The unseen animation should display whether the option is unread or
read, because it should point out notifications that were unseen/new in
this session even if they are immediately marked as read (in cases
where the configuration is 'mark read when seen', like in alerts).
However, the animation itself switched by default to white background
which is an 'unread' state. This made cases like "mark all as read"
mark the notifications as read but still have a white background as
if they are unread, and yet have no 'x' button because they are actually
read. (Bear with me here)
This commit organizes the animation better. We now have a proper clear
naming for the two animations - unseen-to-read and unseen-to-unread and
we use unseen-to-read as default. unseen-to-unread is used when
the -unread class is applied and the other cases should reflect the
correct state of the option read/unread status.
Bug: T112826
Change-Id: I7fe8ea5dcf8c3e31d16213313be34b2350d03655
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 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
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
Hide the 'mark all read' button while we fetch notifications.
We can't mark all as read before there are any actual unread
notifications in the popup anyways.
Change-Id: I38ace6a3f8b7898bdcd82ce650947f0c7ef319e2
Notification badges are conceptually closer together than the rest of toolbar elements.
So it makes sense to move them closer visually too.
This is just a small CSS adjustment to compensate for the default margin
that items in the menu get. If there is a cleanner way to achieve the same,
feel free to refactor.
Bug: T108190
Change-Id: I06403f67c24f045c125c505dca2101f9eed79594
Since the nojs "base" version uses the automatic title creation
of the personal tools, the message keys were adjusted accordingly,
and the old unified message was removed.
Bug: T108190
Change-Id: I1f242f530aa68562aa4dc885156586c22c4df618
For some reason during the readjustment to the model/view the
mark all as read button was not toggled when it should have been.
It is now.
Change-Id: I05c32e9cb02e94b4e3dc3e2bcd9cead0eb802015
Listen to 'toggle' instead of onAction so we can only send api
requests for notifications if the popup is in the process of opening
and not when the button is clicked to close the popup.
Bug: T111667
Change-Id: I39aea942ff5a87a13043cccdb696ef8952ca61db
Make sure that when the seen state changes, the badge icon adjusts
in case there are two different icons for seen and unseen states.
Also organize a bit the unseen/unread status in initialization.
And separate and update the icons in the popup head to always fit
the status and icon of the badge.
Bug: T111432
Change-Id: I891a36c6eace9302b370a3efaf5aa6f57192c17f
The rule to make the firstHeading limited in height should only
apply to the design of the Special:Notifications page, and not
everywhere on MW.
Bug: T111628
Change-Id: I6636ed7f4ad0ccc7bbf83ace51dda62d09e09a5c
This is so that the animation definition remains on the notification even
after it is marked as seen.
Change-Id: Ifd19cd5cd003a4e29d0c42788d51aca985e0b859
First update the notifications as seen, then send the api request
for updating the seen time. Update the actual seen time from the
api response so the time is always in sync with server time.
Change-Id: I97717cfda7b665dcbc3add90712069700f44adf6
So we're not abusing user preferences for the last seen time.
EchoSeenTime is a small wrapper around ObjectCache that handles the
fallback to user preferences during the transition.
All JavaScript code now needs to use mw.config.get('wgEchoSeenTime').
Bug: T95839
Change-Id: Ia45ba5e30eb4564250539d04d5886d2598ebd49a
Split the notifications into 'alert' and 'message' badget with two
different flyouts. Also clean up styling and module behavior.
** Depends on ooui change Id4bbe14ba0bf6c for footers in popups.
** Depends on ooui change Ie93e4d6ed5637c for fixing a bug in
inverted icons.
** MobileFrontend must also be updated to support the new modules
in this patch I168f485d6e54cb4067
In this change:
* Split notifcations into alert and messages and display those in
two different badges.
* Create two separate flyout/popups for each category with their
notifications.
* Create a view-model to control notification state and emit events
for both the popup and the badge to intercept and react to.
* Clean up module load and distribution:
* Create an ext.echo.ui module for javascript-ui support and ooui
widgets.
* Create an ext.echo.nojs module that unifies all base classes that
are needed for both nojs and js support, that the js version
builds upon.
* Create a separate ext.echo.logger module as a singleton that can
be called to perform all logging.
* Clean up style uses
* Move the special page LESS file into nojs module so all styles
load properly even in nojs mode.
* Transfer some of the styling from JS to LESS for consistency.
* Make the 'read more' button load already with the styles it
needs to look like a button, since its behavior is similar in
nojs and js vesions, but before its classes were applied only
by the js, making it inconsistent and also making its appearance
'jump' from a link to a button.
* Delete and clean up all old and unused files.
* Moved 'Help.png' icon from modules/overlay to modules/icons for
later use.
Bug: T108190
Change-Id: I55f440ed9f64c46817f620328a6bb522d44c9ca9
This breaks pages using ?uselang=xx where "xx" is not
the user's language.
This reverts commit 0919b01e75.
Bug: T103935
Change-Id: I219810451b991cef88bac62cf880bfda6f98e930
mw.echo.setUpDismissability was removed in 08fc83b6de, and will
never be called since the class is never set.
Change-Id: I1e13bbabaeb7df21c161d4cf4205a1564e1d81d9
Since we didn't use to save seen time, it is unreliable at first.
I decided to just show them as read then, since we couldn't know
if they had or hadn't been read.
However, it would make more sense to keep them unread until we first
save the time a notifiation is seen: it is in line with the current
behavior (where the badge just stays red, always)
Also fixed a problem where I meant to .get a value but had .set
instead. It wasn't noticable because that function is currently
only called when things have just been seen, so even though it
was wrong, it produced a good result.
Bug: T94634
Change-Id: I7ee447249527feb3914c76cfffd673bbda062b75
Removed exemptions from .jscsrc and fixed the code to make jscs still
pass.
Kept the dangling underscores exemption because leading underscores
are (for now) used as a naming convention for private functions in
this repo.
Change-Id: I18964f8469f52c294276527d92cb6bf9f48c2576
I tried to stick as close to the existing code as possible.
Special:Notifications is slightly different from the overlay,
however. I made it add .mw-echo-unread class for consistency,
but that JS doesn't record seen time (it only loads older
entries), not does the CSS fadeout apply there (it marks
everything as read as soon as it's displayed, so different
behavior from overlay)
PS: I'm not sure about browser compat for the fadeout. But
even if some obscure browsers don't support this, meh. It's
not an "important" feature that can't be missed.
Bug: T94634
Change-Id: Ibb201823fb52ef8a3d5eaa39b0b724ede8d271d1
Links on the notification footer, "View edit" / "View changes", needs
to be blue instead of grey to be consistent with the Mediawiki interface.
The link turns blue upon hovering, just the way it is currently set
for other links on notifications like the page title.
Bug: T57367
Change-Id: Ibaaff52b9d4bdfc5beca442e10734dd5cf8886d7
