With the introduction of the FeaturesManager the
getConfigVariable method will disappear.
(I535b24803341dc3912aed4bef06970e2861fe3ad)
That change cannot be merged until Minerva stops using the
method.
This temporary fix ensures it resolves to false when the method
doesn't exist.
Bug: T182217
Change-Id: I619fd8fac47a98d1ff8f3646d61b8e285246a17f
A horizontal line shows in popup previews in the MinervaNeue skin
just above the setting icon due to a css rule that affect all footer
elements. Removing this effect to apply only for the MN skin.
Bug: T184560
Change-Id: Idb0c40c3fc24e4ec2d32cb2de9520952448da77a
Template pages do not run the MobileFormatter
(see MFMobileFormatterNamespaceBlacklist).
As a result page.getLeadSectionElement() will
return null
When this happens do not change the edit icon to point
to section 1. Instead give them the non-JS editor.
After this patch, the feature remains as:
* Page with lead section get the JS edit overlay for section 0
* Page without lead section but with other sections gets the JS overlay
editor for section 1
* Pages that didn't run through MobileFormatter don't modify the edit
link and just link to the fallback editor (useful for Template pages
at this moment)
Bug: T172948
Change-Id: Icee96e12f62ec13a1cbd3169c687fa4b3af70754
Follows-up 2c01147c13be, 429f557cc7f68a46.
The array is already copied by value once returned from getLanguages().
Setting it by reference within the QuickTemplate instance doens't
have any effect, but does logically break the concept of pushing
data in a single direction through the skin.
Remove use of setRef in preparation for restricting skins only
consuming data as given, without the ability to change data
in other parts of the system.
Bug: T140664
Change-Id: I0978dd5c123fda57f45534a8d2e51b7e65e55223
Changes:
* MinervaUI will now prefix any icons with `minerva`
* Update definitions in skin.json, retaining selectors for cached
HTML for icons that are rendered via PHP.
* In I9021c53c2c04bdd7ce395eed33d89986acbfea6d watch and watched
and arrow are moved to MobileFrontend so are removed from the RL module
skins.minerva.icons.images.scripts as they are not
used directly in this repo. user and anonymous are no longer used
so also removed.
* Presentation of userpage now belongs to MobileFrontend. Icons
are styles were moved there in depends on. They are retained in
skin.json to support cached HTML as user pages are subject to
cache. They can be removed in a week.
* In code review we noticed the anonymous icon was badly named. We
rename to login. No caching implications.
* Main menu icons are now prefixed with minerva rather than mf to
reflect where they come from.
Depends-On: I9021c53c2c04bdd7ce395eed33d89986acbfea6d
Bug: T182162
Change-Id: I93264024f4915fc910c792b1905b89cdc6b8b546
Important note: Make sure to distinguish unseen from unread
One way to reproduce minerva and non-minerva notification inconsistencies:
- Have all your alerts and notices seen. This is displayed with grayed out
number on vector skin or no number at all, if you have (marked as) read.
- Generate new alert or notice (one is enough) in your preferred way.
- You can check minerva and non-minerva at this step. Both should be in sync.
But don't perform any additional action.
- Open the notification popup in some non-minerva skin (I have tried with
vector and monobook), marking it as seen.
- Check the notification icon in minerva. At this point, you should see
notification displayed as unseen.
The reason bug appeared in the first place is that alert/notice timestamps
were mixed up when seen time is obtained. We get seen time from
EchoSeenTime class, where we get smaller of the two timestamps,
using PHP method `min()`. See I27109ee6a248. Then, we get last unread
notification timestamp (which can be either alert or notice), and compare
that to seen time. That leads to the situation when you have only one of
alerts or notices with unread items, smaller timestamp is used for seen,
and most recent for unread, at which point we compare timestamps for
two separate things.
Previous behavior of getting seen timestamps (using max instead of min) would
probably solve the problem, but some other inconsistencies might arrise.
This should prevent any weird and unpredictable behavior to happen.
Bug: T183076
Change-Id: I20bbd6c590086b1c3eccf82983aad59eb3144a7a
Changes:
- moved DownloadButtton checks & initialization to separate function
- introduced supportedNamespaces variable for better readability
- reorganized huge if(){} statement to set of smaller if's with
nice comments why this configuration is not supported
- introduced getAndroidVersion and getChromeVersion helper functions
- added check to not allow Android < 5 or Chrome < 41
- added unit tests
Bug: T182059
Change-Id: Ib5064459ee56aed68179389f37b4bc3b5c2c4492
I used the fix provided by TheDJ and tested out locally
on Firefox 57 and Chrome latest, but I couldn't test out
any grade C browser as on Linux it's really hard to find
such an outdated browser like Internet Explorer on Windows.
Bug: T168716
Change-Id: I8e03610e4eb3c93b80bb757592c2fb3079a68412
To track "download" button interactions we have to notify
EventLogging that button was clicked. The easiest approach is
to use mw.track() and then in WikimediaEvents subscribe to the
`minerva.downloadAsPdf` events and track page impressions.
Bug: T181297
Change-Id: Iecbebe37c165dda3f26af47906662f6e5a81321d
