Moving to mobile-l
Setting the cookie mf_useformat ensures that the mobile site gets loaded.
If tests are run against en.m. etc.. this won't have any effect, but a
lot of local instances are setup to run the desktop URL by default. An
alternative way of doing this would be to toggle to the mobile site
explicitly in the test suite.
e.g.
Given /^I am in the mobile view$/ do
on(ArticlePage).switch_to_mobile_element.click
end
In terms of 2nd question - no I don't think we should abandon trying
to test Nearby in the browser, it is one of our most important
features and has extremely inadequate test coverage and is one of the
things that seems to break the most. Even if the test only works for
Firefox, having that test is a good thing.
On Tue, Mar 18, 2014 at 11:03 AM, Chris McMahon <cmcmahon(a)wikimedia.org> wrote:
>
> I should also mention that part of the change is to update the
> mediawiki-selenium gem to version 2.13. This should make the no_javascript
> tests pass again (along with some similar tests for ULS).
>
>
>
> On Tue, Mar 18, 2014 at 10:36 AM, Chris McMahon <cmcmahon(a)wikimedia.org>
> wrote:
>>
>>
>> Hi Mobilers,
>>
>> Željko and I have been doing a ton of refactoring, moving shared code out
>> of the repositories and into the mediawiki-selenium gem, and removing cruft
>> along the way.
>>
>> We've got the code that makes the user agent spoofing into the gem because
>> MobileFrontend and ULS share that code.
>>
>> We'd like to remove some more code that we believe to be unused, but we
>> need to talk about it here first before that happens. The change is
>> https://gerrit.wikimedia.org/r/#/c/119271/
>>
>> The first question is: is it necessary to set the cookie "mf_useformat"?
>> We don't see that affecting the outcome of any MF tests. If so, we should
>> make that shared code and not hard-code the name and value of the cookie.
>>
>> The second question is: should we abandon trying to test Nearby in a
>> browser? Besides the problems of variable geographic data in both the
>> browser and the target wiki, testing Nearby also relies on managing a SQLite
>> file containing a Firefox profile and manipulating the contents of that
>> file. Even if the test worked, it would only ever work for Firefox. It
>> may be better to test that feature below the browser with appropriate mocks
>> and stubs and what have you.
>>
>>
>>
>>
>>
>
On Wed, Mar 19, 2014 at 2:44 PM, Jon Robson <jrobson(a)wikimedia.org> wrote:
> The problem is it /can't/ be a random page for removing or adding from
> watchlist.
>
For each run of each .feature file we generate a value called
@random_string. That value remains consistent for the run of all the
Scenarios in the Feature, and you can use that value in any way you choose:
as a page title when creating a page, text in a page, anywhere you need a
more-or-less unique string.
Thus you can create a new page using the value for @random_string, then
navigate to that page and manipulate it any way you like -- for instance,
by clicking the Watchlist icon on and off.
page.feature in the browsertests repo is a good example:
https://git.wikimedia.org/blob/qa%2Fbrowsertests/5b59eb8fd0ab0c841826f9a5bc…
-C
> We have to find a page that is already on the watchlist for the test for
> removing from watchlist and for the test adding to watchlist we have to
> ensure we land on a page which is not previously being watched.
>
> We could possibly change these so that one of the Given statements is
> "Given I am already watching the "Foo" article" - this could then ensure
> the article is being watched and vice versa.
>
> A random page cannot be relied on under any circumstances.
>
>
>
> On Wed, Mar 19, 2014 at 2:37 PM, Chris McMahon <cmcmahon(a)wikimedia.org>wrote:
>
>>
>> I fixed it.
>>
>> Since yesterday Cloudbees has unexpectedly given us unlimited Jenkins
>> build executors where before we could only run two builds at once. This
>> has made for a few race conditions, of which this was one.
>>
>> This test should probably create a random page to use for clicking the
>> watchlist on and off.
>>
>> -C
>>
>>
>> On Wed, Mar 19, 2014 at 2:30 PM, Jon Robson <jrobson(a)wikimedia.org>wrote:
>>
>>> They are indeed false positives. I think I know what's happening here.
>>> Basically the tests are not atomic - they are trying to watch an article
>>> that is already watched and have the consequence of making that article
>>> watched. I have an idea of how to fix this.
>>>
>>> Does Watir have a concept of a tear down step?
>>>
>>>
>>> On Wed, Mar 19, 2014 at 1:45 PM, Arthur Richards <
>>> arichards(a)wikimedia.org> wrote:
>>>
>>>> I tested these manually and think they may be false positives, but can
>>>> someone else take a look to make sure these tests and what's in betalabs is
>>>> OK? We should get this resolved asap so we can be sure the state of things
>>>> is healthy on betalabs for tomorrow's deployment.
>>>>
>>>>
>>>> On Wed, Mar 19, 2014 at 12:19 PM, <jenkins-no-reply(a)cloudbees.com>wrote:
>>>>
>>>>> * FAILURE:
>>>>> MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox Build #434
>>>>> <https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…>
>>>>> (Wed, 19 Mar 2014 18:40:00 +0000)*
>>>>> *Test Result*<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…>
>>>>> 2 failed, 1 skipped
>>>>> Failed Tests *Test Name**Duration**Age* Manage Watchlist.Add an
>>>>> article to the watchlist<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> 37
>>>>> sec1<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> Manage
>>>>> Watchlist.Remove an article from the watchlist<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> 38
>>>>> sec1<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> All
>>>>> Tests *Package**Duration**Fail**Skip**Total* (root)<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…>30
>>>>> min2161 Wikitext Editor (TEST RUN ON WIKIPEDIA<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> 1
>>>>> min 14 sec003
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Arthur Richards
>>>> Software Engineer, Mobile
>>>> [[User:Awjrichards]]
>>>> IRC: awjr
>>>> +1-415-839-6885 x6687
>>>>
>>>
>>>
>>
>
The problem is it /can't/ be a random page for removing or adding from
watchlist. We have to find a page that is already on the watchlist for the
test for removing from watchlist and for the test adding to watchlist we
have to ensure we land on a page which is not previously being watched.
We could possibly change these so that one of the Given statements is
"Given I am already watching the "Foo" article" - this could then ensure
the article is being watched and vice versa.
A random page cannot be relied on under any circumstances.
On Wed, Mar 19, 2014 at 2:37 PM, Chris McMahon <cmcmahon(a)wikimedia.org>wrote:
>
> I fixed it.
>
> Since yesterday Cloudbees has unexpectedly given us unlimited Jenkins
> build executors where before we could only run two builds at once. This
> has made for a few race conditions, of which this was one.
>
> This test should probably create a random page to use for clicking the
> watchlist on and off.
>
> -C
>
>
> On Wed, Mar 19, 2014 at 2:30 PM, Jon Robson <jrobson(a)wikimedia.org> wrote:
>
>> They are indeed false positives. I think I know what's happening here.
>> Basically the tests are not atomic - they are trying to watch an article
>> that is already watched and have the consequence of making that article
>> watched. I have an idea of how to fix this.
>>
>> Does Watir have a concept of a tear down step?
>>
>>
>> On Wed, Mar 19, 2014 at 1:45 PM, Arthur Richards <arichards(a)wikimedia.org
>> > wrote:
>>
>>> I tested these manually and think they may be false positives, but can
>>> someone else take a look to make sure these tests and what's in betalabs is
>>> OK? We should get this resolved asap so we can be sure the state of things
>>> is healthy on betalabs for tomorrow's deployment.
>>>
>>>
>>> On Wed, Mar 19, 2014 at 12:19 PM, <jenkins-no-reply(a)cloudbees.com>wrote:
>>>
>>>> * FAILURE:
>>>> MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox Build #434
>>>> <https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…>
>>>> (Wed, 19 Mar 2014 18:40:00 +0000)*
>>>> *Test Result*<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…>
>>>> 2 failed, 1 skipped
>>>> Failed Tests *Test Name**Duration**Age* Manage Watchlist.Add an
>>>> article to the watchlist<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> 37
>>>> sec1<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> Manage
>>>> Watchlist.Remove an article from the watchlist<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> 38
>>>> sec1<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> All
>>>> Tests *Package**Duration**Fail**Skip**Total* (root)<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…>30
>>>> min2161 Wikitext Editor (TEST RUN ON WIKIPEDIA<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> 1
>>>> min 14 sec003
>>>>
>>>
>>>
>>>
>>> --
>>> Arthur Richards
>>> Software Engineer, Mobile
>>> [[User:Awjrichards]]
>>> IRC: awjr
>>> +1-415-839-6885 x6687
>>>
>>
>>
>
Due to human error we've pointed all of our wiki projects nearby pages
to hit English Wikipedia. This is bad for many reasons
1) Broken links on production on all our wikis other than enwiki
2) enwiki now jsonps itself.
3) enwiki will now get the sum of all traffic across all our projects
for the nearby page (can it cope?!)
4) projects like French Wikipedia will get English results on Nearby.
For these reasons I suggest we lightning deploy this asap:
https://gerrit.wikimedia.org/r/#/c/119416/
In terms of acceptance tests to protect this from happening again -
this is not really possible due to the longstanding issues we are
having with being able to test nearby with browser tests.
Mobile web folks, there's been some recent conversation happening on bug
61114 (https://bugzilla.wikimedia.org/show_bug.cgi?id=61114) - "Option
labels on the mobile preferences page can be too long".
It looks like there has been some consensus to a path forward for better
localization support. Since this bug has been in our backlog, I figured the
conversation happening there may not be on everyone's radar and wanted to
make sure this got flagged (particularly with Kenan).
I suspect this should be fairly trivial to implement - Kenan can we tackle
this one soon, either in the upcoming iteration or what will likely be a
bug fixing/hygiene-focussed iteration around quarterly planning (happening
in two weeks)?
--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
by The International Conference on Computing Technology and Information Management (ICCTIM2014)
***************************************************************************
We apologize for multiples copies. Please circulate this CFP among your
colleagues and students.
***************************************************************************
[ICCTIM 2014] The International Conference on
Computing Technology and Information Management
Important Dates
Paper due: March 20, 2014
Author Notification: March 25, 2014 or 4 weeks from the submission date
Camera-ready due and Registration: March 31, 2014, however, it is
recommended to do it few days before
Conference Date: April 9-11, 2014
****************************************************************************
For more information: http://sdiwc.net/conferences/2014/icctim2014/
To submit your paper:
http://sdiwc.net/conferences/2014/icctim2014/openconf/openconf.php
****************************************************************************
All registered papers will be published in one of the following special
issues provided that the author do major improvements and extension within
the time frame that will be set by the conference and his/her paper is
approved by the chief editor:
International Journal of New Computer Architectures and their Applications
(IJNCAA)
International Journal of Digital Information and Wireless Communications
(IJDIWC)
International Journal of Cyber-Security and Digital Forensics (IJCSDF)
International Journal of E-Entrepreneurship and Innovation (IJEEI)
International Journal of E-Services and Mobile Applications (IJESMA)
International Journal of Information Technology Project Management (IJITPM)
International Journal of Multimedia Data Engineering and Management (IJMDEM)
International Journal of Service Science, Management, Engineering, and
Technology (IJSSMET)
Moved to mobile-l :)
On Tue, Mar 11, 2014 at 5:12 PM, Kenan Wang <kwang(a)wikimedia.org> wrote:
> Beginning of mobile app event logging requirements:
>
> https://www.mediawiki.org/wiki/Event_logging/MobileApp
>
> Apps team, please take a look and let me know what you think...
>
> --
>
> Kenan Wang
> Product Manager, Mobile
> Wikimedia Foundation
>
--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
Does anyone know the answer to this question on the extension talk
page? If so could you reply?
---------- Forwarded message ----------
From: MediaWiki Mail <wiki(a)wikimedia.org>
Date: Thu, Mar 13, 2014 at 9:35 AM
Subject: MediaWiki discussion - New thread: X-Analytics/mobile tracking?
To: Jdlrobson <jdlrobson(a)gmail.com>
Hi Jdlrobson,
this is a notification from MediaWiki that a new thread on Extension
talk:MobileFrontend, 'X-Analytics/mobile tracking?',
was created on 13 March 2014 at 16:35 by Kchurch05
You can see it at
<http://www.mediawiki.org/w/index.php?title=Extension_talk:MobileFrontend&of…>
The text is:
We're using Piwik and Google Analytics, and currently the only way we
can determine whether a visitor used our wiki on a mobile device is
via the browser model, since we don't have a mobile URL -- and even
then it's not 100% accurate, since some people prefer to use the
desktop version of the site instead of the mobile version.
I did a search and saw
[https://wikitech.wikimedia.org/wiki/X-Analytics this article] on
[[Analytics/Kraken/Data Formats|X-Analytics]]. I'm not a MW expert so
I'm not 100% clear on what X-A does, and from the code linked it seems
to only track whether a user is in alpha or beta mode.
We're currently running MW 1.21 so the X-Analytics doesn't seem to be
included in that MobileFrontend version. Hopefully we'll upgrade ASAP,
but I wanted to see if this was a way to get better data on mobile
usage of our wiki.
Thanks all!
--
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon
Hello!
I just setup a super easy way for Android users to try out the
rewritten, new Wikipedia app without having to download and install
new APKs every now and then. Simple steps:
1. Join the alpha testers group:
https://groups.google.com/forum/#!forum/wpandroidapptesters. Make sure
you use the same Google Account that is used on the Play store on your
Android device (you can check this by opening the play store app, and
opening the left nav drawer)
2. Go to https://play.google.com/apps/testing/org.wikipedia and opt-in
to alpha. Note that you need to have completed step 1 first, otherwise
this URL will be a 404. Again, make sure it is the same Google
account.
3. Install the wikipedia app from the link at the bottom of the page
on step2. It should just take you to the regular play store and let
you install. It should show up on your phone shortly (assuming it is
the same Google account).
Next time we push out an alpha (rather frequently, I imagine), your
phone will automatically update to the new version without you having
to do anything! This is also open to anyone (with a Google account).
Try it out, and send us feedback! (Use the 'send feedback' button in
the app :)).
--
Yuvi Panda T
http://yuvi.in/blog