Move window.location manipulation from ImageOverlay view to MinervaNeue.
Also, don't leave a hanging empty URL fragment when closing the overlay.
Bug: T173539
Related: I292c0578716ff56e0e069aa8006f840025d78a88
Change-Id: I56ba9217aa9cd4e0a925c623060022392e3021c7
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
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
The MinervaDownloadIcon config option is replaced with a
more specific wgMinervaDownloadNamespaces config option.
If the list is empty then the download button will not be
shown.
Since the download icon is enabled everywhere in production now
this is good as it means Minerva reflects the production value.
Bug: T181152
Change-Id: Id78c1de9e8e9013530106bc0d45d3cf0297897b5
As discussed on ticket the download button only appears
to work on Google Chrome on mobile browsers.
Bug: T179529
Bug: T179914
Change-Id: I8bbda8d5a8aa42dd23773fea424c1a70e31d6f85
As documented on the ticket, iOS does not provide PDF functionality
via print.
iOS 11 provides PDF generation but the resulting PDF is unreadable for
our content and missing styles (see T177215#3700576) and we do not know
of any way to invoke that just yet.
Bug: T177215
Change-Id: I7e195ae067625c7865dccee31fa7a2c3c0ee57e5
Shortcut for print. Disabled by default and controlled by
wgMinervaDownloadIcon
Note that with lazy images enabled, images will not appear
in the printed article. This can be easily addressed inside
the onClick function in a later patchset with a few modifications
to the Skin class.
Currently the flag when enabled will show on all browsers. There
are some open questions on the ticket about how we want to limit
the feature. This shouldn't block review or merging.
Bug: T177215
Change-Id: I49f1736870c743990b3fb9916247e07a597b2f59
Since Minerva is the only skin which does this kind of thing, it
was premature to add this logic to the Skin module.
By forcing Minerva to do this itself, we allow MobileFrontend to
be responsible for creating a Skin without having to know about
what that skin may want to load in tablet mode.
(see I8503c26bd064ae0d203f95a35031468c7c678ac1)
Bug: T173454
Change-Id: I32e2b4a10799a06138bfee08abc6769a6b96004d
* Remove deprecated module definitions
* Remove unnecessary check for Minerva skin (this is only
ever run by Minerva skin)
* Move overlayManager to place it is first used
* Make Skin::getMainMenu method redundant
Change-Id: I17ea52172e7fae0a8f0e06b8418c7ed5bb01ef64
This is programmatic output from python3 scripts/migrate.py
This will result in a Minerva skin dependent on MobileFrontend.
Post merge we will rename message keys to have minerva- prefix
Bug: T166748
Change-Id: Iff1f7e63e796cc5d4a6d2ab0370e0c33248d2fce