p-personal links have a white background on hover, and links
inside the notifications popup were inheriting that CSS rule.
Bug: T144063
Change-Id: I3868e418ab8cce8e5ff6f7cc10e042907cb1e8df
This is necessary to preserve backwards compatibility for the API, and
this also fixes the no-JS special page.
Also, fix additional warnings.
Change-Id: Id603b4ab22c69097d5559a756bec72a6ba785661
Allow extensions to add dynamic actions that perform some
API request and display a confirmation message.
Bug: T132975
Change-Id: Ib16d57c3f1a11a9749564c6e2112bf1ca32c55e8
Work around new styles introduced in oojs-ui in I77cd5212c.
Bonus: remove useless styles targeting the dotdotdot popup
in NotificationItemWidget.less: it's not even a popupWidget
any more and it's located in an overlay anyway, so these
styles didn't do anything.
Change-Id: Ifb16b7bb0b01c1eb2551ba4c173042cc759e9b02
Just like we do in the mobile popup, the menu should be accessible
in mobile clicks/taps by being "stuck" at the bottom of the screen.
Bug: T142013
Change-Id: I730216e717c2a02ad98bbcc28f66b13c1cbe29ed
In the unseen notifications case, Monobook used badges with
black text on a light red/blue, even though the text
is white on grey in the non-unseen case. Change the unseen style
to white on dark red/blue like Vector, and also make the colors
exactly the same as Vector.
Change-Id: I9d2d1a2614ac1130e027fb952c9288588d25d495
Do not emit sortChange for toggleSeen, because every sortChange
creates a fake widget with a flipped 'read' state. There is no
reason to emit the sortChange event in toggleSeen anyways so it
is safer when only emitted in togglRead.
Also, make sure the controller always updates the correct seenTime
from the API when fetching local notifications. This was done for
the special page method but was overlooked for the fetching of local
notifications. For the most part, it shouldn't be affecting too much
because the SeenTimeModel is initialized with wgEchoSeenTime (which
is local) but updating the controller with the API response is the
safe thing to do, and will also cover cases where a tab was open,
notifications were seen in a different tab, and now the popup was
reopened in a "stale" tab again.
Bug: T143067
Change-Id: Ie261e32db28926d04fe14f7badd9d287ddc52749
We have to override a CSS rule that tries to make all <a>s blue,
but not override it so powerfully that the real link in the footer
notice isn't blue.
Change-Id: I5a91419aab7cf6d6fe10c8e707168b52c2451cd8
Adds common bundling including messages and icons.
Bundling relates to revision now.
Changed order how notifications are generated. Now errors will
show first, since they are generated last.
Bug: T140224
Change-Id: I1069aeb5523db8710da4e8e21065bf447d031e3c
Seems to be fixed by different changes, and now this change
is causing trouble, moving the badges up off-screen.
This reverts commit 0b7f8712a9.
Change-Id: Ia5a0a6b6be3698436a043aee111f251709c22f20
What this really does is:
* Change the forced width of the <a> to the width of the icon
(rather than 1.25x the width of the icon)
* Change the alignment of the :before from 40% to 50% so it
stays in the middle (1.25*40=50)
Change-Id: I0399a20fc84e59fcbcf69da509a4d8bfa9b54a08
The color: transparent; hack was being overridden by a color rule
that's only in effect after the popup is opened.
Change-Id: I2f415619603ccadb625ed2482c25fde78765fee4
It's a lot easier to set 'color' back to the desired value than 'font-size'.
As an amusing side-effect, the hidden text will appear when selected, and
it will be possible to copy it.
Change-Id: I7a7ef8e60f514743c9cb65bcef3ba4e869f5b7b7
I think everything works the same. Some older browsers (IE 10-11,
Opera 12) have funny issues with SVGs in 'content'.
.mw-echo-notifications-badge now has 'height: 24px', as it must be
at least as high as the background to display it. We no longer need
.oo-ui-popupWidget to have 'margin-top: 7px', that was a workaround
for the badge having smaller dimensions in CSS than in reality.
This also allows us to significantly reduce the amount of Monobook-
specific CSS, because we now use the background-image approach for
all skins.
Bug: T142042
Bug: T142248
Change-Id: Iaa22202dbd5b5eb7a9b1ef47d068e80764ed982f
The actions logged:
* Popup: Mark all notifications in the popup as read
- Event ID is omitted
- Context 'flyout'
* Special page: Mark all notifications in current wiki
as read
- Event ID is omitted
- Context 'archive'
Bug: T127955
Change-Id: Id7c091f9e0cf0dd3745d33e335ab44706581d7f3
When we mark an entire bundle as read, we don't care if it was opened
before or not - we call the API for the list of sources and their items
and build a list of IDs to mark as read in the remote source.
Then, we make sure that bundleIDs are expanded, added to that list.
Previously, we then sent those IDs to 'markCrossWikiItemsRead'
which marked the item IDs in the remote wikis as read.
markCrossWikiItemsRead is also expanding item bundle
IDs (correctly, because we also use it when we mark individual
xwiki items, and they should be expanded)
However, in cases where we mark individual xwiki items, the
model list is already filled, so markCrossWikiItemsRead trusts
the models to deliver the sub items (and then expand on their
IDs properly)
In the case of marking an entire xwiki bundle as read without
opening it first, however, that operation is not only redundant,
it produces a problem where the models were not yet filled
(because the xwiki bundle wasn't opened) and so we get empty
array of IDs, and the API has nothing to mark as read.
The solution is simple in this case - skip this method for working
with an entire bundle. It's both a redundant operation and the
wrong model to check. Send the information directly to the API
instead.
Bug: T142143
Change-Id: I4ed3bbc5c83290ed5791060b124840b1c3b12a75
This fixes a bug where changing the read status of any notification
in the messages popup would remove the "You have new messages"
banner even though there are still unread talk page notifications
in the alerts popup.
Change-Id: Ic6b3d2c9fa764be2da8f9bd9b0d10311857f8509
A browser bug causes the badges to be pushed down by 1em in IE11
and below, but not in Edge. The only way I could find to work
around this was to add top:-1em; in IE browsers using CSS hacks.
Bug: T142053
Change-Id: If240f7281dd795085c003af524da294d5bf5ff76
Not sure why it's doing that, because the SVG has explicit 24x24
dimensions, but adding these (theoretically unnecessary) CSS rules helps.
In Chrome/FF (as well as more modern IE versions), this is a no-op.
Bug: T142042
Change-Id: Ibb293f453dc79de90690ab48f522e43d3e66b8e8
Foreign notifications, though non-expandable, can represent
bundles (4 new topics on your talk page). When marking one
as read, it's important to provide all the IDs that are
part of that bundle. Otherwise, only the dynamic base is
marked as read and the bundle shows up again on reload
(3 new topics on your talk page).
For bundles that do not include the count
(The description on Flow_Page was edited multiple times)
it looks like the mark-as-read action did not work.
Tagging with T140309 as it may explain it but not 100% sure.
Bug: T140309
Change-Id: I19c9eb18669b7cad8173c966392a6e5977018121
