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
This is now required to actually pick up the MW UI progressive
color, so there's a slight visual change (wrong blue => right blue).
Fixes T72818
Bug: T72818
Change-Id: I719eb20a3940904ab45f8376280e20432a3b2d80
Added ext.echo.updateNotificationCount to notify other extensions
about updates to the notification count.
Bug: T67178
Change-Id: I7f4e34f2c1808b249db010018dd1b49a8dde246a
mw-ui-quiet gets dark gray and bold.
This way it is easier to see which is the current tab.
Bug: T71929
Change-Id: Ie7e21cd71a385d216402d393344cf76d3ed45d23
Binding it to the element name should rarely be needed as it only
adds complexity with no clear benefit.
Nesting classes should also rarely be necessary as it basically
requires the code will never be embedded in or itself embed something
from another component (otherwise you'd clash with that other component's
class name, and if you don't clash, then it wasn't neccecary to
nest the class in the first place).
If the class is overlay-specfic it should be renamed to something
like '.mw-echo-overlay-grey-link'. Keeping it as-is and applying
directly though, as it doesn't appear overlay-specific.
Change-Id: Ied601058c8e501914113d542f88542c83157d5a0
The max-height of the notifications list was hardcoded to
the height of the window minus 134 pixels. I don't know
where this value came from, but it doesn't seem to take
borders into account. The correct value appears to be
139 in Chrome and 140 in Firefox, so I changed it to 140.
Also, this really really should not be a hardcoded value.
This 140 value can be measured in JavaScript; that's how I
derived it. Even better, oojs-ui has a mixin called
OO.ui.ClippableElement that automatically does this for you
AND automatically adjusts the height when the window is resized
as well.
Change-Id: I17bc2c5333e5c3d5dd720e6bccf8cbbdbb4abe6c
The "hover" pseudo-event was deprecated in jQuery 1.8 and removed in
1.9. This is logged as "JQMIGRATE: 'hover' pseudo-event is deprecated,
use 'mouseenter mouseleave'". This fix switches to using the .hover()
method which appears to be the original intent as two functions have
been used which .hover() supports, whereas .on() only accepts one
handler. Now the class change works as expected.
Change-Id: Ib28801293b72f8f344455b5f308876d185abc8bd
This reverts the tests and amends them after the
application of commit 5da9eac08a.
Luckily nothing appears to be broken.
Change-Id: I67acfe5dc74ef750d5443dd619dbb114623ee233
Just like all other text elements in the overlay: set the font-size to 13px
Not sure why this was em & rest px. 13px is equivalent to the current 0.8em in
Vector.
Change-Id: I29d67f21cc2af7209469299ab228ebe7dac98af7
The only exception is when there are new message notifications but no new
alert notifications.
Bug: 70461
Change-Id: I06daa3f7d526beeb878eb343c169e01acd49e71f
This class was only being applied to notification output
on special pages and not in the overlay, move it so it can.
Additionally:
* bolds .mw-echo-title-heading same as the anchors it works with
* clean up a repeated rule against `.mw-echo-title a`
Change-Id: I579252399b39746f5aa2cfc51b5cd3b9b8b2cdb0
Also adds browser tests for the behaviour of the mark all as read button
to ensure it only clears message notifications.
Dependency: Ifb7b1b7b7feb4a5af65c79bb16b91a5a9c70166c
Change-Id: I46e1de229e32d705e67cebde678ecea3f3633906
This removes the need from the super specific selectors.
It also allows us to create multiple notification elements
on a screen.
Change-Id: Ife5291a315915779689943ffc18ac73d77351d0e
IE8+ supports the pseudo element. The world will not explode if
IE6 and 7 do not have the chevron.
This simplifies code by dropping the use of the pokey element
Note: I know we can drop using the image too but I decided not to do
that in this patch.
Change-Id: Ia9ac434461e63bc2cf8554060126995ac65a3531
Danny noticed a bug where if both tabs have unread notifications,
then when opening the overlay and clicking on the alerts tab, the user
would be reverted back to the messages tab.
Test stops this from happening again.
Change-Id: I6bbbbf61251957336de8856201412fa3569ab22d
Don't mark messages as read until they have been acted on.
Show a mark as read button that marks entire list as read.
Change-Id: I4450a66cffd11c67b9a4ba9aac0fe958dc760e15
Note no design was defined so have taken this to mean use
mediawiki ui for consistency purposes.
* Use mw-ui-active and mw-ui-quiet for tabs
* Update tests
Change-Id: If7a51b2286cdfe6e839dacc2476c9a578bc7f1df
Shift to new API to support 2 tab view
When a new has no messages they will see the old style overlay with
Notifications heading. I have added tests to assure this is the case!
Later patches will:
1) Add the mark as read button only in message view
2) Note currently the tabs do not refresh when notifications is clear.
We need some kind of EventEmitter to make this sort of thing easier.
Change-Id: I62b590e81cd3fe867c4c13959cb43466aacfe2d5
Make various properties of the overlay properties of
EchoOverlay to reduce need for function parameters
Change-Id: I70ec0c650d58322aad93d71292a836d7cf7e7474
Not as scary as it looks. The change to _buildOverlay simply changes
indenting, and cleans up to reflect new parameter. Tests still pass ;-)
Kill noticationLimit concept
Only expose what's necessary on mw.echo.overlay
Change-Id: I2671a41af8188c14ad4c910396afa0d9000b6051
