Dynamic Type is a feature in iOS that lets users pick their reading size
so that apps can adjust their text size accordingly. This commit makes
the mobile site hook into that feature. If you go to
settings > Accessibility > Larger Text in iOS and increase or decrease
the reading size, the mobile site will now increase / decrease
its text size relative to that setting.
Notable changes:
* Moved `font-size: 100% * @fontScalingFactor` from html to body. This
rule would override Dynamic Type sizing which would effectively disable
it. Moving it to the body makes the rule be relative to Dynamic Type
instead of overriding it in iOS browsers while browsers that don't
support Dynamic Type should observe no visible changes.
* Removed intermediate variable @bodyLineHeight because it was only
being used in one place.
* Added @font-size-body-mobile and made it based on % instead of em
(which is what @font-size-body uses). @font-size-mobile-bod is used by a
media query in browsers that support Dynamic Type and by another media
query in browsers that don't support Dynamic Type.
* Added a feature query for Dynamic Type which will make Dynamic Type CSS
rules only affect browsers that support Dynamic Type. This limits the
feature to iOS 9+ feature but ensures that the css rules don't affect
browsers that don't support Dynamic Type.
* Scaled down Dynamic Type so that its default size would appear
identical to the common browser default text size of 16px. By not doing
this, the default font size in iOS browsers would be 17px (Dynamic
Type's default) and would appear 1px larger than Android browsers.
Bug: T204807
Change-Id: I8a4d621dba8dc56190bd8c974543d08dd374ba5e
Goal: Make skins.minerva.editor not rely on Minerva-specific markup.
SkinMinerva.php:
* Add `class="mw-editsection"` to section edit links in SkinMinerva.
This is the default behavior in SkinTemplate.
* Tweak the page "Edit" link generated in PHP to be the same as the
link we were generating in JS: add class="edit-page" and change the
message for the text.
* (Fix an unrelated code comment that was incorrect.)
skins.minerva.content.styles/hacks.less:
* Remove a hack that was hiding .mw-editsection, since we now use it.
skins.minerva.editor/init.js:
* Stop using the `data-section` attribute on links to decide which
page section to open in the editor. Instead, use the `href`
attribute and extract the `section` URL parameter from it.
* Stop using the `edit-page` class to find section edit links.
Instead, use the `mw-editsection` class.
* Remove super weird code that removed the original "Edit" link from
the page and generated an identical one to replace it, instead of
just adding event handlers to the existing one.
* Centralize event handling for all types of edit links.
Bug: T198765
Change-Id: I79639c738ff1c3ec4b48ee2e462d23060151a21b
These CSS classes are specific to the Minerva skin and we want to move
this file to MobileFrontend.
Now that this code is all in one place, I noticed that it seems to not
do much at all… Everything in this function looks like it could just
be done in the PHP code. If PHP does it all, then we could remove all
of it for a free performance improvement.
Bug: T198765
Change-Id: I6487c2fc520e14e0856b2e9a6f9dfa5066205817
For non-web-apps we can still control the color of the address and
status bar. Currently this is defined in MobileFrontend)
but is configurable if we ever want to change it. If not defined
(e.g. no MobileFrontend/no config) it is not added.
Bug: T204691
Depends-On: I39c0905f86edc4f52235b905850c31257e7f792e
Change-Id: I3ab0f538fb6ae3332574fd212eea1a7ec6a397bd
The $returntoquery variable is created only when request wasn't
posted, but the variable can be accessed on POSTed request.
To fix that issue we need to always define $returntoquery as
an empty array. This is done in order to prevent leak of
any sensitive data sent by POST request.
The sample error from fatalmonitor:
Undefined variable: returntoquery in
skins/MinervaNeue/includes/skins/SkinMinerva.php on line 701
Bug: T205449
Change-Id: I20e5955ddcb99c110a3dc03fb3b56c1904601453
The fancy mobile editor doesn't support undo, but we can just use the
fallback (no-JS) editor. The experience is not very friendly (e.g. due
to two-column diff), but it works.
Previously we showed an old-school alert() message and then loaded the
fancy editor as if it was a normal edit, ignoring the undo parameters.
The whole thing is rather hypothetical, since there are no links to undo
in the mobile interface. See T191706.
Bug: T191706
Change-Id: I5147ada9e85d9188f19ae898fdd411985d19182f
* Page edit action (#ca-edit)
I guess it became always visible when no-JS editing was implemented?
* User page creation CTA (.edit-link)
I'm making it always visible in Ie2fc6d43ebc03626517eec21bf4738dca05152d0
(which also makes it available for no-JS editing).
* Section edit links for nested sub-sections (.in-block > .edit-page)
No idea about these, but they are clearly always shown (even in
non-article namespaces).
Depends-On: Ie2fc6d43ebc03626517eec21bf4738dca05152d0
Change-Id: I226cb1fd1e716078a4a34ed8349d5304428964cf
This is a MobileFrontend feature, implemented
in ExtMobileFrontend::getUserPageContent().
Having the test for it in the Minerva repo made
it harder to make changes to it. Adding it there
in I6e763cd6b6763c60d2ad47bf384f739dfb1a07c0.
Depends-On: I6e763cd6b6763c60d2ad47bf384f739dfb1a07c0
Change-Id: Id1692b50f3f0d282c8aea4c45b63845f418e0970
This reverts commit 6daf19dfb5.
Mobilefrontend change was reverted meaning this test should be
restored here so we continue to have coverage.
Change-Id: I2e8eeacaf01aa61040405501d69f329fe3a9bbd6
It was limited to the main namespace since its introduction in
Ieabe8f7071696cde6afbdc6df853aacdb741a4a3. Unfortunately that
commit does not explain the reason.
It should be shown e.g. on user pages (so that sandbox pages
look like the real article) or on project pages (many policy
or help pages on Wikipedia are long and would benefit from it).
It looks like some of the CSS code already assumed that the
TOC would be shown in all namespaces (space for it was reserved
using a 'visibility: hidden;' element on all pages).
Bug: T205312
Change-Id: Id6935f5a7a3701c1c7a38fb37b48b6a3bbc80393
Config added inside SkinMinerva is subject to the rules of HTML
caching and can take several days [1]
Adding it via the onResourceLoaderGetConfigVars hook reduces the
cache time to minutes [2], giving us more control over the experiment's
enabled state.
[1] T124954
[2] https://www.mediawiki.org/wiki/ResourceLoader
Bug: T205355
Change-Id: I18cb40afe405e2f6a89a7ce5a924eb855aed5430
This is a MobileFrontend feature, implemented
in ExtMobileFrontend::getUserPageContent().
Having the test for it in the Minerva repo made
it harder to make changes to it. Adding it there
in I7cac24cf64422212196439bf49598ed749d5fafa.
Depends-On I7cac24cf64422212196439bf49598ed749d5fafa
Change-Id: I93e0f195b3cad1ae83ee2ae3b5b4c5f08944882e
This code could never be used under normal circumstances since
a crucial bit of it was removed from MobileFrontend in 2015:
(I65e943b6dad8bfea994020f9f555bd095da1a171)
// Allow us to distinguish sign ups from the left nav to logins.
// This allows us to show them an edit tutorial when they return to the page.
if ( $query['returntoquery'] === 'welcome=yes' ) {
$query['returntoquery'] = 'campaign=leftNavSignup';
}
…and honestly, that's for good, because it fails horribly
when triggered by adding &campaign=leftNavSignup to the URL
manually: clicking "Start editing" in the callout navigates
you to an article called "Undefined/leftNavSignup".
Bug: T205325
Change-Id: I0e385488be5b2eaa7d489029b91e18b336c0d133
'returnto' is, in fact, set a few lines above this comment,
since 2013 (I1553ee71f4f9ffec8462e3f9b85de9f39d921204).
Change-Id: I20ab084b3ddf59d338268f00a7f2306c9e2bd2b3
Unlike other skins, Minerva wants to be in charge of when WikimediaEvents
is loaded, so that it can guarantee load order happens at a time that
suits it.
WikimediaEvents will be loaded after initialisation of the interface.
This allows Minerva to enable schemas such as ReadingDepth conditionally.
Upon merging this patch, Ibb45f40ea301727c0c6480043760bd9426106845 can
be merged which will revoke WikimediaEvent's ownership.
Merging in this order will ensure that ReadingDepth is never
removed from production.
Bug: T204144
Change-Id: If8395033f31485aca0ca3b38fda1be985369b481
