© 2009 BitTorrent, Inc. µTorrent is a trademark of BitTorrent, Inc.
µTorrent Community
You are not logged in.
Here's another interesting piece to the BlackBerry OS 5.0 puzzle. If I navigate to the normal webui page, I can add a .torrent file with no problems. Now, using the normal webui on the BlackBerry still doesn't display any of the graphics and it's pretty jumbled mess, but it will work. Here's the log:
[2009-11-06 08:19:54] HTTP: IP 206.53.153.60: GET /gui/
[2009-11-06 08:20:00] HTTP: IP 206.53.153.60: GET /gui/stable.css
[2009-11-06 08:20:00] HTTP: IP 206.53.153.60: GET /gui/stable.css
[2009-11-06 08:20:06] HTTP: IP 206.53.153.60: GET /gui/main.css
[2009-11-06 08:20:07] HTTP: IP 206.53.153.60: GET /gui/main.css
[2009-11-06 08:20:18] HTTP: IP 206.53.153.60: GET /gui/images/snake.gif
[2009-11-06 08:20:19] HTTP: IP 206.53.153.60: GET /gui/images/mootools.png
[2009-11-06 08:20:20] HTTP: IP 206.53.153.60: GET /gui/lang/en.js
[2009-11-06 08:20:20] HTTP: IP 206.53.153.60: GET /gui/lang/en.js
[2009-11-06 08:20:25] HTTP: IP 206.53.153.60: GET /gui/?action=add-file
Offline
WebUI seems to behave identically to MiniUI here on BlackBerry OS v5.0 -- it simply doesn't work, and packet sniffs seems to indicate that the .torrent file either isn't sent, or it is stripped before it reaches µTorrent.
What model are you using, and what is the exact OS version? For example, I'm testing this on a BlackBerry 9500 simulator, using v5.0.0.252 (Platform 2.13.0.54).
Offline
I'm using a BlackBerry 9000 Bold OS v5.0.0.314 (Platform 5.2.0.19)
Offline
Right, so I was just testing image uploading at imageshack.us with BlackBerry OS v5.0, and curiously, it worked. After a bit of digging around in the code to check the fundamental differences between ImageShack's form upload and MiniUI's form upload, I think I've determined the cause of the problem. What MiniUI does when it submits a form is that it targets a hidden iframe element in the page so that the page doesn't change. Apparently, BlackBerry OS v5.0's browser doesn't like doing this for forms using the POST method, so it isn't submitting the form data to the iframe to be sent to the server. The result is that nothing gets sent at all except the request itself.
(Aside: ImageShack doesn't have to worry about using hidden iframes because the URL they're submitting the data to does return relevant HTML to be shown in the browser, so it's okay to let the browser load the resulting page. µTorrent doesn't return relevant HTML after a call to /gui/?action=add-file, and honestly, it shouldn't need to either).
If my hunch is correct, then this is definitely a bug in BlackBerry OS v5.0's browser, as usage of hidden iframe elements is a very common AJAX technique used to submit form data with files, without reloading the page. I would bother BlackBerry about it if I were you.
<html>
<head>
<title>µTorrent Uploader</title>
</head>
<body>
<div id="token" style="display: none;">##TOKEN##</div>
<iframe name="dummy" src="about:blank" style="display: none; width: 0; height: 0;"></iframe>
<div class="cont">
<form action="./?action=add-file" onsubmit="return (!!this.torrent_file.value);" method="post" enctype="multipart/form-data" id="add_file">
<label for="torrent_file">Torrent file:</label> <input type="file" name="torrent_file" /> <input type="submit" value="Add File" />
</form>
<hr />
<form action="./?action=add-url" onsubmit="return (!!this.s.value);" method="get" target="dummy" id="add_url">
<input type="hidden" name="token" value="##TOKEN##" />
<input type="hidden" name="action" value="add-url" />
<label for="s">Torrent URL:</label> <input type="text" name="s" /> <input type="submit" value="Add URL" />
</form>
</div>
<script type="text/javascript">
var token = document.getElementById("token").innerHTML;
document.getElementById("add_file").action = "./?token="+token+"&action=add-file";
document.getElementById("add_url").token.value = token;
</script>
</body>
</html>
Make a backup of your webui.zip somewhere, copy the code into a new file called "index.html", then place that file at the root of webui.zip.
Afterwards, if you try visiting http://[HOST]:[PORT]/gui/ and uploading a .torrent file, it will work. If you try using this snippet instead, you'll find that file upload won't work. The only difference between the two is that I removed target="dummy" from the add file form.
(You'll also notice that the "fixed" form ends up redirecting you to a page that looks like {"build":17188}, which is what targeting to an iframe would prevent)
Last edited by Ultima (2009-11-06 10:56:34)
Offline
Thanks for the information Ultima.
Ultima, would there be any way to run both the normal webui index.html as well as one with the code you posted above? That way I could use point the BlackBerry browser to the code above and my normal Firefox browser to the normal index.html.
Last edited by ytsejam1138 (2009-11-06 12:33:55)
Offline
It depends. If webui.token_auth is disabled, then the above code does not need to be named index.html, and it'll work fine with whatever name you choose. But if webui.token_auth is enabled, then the above code won't work without additional (not so trivial) modification if you wish to rename it to something other than index.html. Leaving webui.token_auth disabled is generally not a good idea.
You really should report the bug to BlackBerry, as this is a pretty big bug on their part. Working around it only gives them less incentive to fix the problem.
Edit: Eh, reported on the BlackBerry forum here.
Last edited by Ultima (2009-11-06 20:50:57)
Offline
2009-11-11
+ Feature: Palm webOS support
+ Feature: Set torrent job label from a list of existing labels
* Fix: Active/Inactive torrent jobs categories not filtered properly
* Fix: Auto-refreshing makes it difficult to modify settings
* Fix: Double token request when logging in as guest
* Fix: Improper guest account detection on Palm webOS Browser
* Fix: Newly set torrent job label not shown after Properties refresh
* Fix: Palm webOS reloading MiniUI when switching Details view
* Fix: Refresh button not working when viewing torrent job Files and Properties
* Fix: Use new values for queue.slow_*_threshold if modified in MiniUI
For Palm webOS users, there is a bug with the browser that prevents users from logging into sites that use basic HTTP authentication (like µTorrent's WebUI backend). The only way you can log in is to visit http://username:password@ip:port/gui/mini/index.html (or wherever you installed MiniUI).
So as a recap, I'm tracking a few bugs in various mobile browsers:
Offline
