I just wondered if anyone doing MediaWiki development had any
experience in catching CSS regressions?
We have had a few issues recently in mobile land where we've made big
CSS changes and broken buttons on hidden away special pages -
particularly now we have been involved in the development of mediawiki
ui and moving mobile towards using them.
My vision of how this might work is we have an automated tool that
visits a list of given pages on various browsers, take screenshots of
how they look and then compares the images with the last known state.
The tool checks how similar the images are and complains if they are
not the same - this might be a comment on the Gerrit patch or an
e-mail saying something user friendly like "The Special:Nearby page on
Vector looks different from how it used to. Please check everything is
okay."
This would catch a host of issues and prevent a lot of CSS regression bugs.
Any experience in catching this sort of thing? Any ideas on how we
could make this happen?
Here is a report of current mobile upload errors that have occurred in
the last 30 days. It appears that are main source of errors are around
filenames and bad tokens/expired logged in sessions. Let's try and cut
these down [1,2].
What is strange is none of the filenames look bad - 2 examples being:
"Cheatahs_play_a_live_show_at_Amoeba_music_2014-03-01_16-52.jpg"
"Colonel_Reynolds_in_Iraq-_2014-02-05_23-28.jpg"
Does anyone see any issues with the above names?
Help much appreciated...
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=62587
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=62241
Full breakdown of errors...
== Server problems ==
An internal error occurred 28
upload/error/http 26
Database query error 25
parsererror: SyntaxError: Unexpected token < 8
error: Internal Server Error 4
error: Bad Gateway 4
upload/error/autoblocked 2
internal_api_error_DBQueryError 1
edit/error/http 1
== Token errors ==
Invalid token 3468
Bad token name. 1983
Anonymous token. 1574
badtoken 195
Failed to retrieve token. 172
upload/error/badtoken 52
edit/error/badtoken 4
== Abuse filter problems ==
abusefilter 161
edit/abusefilter 45
verification-error abusefilter-disallowed 2
edit/error/autoblocked 1
== Captcha ==
captcha 1
== Permissioning problems ==
You have been blocked from editing 681
Unknown error: "titleblacklist-forbidden-edit" 323
Your IP address has been blocked automatically, because it was used by
a blocked user 133
The "autoconfirmed" right is required to edit this page 110
blocked 83
edit/error/blocked 29
The "protect" right is required to edit this page 22
The "editprotected" right is required to edit this page 22
upload/error/blocked 16
Unknown error: "wikimedia-globalblocking-ipblocked" 14
Unknown error: "globalblocking-ipblocked" 13
autoblocked 11
The "editsemiprotected" right is required to edit this page 11
The wiki is currently in read-only mode 4
edit/error/protectedpage 3
protectedpage 2
The "templateeditor" right is required to edit this page 1
== Edit conflicts ==
Edit conflict detected 96
editconflict 2
== File type problems ==
Bad filename: * 6806
This file did not pass file verification 588
Missing filename: Duplicate archive 1534
verification-error filetype-mime-mismatch 49
empty-file 8
Filetype not permitted: bmp 30
Filetype not permitted: docx 1
Filetype not permitted: m4a 3
Filetype not permitted: MOV 31
Filetype not permitted: mp3 7
Filetype not permitted: mp4 5
Filetype not permitted: txt 1
Filetype not permitted: webp 15
Filetype not permitted: xml 2
Filetype not permitted: zip 1
filetype-banned 22
Filename exists 52
Missing filename 774
Missing filename: Bad filename 356
Missing filename: Filename exists 270
The file you submitted was empty 149
The file you submitted was too large 8
The filename is not allowed 11
Unknown error: "titleblacklist-custom-double-apostrophe" 10
Unknown error: "titleblacklist-custom-filename" 853
Unknown error: "titleblacklist-custom-hidden-char" 15
Missing filename: Unknown warning {"exists-normalized":* 8
Missing filename: Unknown warning {"bad-prefix":"* 93
upload/warning/badfilename/* 184
upload/warning/exists/* 5
upload/warning/exists-normalized/* 3
upload/warning/duplicate-archive/* 59
upload/warning/bad-prefix/* 2
upload/error/verification-error/filetype-mime-mismatch 13
upload/error/verification-error/zip-bad 1
upload/error/filetype-banned 2
upload/error/empty-file 1
== Other ==
error: 833
error: Error: INVALID_STATE_ERR: DOM Exception 11 1
Exception Caught: Error: invalid magic word 'noexternallanglinks' 9
Exception Caught: The calling convention to LinksUpdate::__construct()
has changed. Please see WikiPage::doEditUpdates() for an invocation
example.↵ 6
The modification you tried to make was aborted by an extension hook 222
upload/error/unknownerror 55
unknownerror 157
undefined/undefined 4
On this page - https://en.m.wikipedia.org/wiki/Special:MobileOptions -
it is possible to disable images across the mobile site.
How many people actually use this (outside Zero)? Can we get some data?
I personally think we should explore killing this feature as an option
and leave it to the browser to take care of...
You can now apply the mobile skin to the desktop site [1]. Wahhhh?!
To cut a long story short, to help MobileFrontend and VisualEditor
integrate nicely with one another, we needed the mobile skin to be
registered as a valid skin. We've previously avoided this as we didn't
want to surface this in the Special:Preferences (a side effect of
doing so). Kaldari however found a way we can supress it there, so
thus we went and registered it [1].
I encourage editors to check how their stuff looks in the minerva skin
on a small window size. This should make mobile optimisation a lot
easier for you! :)
[1] http://en.wikipedia.beta.wmflabs.org/wiki/Forty-seven_Ronin?useskin=minerva
[2] https://gerrit.wikimedia.org/r/#/c/118037/
Another note in case you missed it earlier. If your'e looking in general to
test the Wikipedia app reboot, at the moment the Android APK can be
downloaded from
https://releases.wikimedia.org/mobile/android/apps-android-wikipedia-sprint…
bugs can be filed via Bugzilla. The iOS build is currently internal
due
to installation limits, although simulator and debugging stuff can be done
on the latest beta of Xcode.
I also forgot to mention my peer Yuri's great work! The guy knuckled down
to considerably revise Varnish scripts, reviewed and helped me improve
code, and offered really good advice on API-app interaction. Thanks Yuri!
-Adam
On Wed, Mar 5, 2014 at 4:16 PM, Adam Baso <abaso(a)wikimedia.org> wrote:
> I realized I should be clear that the "rebooted apps" I mention are "the
> future Wikipedia mobile app"s mentioned earlier in the thread. Sorry if any
> confusion.
>
> -Adam
>
>
> On Wed, Mar 5, 2014 at 11:43 AM, Adam Baso <abaso(a)wikimedia.org> wrote:
>
>> +mobile-l
>>
>> Greetings. Rupert, an update!
>>
>> The rebooted Android (Android 2.3+) and iOS (iOS 6+) apps will have
>> Wikipedia Zero flourishes built into them, making it possible for the user
>> to know whether the app access is free of data usage charges. The rebooted
>> apps are tentatively slated for store submission at the end of the month.
>> The flourishes will hinge on each operator's zero-rating of HTTPS.
>>
>> Likewise, HTTPS contributory features are about to be introduced on the
>> Wikipedia Zero mobile web experience as well for operators that zero-rate
>> HTTPS.
>>
>> WMF is starting the work with partner operators to add support for
>> zero-rating of HTTPS. There will be, at least, technical hurdles
>> (networking equipment architecture varies) in this transition, but it's
>> underway! Indeed, we have some carriers that have noted support for HTTPS
>> zero-rating already.
>>
>> I'm very much grateful to Brion, Yuvi, and Monte for their assistance
>> while I added code to the Android and iOS platforms, and am happy to get to
>> work with them more while putting final touches in place this month. Props
>> to Faidon, Mark, and Brandon in Ops Engineering as well on helping us
>> overcome some rather non-trivial hurdles in order to retain good
>> performance and maintainability while adding HTTPS support.
>>
>> -Adam
>>
>>
>> On Mon, Aug 26, 2013 at 3:34 PM, Brion Vibber <bvibber(a)wikimedia.org>wrote:
>>
>>> On Mon, Aug 26, 2013 at 8:19 AM, Adam Baso <abaso(a)wikimedia.org> wrote:
>>>
>>> > Rupert, I saw your question regarding Wikipedia Zero. Wikipedia Zero is
>>> > currently targeted for the mobile web, but I'll take this question
>>> back to
>>> > the business team as to whether we'd be able to support zero-rating of
>>> apps
>>> > traffic at some point in the future, at least in locales where moderate
>>> > bandwidth is available.
>>> >
>>>
>>> I think that once the zero-rating is switched to support HTTPS by using
>>> IP-based instead of Deep Packet Inspection-based HTTP sniffing, ISP
>>> partners wouldn't actually be able to distinguish between mobile web and
>>> mobile apps content unless we actively choose to make them use separate
>>> IPs
>>> and domain names.
>>>
>>> Especially if, as we think we're going to, the future Wikipedia mobile
>>> app
>>> will consist mostly of native code widgets and modules that plug into the
>>> web site embedded in a web control... it'll be loading mostly the same
>>> web
>>> pages from the same servers, but running a different mix of JavaScript.
>>>
>>> -- brion
>>> _______________________________________________
>>> Wikitech-l mailing list
>>> Wikitech-l(a)lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>>
>>
>
Latest Wikimedia-internal iOS build on TestFlight -- anyone working for
Wikimedia who wants to test but didn't get the email please let me know and
I'll get you set up. Currently we can only do internal beta distribution
for iOS, but we hope to be able to do wider testing again soon.
Public Android build at
https://releases.wikimedia.org/mobile/android/apps-android-wikipedia-sprint…
Note that both versions of the beta app now support logging in, creating
accounts (with captcha), and basic wikitext editing.
iOS version now includes optional edit summaries, with an experimental
'canned summary' feature where you can select some common notes.
There are also updated localizations from translatewiki.net -- please give
a shout if there are obvious problems with the UI not matching the phone's
system language; it's our first build since the new updates went in.
Coming soon:
Android edit summaries didn't quite make it through review yet, but should
be available in a beta update in a couple days.
Random-article feature is also coming on both platforms, needs some slight
tweaking but should be ready in next build.
-- brion
After a lot of analysis, discussions and preparations, today we announce
that WAP/WML support has been removed from MobileFrontend. Our sites
were running HTML only for a couple weeks now, so since we received no
complaints, we pulled the trigger. Final deprectation might take a
couple more weeks, but we're already beyond the point of no return.
I would like to thak everyone who participated in this effort!
This wasn't an easy decision, however the share of WAP has fallen
tremendously and we can find better use for engineering resources we
would have needed to maintain WAP support functional.
--
Best regards,
Max Semenik ([[User:MaxSem]])
In the beta mode of mobile, due to the features having no tests we
broke nearby pages.
There is a bug for this and the fix provides some browser tests
https://bugzilla.wikimedia.org/62294
1) Can someone help with review for this
2) Do we want to lightning deploy a fix, or are we happy to have
nearby broken on production wikis for a week?