There's a few comments on the Wikimedia blog saying they can't access en:wp any more using their BlackBerry. Though we tried it here on an 8900 and it works. Any other reports?
- d.
On Thu, May 13, 2010 at 3:16 PM, David Gerard dgerard@gmail.com wrote:
There's a few comments on the Wikimedia blog saying they can't access en:wp any more using their BlackBerry. Though we tried it here on an 8900 and it works. Any other reports?
Punching in http://en.wikipedia.org/ as I normally would...
It starts to render, but with an enormous grey area at the top like a gigantic banner ad. Then the browser crashes, I assume I've never seen it do that before... it throws up a "there was a problem rendering this page", blanks the screen, and goes unresponsive.
Blackberry 8310, software v4.5.0.110 (Platform 2.7.0.90)
"David Gerard" dgerard@gmail.com wrote in message news:AANLkTin9qhCgvataEgsDrWjUc-jEGJ-iwdG6f9oYtwdt@mail.gmail.com...
There's a few comments on the Wikimedia blog saying they can't access en:wp any more using their BlackBerry. Though we tried it here on an 8900 and it works. Any other reports?
Works fine using Opera Mini.
Trying to load any page on the native Blackberry Browser, with JavaScript disabled, results in a browser crash with message "Uncaught exception: java.lang.ClassCastException" (after the page has fully loaded). Trying with JavaScript enabled (while not logged in) results in "HTTP Error 413: Request Entity Too Large", even on a page known to be very small.
This is for a Blackberry 8800 v.4.5.0.110.
On 05/13/2010 10:55 PM, Russell Blau wrote:
"David Gerard"dgerard@gmail.com wrote in message news:AANLkTin9qhCgvataEgsDrWjUc-jEGJ-iwdG6f9oYtwdt@mail.gmail.com...
There's a few comments on the Wikimedia blog saying they can't access en:wp any more using their BlackBerry. Though we tried it here on an 8900 and it works. Any other reports?
Works fine using Opera Mini.
Trying to load any page on the native Blackberry Browser, with JavaScript disabled, results in a browser crash with message "Uncaught exception: java.lang.ClassCastException" (after the page has fully loaded). Trying with JavaScript enabled (while not logged in) results in "HTTP Error 413: Request Entity Too Large", even on a page known to be very small.
Error 413 generally means, in plain English, "URL too long". I'd suspect some script is trying to do an API query using a very long URL, and the fact that this only happens when JS is enabled lends support to this.
Assuming that the Blackberry browser doesn't have particularly good JS debugging support, it might be worth looking at the same page in e.g. FF + Firebug, with JS and net debugging enabled, and looking for any requests with suspiciously long URLs.
I've no idea what might be causing the other problems, though.
2010/5/13 Ilmari Karonen nospam@vyznev.net:
Error 413 generally means, in plain English, "URL too long". I'd suspect some script is trying to do an API query using a very long URL, and the fact that this only happens when JS is enabled lends support to this.
Assuming that the Blackberry browser doesn't have particularly good JS debugging support, it might be worth looking at the same page in e.g. FF
- Firebug, with JS and net debugging enabled, and looking for any
requests with suspiciously long URLs.
I've no idea what might be causing the other problems, though.
413s are thrown by the *server*, not the client. An overlong URL would cause 413s independent of whether it's Firefox or a Blackberry requesting them.
Roan Kattouw (Catrope)
On Thu, May 13, 2010 at 1:39 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
2010/5/13 Ilmari Karonen nospam@vyznev.net:
Error 413 generally means, in plain English, "URL too long". I'd suspect some script is trying to do an API query using a very long URL, and the fact that this only happens when JS is enabled lends support to this.
Assuming that the Blackberry browser doesn't have particularly good JS debugging support, it might be worth looking at the same page in e.g. FF
- Firebug, with JS and net debugging enabled, and looking for any
requests with suspiciously long URLs.
I've no idea what might be causing the other problems, though.
413s are thrown by the *server*, not the client. An overlong URL would cause 413s independent of whether it's Firefox or a Blackberry requesting them.
You'd think so, but it really is the "client".
If you Google "Blackberry 413" there is a long history of this error happening on the Blackberry web client. It appears that a 413 error is the way that the Blackberry rendering engine responds to hitting resource limits (e.g. memory or storage space). The newer models tend to avoid it by devoting more resources to browsing.
I would guess that the Javascript associated with Vector is using more memory than the Monobook version did and this is causing an error for people that used to have no trouble browsing Wikipedia before.
-Robert Rohde
vyznev wrote:
I'd suspect some script is trying to do an API query using a very long URL, and the fact that this only happens when JS is enabled lends support to this.
I don't see any long url requested on enwiki.
I would guess that the Javascript associated with Vector is using more memory than the Monobook version did and this is causing an error for people that used to have no trouble browsing Wikipedia before.
jQuery is by itself much more complex than the scripts used before, plugins.combined.min.js and Vector.combined.min.js aren't small either.
Does Blackberry also fail on other webs using jQuery?
On 14 May 2010 16:34, Platonides Platonides@gmail.com wrote:
vyznev wrote:
I'd suspect some script is trying to do an API query using a very long URL, and the fact that this only happens when JS is enabled lends support to this.
I don't see any long url requested on enwiki.
I would guess that the Javascript associated with Vector is using more memory than the Monobook version did and this is causing an error for people that used to have no trouble browsing Wikipedia before.
jQuery is by itself much more complex than the scripts used before, plugins.combined.min.js and Vector.combined.min.js aren't small either.
Does Blackberry also fail on other webs using jQuery?
Maybe a Blackberry emulator can be usefull (one that is accurate). Any idea of where one can be downloaded?
On Fri, May 14, 2010 at 10:51 AM, Tei oscar.vives@gmail.com wrote:
Maybe a Blackberry emulator can be usefull (one that is accurate). Any idea of where one can be downloaded?
First google result:
http://na.blackberry.com/eng/developers/resources/simulators.jsp
-Chad
BTW, Vector is also breaking the PS3 browser, according to a couple of comments on the blog post.
We seem not to be quite achieving that "graceful degradation" thing immaculately ...
- d.
When visiting a vector site with a Nokia N-series (tested on N90,95and 96) viewing it on Opera Mini there are problems also.
Its impossible to click the buttons "userpage, talkpage, watchlist .." they are all in the same spot, trying to press will give the prefences.
The Buttons with Edit Talk History are all in the same place and pressing one isn't working at all.
Best,
2010/5/14, David Gerard dgerard@gmail.com:
BTW, Vector is also breaking the PS3 browser, according to a couple of comments on the blog post.
We seem not to be quite achieving that "graceful degradation" thing immaculately ...
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Maybe could be usefull to have a special url that automatically disable vector, and make this setting continue with the session (is that even possible?).
Like http://en.wikipedia.com/classicview
So people designing smartphones, that want his smartphone to use the old interface, can make the link point there, so a old style theme is in use even before the user has the oportunity to login.
On 14 May 2010 17:55, Huib Laurens sterkebak@gmail.com wrote:
When visiting a vector site with a Nokia N-series (tested on N90,95and 96) viewing it on Opera Mini there are problems also.
Its impossible to click the buttons "userpage, talkpage, watchlist .." they are all in the same spot, trying to press will give the prefences.
The Buttons with Edit Talk History are all in the same place and pressing one isn't working at all.
Best,
2010/5/14, David Gerard dgerard@gmail.com:
BTW, Vector is also breaking the PS3 browser, according to a couple of comments on the blog post.
We seem not to be quite achieving that "graceful degradation" thing immaculately ...
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Huib "Abigor" Laurens
Tech team www.wikiweet.nl - www.llamadawiki.nl - www.forgotten-beauty.com
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, May 24, 2010 at 7:48 AM, Tei oscar.vives@gmail.com wrote:
Maybe could be usefull to have a special url that automatically disable vector, and make this setting continue with the session (is that even possible?).
http://en.wikipedia.org/wiki/?useskin=monobook
You have to readd ?useskin=monobook or &useskin=monobook on every page view, though, since it's not added to links.
On 24 May 2010 16:25, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Mon, May 24, 2010 at 7:48 AM, Tei oscar.vives@gmail.com wrote:
Maybe could be usefull to have a special url that automatically disable vector, and make this setting continue with the session (is that even possible?).
http://en.wikipedia.org/wiki/?useskin=monobook You have to readd ?useskin=monobook or &useskin=monobook on every page view, though, since it's not added to links.
A lotta commenters on the blog have complained at having to create a login to get back monobook. People don't like being forced (as they see it) to create yet another website login.
Is there any reason not to make "useskin=" persistent? i.e., to render all internal links on a page with a useskin= if one was used in the URL? Then at least that'd be a workaround for the Blackberry, PS3 etc. users until we get some graceful degradation happening, and calm the ruffled feathers a bit.
- d.
On Mon, May 24, 2010 at 11:34 AM, David Gerard dgerard@gmail.com wrote:
Is there any reason not to make "useskin=" persistent? i.e., to render all internal links on a page with a useskin= if one was used in the URL?
Yes. We'd have to either fragment the parser cache, or implement some type of postprocessing step in the parser (which would surely be unreliable unless the parser was significantly reworked). The standard way to do this instead would be with a cookie, which would work without fragmenting the parser cache. But any solution at all will have to fragment the Squid cache, since the HTML output is entirely different, and that's already not a good thing if a lot of people switch back to Monobook. (If Monobook and Vector differed only in CSS, then better options would be available, but they don't.)
David Gerard wrote:
On 24 May 2010 16:25, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Mon, May 24, 2010 at 7:48 AM, Tei oscar.vives@gmail.com wrote:
Maybe could be usefull to have a special url that automatically disable vector, and make this setting continue with the session (is that even possible?).
http://en.wikipedia.org/wiki/?useskin=monobook You have to readd ?useskin=monobook or &useskin=monobook on every page view, though, since it's not added to links.
A lotta commenters on the blog have complained at having to create a login to get back monobook. People don't like being forced (as they see it) to create yet another website login.
Is there any reason not to make "useskin=" persistent? i.e., to render all internal links on a page with a useskin= if one was used in the URL? Then at least that'd be a workaround for the Blackberry, PS3 etc. users until we get some graceful degradation happening, and calm the ruffled feathers a bit.
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Another possible solution is to serve the mobile site when the page is requested from blackberry. I am working with Tomasz and Hamton, if we can make the switch.
- Naoko
On 24 May 2010 19:58, Naoko Komura nkomura@wikimedia.org wrote:
Another possible solution is to serve the mobile site when the page is requested from blackberry. I am working with Tomasz and Hamton, if we can make the switch.
That's the obvious answer, yes :-)
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.
- d.
On 24 May 2010 20:04, David Gerard dgerard@gmail.com 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?
- d.
Hi,
On 24 May 2010 21:09, David Gerard dgerard@gmail.com wrote:
On 24 May 2010 20:04, David Gerard dgerard@gmail.com 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).
On 24 May 2010 17:25, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Mon, May 24, 2010 at 7:48 AM, Tei oscar.vives@gmail.com wrote:
Maybe could be usefull to have a special url that automatically disable vector, and make this setting continue with the session (is that even possible?).
http://en.wikipedia.org/wiki/?useskin=monobook
You have to readd ?useskin=monobook or &useskin=monobook on every page view, though, since it's not added to links.
Neato.
I have made this awesome url: http://en.wikipedia.org/w/index.php?title=Special:UserLogin&returnto=Spe...
It create the login page in monobook, and once you login, puts you in settings (again in monobook), so from there you can disable monobook (note: I have not tested that myself, I love vector ;-) )
wikitech-l@lists.wikimedia.org