Re: [Wikitech-l] Vector skin not working on BlackBerry?
Hi,
On 24 May 2010 21:09, David Gerard wrote:
> On 24 May 2010 20:04, David Gerard wrote:
>
>> Do we have a known graceful-degradation path when a browser is just
>> too crappy to deal with l33t skins like Vector? I'm thinking of the
>> PS3 users here, noisy as they are considering their near-negligible
>> user percentage. ('Cos when you're on a gaming platform, reading an
>> encyclopedia is of course the first use that springs to mind.)
>> Apparently their browser is a NetFront variant.
>
>
> Sending PS3 to mobile as well may be appropriate:
>
> http://www.design215.com/read.php?title=playstation%203%20browser%20specs
>
> Anyone got a PS3 to test on?
>
Yesterday I finally found some time to fire up the PS3 again and look
at the web-browsing. The Mediawiki rendering is indeed not completely
correct. There are large vertical bands of gray layered across the
text: the tabs available at the top of a page are extended downwards
and obscure the text.
I have not yet found a way to look at it in another way than actually
browsing, so it may be difficult to investigate further. If anyone has
ideas/suggestions on how to show/report the rendering, then just let
me know (if you want I can take some shots with the digital camera and
upload them somewhere).
--
Regards,
Jean-Marc
--
. ___
. @@ // \\ "De Chelonian Mobile"
. (_,\/ \_/ \ TortoiseSVN
. \ \_/_\_/>The coolest Interface to (Sub)Version Control
. /_/ \_\ http://tortoisesvn.net
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] New committers
Extension access only: * Liangent: CategoryMultisort extension * Andrew Whitworth (whiteknight): EmbedVideo and EmbedVideoPlus * Garrett Brown (gbruin): FBConnect * Hampton Catlin (hcatlin): webstatscollector -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium testing framework- Firefox browsers compatible
On Wed, 26 May 2010 17:11:33 -0700, Michelle Knight wrote: > Hi Dan, > > There is a list of browsers compatible with Selenium (See > http://seleniumhq.org/about/platforms.html#browsers ). The page states > that Selenium works with Firefox 2+ when a Linux OS is used (I think > Ubuntu would fall under this category ). > > I am using Firefox 3.5.9 on Ubuntu 9.10 . I have been finishing another > project (my grandfather visited me in Oregon from Ohio) and have not > played with the at the Selenium Framework since May 14th. I will let you > know if I see the error messages. > > Michelle Knight > > > > Message: 5 > Date: Tue, 18 May 2010 17:44:03 + (UTC) From: Dan Nessett > Subject: Re: [Wikitech-l] Selenium testing > framework To: wikitech-l@lists.wikimedia.org > Message-ID: Content-Type: text/plain; > charset=UTF-8 > > On Tue, 18 May 2010 19:27:38 +0200, Markus Glaser wrote: > >> Hi Dan, >> >> I had these error messages once when I used Firefox 3.6 for testing. >> Until recently, Selenium did not support this browser. Apparently now >> they do, but I did not have a chance to test this yet. So the solution >> for me was to point Selenium to a Firefox 3.5. >> >> Cheers, >> Markus > > My OS is Ubuntu 8.04. The version of Firefox is 3.0.19. Since Ubuntu > automatically updates versions of its software, I assume this is the > most up-to-date. > > Is there a list of browser versions compatible with selenium? Thanks for the pointer to the list, Michelle. As it turned out there was bug in RunSeleniumTests that accessed global data before LocalSeleniumSettings was included. Markus has fixed this problem and is testing it before checking it in to the repository. Before this fix is available, you should put all your local configuration data in RunSeleniumTests. Regards, Dan -- -- Dan Nessett ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium testing framework- Firefox browsers compatible
Hoi, Selenium is not compatible with Ubuntu.. Thanks, GerardM On 27 May 2010 02:11, Michelle Knight wrote: > Hi Dan, > > There is a list of browsers compatible with Selenium (See > http://seleniumhq.org/about/platforms.html#browsers ). The page states > that > Selenium works with Firefox 2+ when a Linux OS is used (I think Ubuntu > would > fall under this category ). > > I am using Firefox 3.5.9 on Ubuntu 9.10 . I have been finishing another > project (my grandfather visited me in Oregon from Ohio) and have not played > with the at the Selenium Framework since May 14th. I will let you know if I > see the error messages. > > Michelle Knight > > > > Message: 5 > Date: Tue, 18 May 2010 17:44:03 + (UTC) > From: Dan Nessett > Subject: Re: [Wikitech-l] Selenium testing framework > To: wikitech-l@lists.wikimedia.org > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > On Tue, 18 May 2010 19:27:38 +0200, Markus Glaser wrote: > > > Hi Dan, > > > > I had these error messages once when I used Firefox 3.6 for testing. > > Until recently, Selenium did not support this browser. Apparently now > > they do, but I did not have a chance to test this yet. So the solution > > for me was to point Selenium to a Firefox 3.5. > > > > Cheers, > > Markus > > My OS is Ubuntu 8.04. The version of Firefox is 3.0.19. Since Ubuntu > automatically updates versions of its software, I assume this is the most > up-to-date. > > Is there a list of browser versions compatible with selenium? > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium testing framework- Firefox browsers compatible
Gerard Meijssen schrieb: > Hoi, > Selenium is not compatible with Ubuntu.. > Thanks, >GerardM works fine for me -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium testing framework- Firefox browsers compatible
Hoi, I read some more about this.. It turns out that even though I asked for an update, the software did not update. I just upgraded from release 1.02 to 1.07 and now it works. The documentation states that from 1.05 updates are pushed. Thanks, GerardM On 27 May 2010 21:21, Daniel Kinzler wrote: > Gerard Meijssen schrieb: > > Hoi, > > Selenium is not compatible with Ubuntu.. > > Thanks, > >GerardM > > works fine for me > > -- daniel > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Revisiting becoming an OpenID Provider
Here's the last post I could find on the subject: > For my part, I'm firmly against joining the "provider but not > consumer" camp. It's of no benefit to anyone . . . I just thought of a great benefit, however. Consider this true scenario: I want to write a MediaWiki API client for editors; something like the Wordpress Dashboard. Really give editors a modern web experience. I'd want to do this as a Rails app: I could build it quickly and find lots of collaborators via GitHub. But there's one problem: people would need to log in to Wikipedia *through my app*. They'd have to enter their username and password to my app, which would turn around an authenticate via the MediaWiki API. Policy-wise, this isn't a good thing; that is, giving people the message that it's ok to type in your credentials to something other than Wikipedia sites. And I believe that this is why no such app exists. And further, why the only similar apps that have been made were fat clients, and e.g. Windows only. Because then, the credentials stay on the user's computer. But imagine: If Wikipedia was an OpenID Provider, or provided OAuth, then my Rails app would be the OpenID Consumer. It'd send people to Wikipedia to log in, and they'd bounce back and begin using the Rails app. My app would never see any private information. I believe this would encourage a new wave of 3rd party app development; everything from big ambitious projects (like my editor dashboard) to small focussed apps (say, a simple web app just for editing one's talk page). Just thinking out loud here! Robb ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Revisiting becoming an OpenID Provider
On Thu, May 27, 2010 at 6:13 PM, Robb Shecter wrote: > Here's the last post I could find on the subject: > >> For my part, I'm firmly against joining the "provider but not >> consumer" camp. It's of no benefit to anyone . . . > Not totally sure who wrote that. It may have been a while ago though. Some context would be good. > I just thought of a great benefit, however. Consider this true > scenario: I want to write a MediaWiki API client for editors; > something like the Wordpress Dashboard. Really give editors a modern > web experience. I'd want to do this as a Rails app: I could build it > quickly and find lots of collaborators via GitHub. > > But there's one problem: people would need to log in to Wikipedia > *through my app*. They'd have to enter their username and password to > my app, which would turn around an authenticate via the MediaWiki API. > Policy-wise, this isn't a good thing; that is, giving people the > message that it's ok to type in your credentials to something other > than Wikipedia sites. > > And I believe that this is why no such app exists. And further, why > the only similar apps that have been made were fat clients, and e.g. > Windows only. Because then, the credentials stay on the user's > computer. > This really calls for OAuth support. As a warning, it is very likely your application will be blocked if you store user credentials in your third party app. OAuth support was originally brought up about a year ago because of a third party app that did this. > But imagine: If Wikipedia was an OpenID Provider, or provided OAuth, > then my Rails app would be the OpenID Consumer. It'd send people to > Wikipedia to log in, and they'd bounce back and begin using the Rails > app. My app would never see any private information. > > I believe this would encourage a new wave of 3rd party app > development; everything from big ambitious projects (like my editor > dashboard) to small focussed apps (say, a simple web app just for > editing one's talk page). > OAuth and OpenID as both a provider and a consumer were discussed at the Berlin developer's workshop, and everyone seemed to agree that all three were a good idea. OAuth and OpenID can and should be worked separately. I was planning on working on all three. I don't have time to tackle this right now. If you want to submit patches for OAuth, I'm sure you'll get some good feedback, and will get inclusion if done properly. You may want to do an RFC beforehand. Consumer support for OpenID is likely going to be more difficult, and will happen much later than OAuth or OpenID as a provider. Neither OAuth nor OpenID are likely to get dedicated developer time in the immediate future. Respectfully, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Revisiting becoming an OpenID Provider
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 37-01--10 03:59 PM, Robb Shecter wrote: > But there's one problem: people would need to log in to Wikipedia > *through my app*. They'd have to enter their username and password to > my app, which would turn around an authenticate via the MediaWiki API. > Policy-wise, this isn't a good thing; that is, giving people the > message that it's ok to type in your credentials to something other > than Wikipedia sites. This is a perennial problem for many Toolserver tools as well. It has resulted in such hacks as http://toolserver.org/~magnus/tusc.php - an OpenID-based solution is clearly preferable. - -Mike -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkv/EHAACgkQst0AR/DaKHubPgCgwuiG2fx3CvyaVOTsNKV5prxt FdYAoNpM28CKWkssnAdO6xINlgjkKP9w =JAuM -END PGP SIGNATURE- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Revisiting becoming an OpenID Provider
I could see some real use cases for OAuth. Especially with regards to the cases mentioned above. People could potentially build apps like AWB and Huggle using OAuth. In general I think this would be a "cool thing" to have for all MediaWiki installs. As for being an OpenID provider... only one major thought: Having this Foundation be a provider would be a lot of additional server load (It is 100% non-cacheable) without any benefit to the main goal of providing free information. -- Jon [[User:ShakataGaNai]] / KJ6FNQ http://snowulf.com/ "This email should not be used to sue me" -- Bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Revisiting becoming an OpenID Provider
On Thu, May 27, 2010 at 7:08 PM, Jon Davis wrote: > I could see some real use cases for OAuth. Especially with regards to the > cases mentioned above. People could potentially build apps like AWB and > Huggle using OAuth. In general I think this would be a "cool thing" to have > for all MediaWiki installs. > > As for being an OpenID provider... only one major thought: Having this > Foundation be a provider would be a lot of additional server load (It is > 100% non-cacheable) without any benefit to the main goal of providing free > information. > The biggest immediate benefit to becoming a provider is for non-MediaWiki based apps that the foundation uses. If we become a provider, our Wordpress, Bugzilla, Ideatorrent, etc. apps don't need to have separate username/password databases. As someone mentioned earlier, it would be extremely useful for the toolserver. Even for third-party applications, if we just provide OAuth, they would still need to handle user account databases, and that isn't optimal. It is especially less optimal for WMF users, who would need to have user accounts in a number of spots, and possibly have to remember multiple passwords. Respectfully, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Anyone with CSS fu that can help out on Flagged Revs?
Hi everyone, One thing we're struggling with right now is getting a chunk of the Flagged Revs UI to look right. None of us working on Flagged Revs right now are CSS gurus, and the people that we have at Wikimedia Foundation that are really good with CSS are buried in other work, so we could really use some help. What we're struggling with is that the "[review pending revisions]" with the little lock icon beside it to look right in a cross-browser and cross-skin fashion. A couple of the problems we're seeing: 1. In Vector, the placement of the text can be too high or too low, depending on the browser in use 2. In Monobook, the problem is even worse. For example, in Chrome on Linux, the text hovers way up above article, covering up the "My contributions" link, for example You can see all of this in action here: http://flaggedrevs.labs.wikimedia.org/wiki/Backmasking ..and there are screenshots of the problem here: http://www.pivotaltracker.com/story/show/2937207 Is there anyone here who can look at the CSS and offer up a better version of what's there? Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Revisiting becoming an OpenID Provider
Robb Shecter wrote: > > Consider this true > scenario: I want to write a MediaWiki API client for editors; > something like the Wordpress Dashboard. Really give editors a modern > web experience. I'd want to do this as a Rails app: I could build it > quickly and find lots of collaborators via GitHub. Not to "derail" the open-id idea I think we should support oAuth 100% and it certainly would help with persistent applications and scalability... But ...for the most part you can build these types of applications in pure javascript. Anytime you need to run an api action that requires you to be on the target domain you call a bit of code to iframe proxy that action on the target domain and communicate its results to the client domain with another iframe back to the client. mwEmbed provides iFrame proxy as part of a uniform api request system with the "mw.getJSON()" function. This that lets you just call that function and mwEmbed works out if it needs to spawn a proxy or if it can make the request directly. Presently I hard-code the approved domains, but it would not be difficult to add in process where users could approve domains / applications. We could even do explicit approval for the set of allowable api actions being requested. ( ie edit pages "OK" upload "NO" ) This has been in use for a while and its how the uploading to commons from the English encyclopedia page works with the add-media-wizard gadget. http://bit.ly/9P144i You can test it by simply by enabling that gadget, then while editing click "insert image", then the "upload" button, then upload to commons. ~Right now~ its a pure javascript gadget that is enabled on (en.wikipedia) which calls another gadget on ( commons.wikimedia ) and they setup two-way communication that way. To make things more complicated all the javascript and html proxy pages are hosted on a 3rd domain ( prototype.wikimedia.org ) and its not just simple api calls, rather its full file uploading proxy with progress indicators and two way error interactions. In the context of the mwEmbed gadget this is more complicated than it needs to be. I should package a apiProxy extension that could simplify things like having an actual proxy entry point that does not load the entire set of mediaWiki view page assets on every proxy interaction. Also it could use some HTML5 type enhancements around cross domain communication so the application could send and receive the msgs directly where the domain is approved and the browser supports it. Furthermore some versions of IE have to request user approval for the iFrame to carry user credentials, but this can be avoided with a p3p policy added to the response header. http://bit.ly/13kpV That being said it has worked oky for what I needed it for, and I think it could be used for prototyping the "editors portal" as you have described it. peace, --michael ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Revisiting becoming an OpenID Provider
> > > Not to "derail" the open-id idea I think we should support oAuth 100% > and it certainly would help with persistent applications and scalability... > > I don't think that's a derail at all. I don't know OAuth that well, but it seems to provide the same benefits of OpenID Provider. Now... going to a 100% Ajax solution for apps... :-) Yeah, I've seen that used to solve interesting authentication & session problems. But that does limit the developer pool and range of apps that'll get built. (Witness the current scarcity of web-based auth-enabled wikimedia apps.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Revisiting becoming an OpenID Provider
> Not to "derail" the open-id idea I think we should support oAuth 100% > and it certainly would help with persistent applications and scalability... > > But ...for the most part you can build these types of applications in > pure javascript. Anytime you need to run an api action that requires > you to be on the target domain you call a bit of code to iframe proxy > that action on the target domain and communicate its results to the > client domain with another iframe back to the client. > That is fine for applications that require user interaction, but one of the major benefits of OAuth is that an application can do an action on behalf of a user without their direct interaction; they don't even need to be logged in. Also, OAuth is a standard that is becoming fairly widely used. We shouldn't force third parties to use our custom made solution. That said, the javascript solution could be useful for lightweight applications that don't need to do actions on a user's behalf without direct interaction. Respectfully, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Revisiting becoming an OpenID Provider
On Fri, May 28, 2010 at 12:11 AM, Robb Shecter wrote: >> >> >> Not to "derail" the open-id idea I think we should support oAuth 100% >> and it certainly would help with persistent applications and scalability... >> >> > I don't think that's a derail at all. I don't know OAuth that well, but it > seems to provide the same benefits of OpenID Provider. > OpenID and OAuth are different. The former provides a decentralized, yet single, login service, while the latter provides an authorization service from a consumer application to a provider application. They seem similar at first, but do different things. Both would be nice to have. The following article gives a good idea of the differences: http://softwareas.com/oauth-openid-youre-barking-up-the-wrong-tree-if-you-think-theyre-the-same-thing Respectfully, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Revisiting becoming an OpenID Provider
Ryan Lane wrote: > On Thu, May 27, 2010 at 7:08 PM, Jon Davis wrote: > >> I could see some real use cases for OAuth. Especially with regards to the >> cases mentioned above. People could potentially build apps like AWB and >> Huggle using OAuth. In general I think this would be a "cool thing" to have >> for all MediaWiki installs. >> >> As for being an OpenID provider... only one major thought: Having this >> Foundation be a provider would be a lot of additional server load (It is >> 100% non-cacheable) without any benefit to the main goal of providing free >> information. >> >> > > The biggest immediate benefit to becoming a provider is for > non-MediaWiki based apps that the foundation uses. If we become a > provider, our Wordpress, Bugzilla, Ideatorrent, etc. apps don't need > to have separate username/password databases. As someone mentioned > earlier, it would be extremely useful for the toolserver. > > Even for third-party applications, if we just provide OAuth, they > would still need to handle user account databases, and that isn't > optimal. It is especially less optimal for WMF users, who would need > to have user accounts in a number of spots, and possibly have to > remember multiple passwords. > > Respectfully, > > Ryan Lane > You sure you can't use pure OAuth similarly to the way you can with OpenID? I know they have their own user management, but disqus is using OAuth to turn twitter accounts into a login. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Reasonably efficient interwiki transclusion
I have updated my proposal with a fourth version [1] I am still waiting for comments from Tim Starling. I have contacted him on IRC for this. [1] http://www.mediawiki.org/wiki/User:Peter17/Reasonably_efficient_interwiki_transclusion#Fourth_version_.(to_be_discussed) -- Peter Potrowl http://www.mediawiki.org/wiki/User:Peter17 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
