Sunday, January 22, 2017

Uploading files via Firefox in Android 2.3

This is very much a quick-and-dirty post, so that I wouldn't forget about it. As my phone is also currently charging while off, I can't check out some information pertaining to this post. Some time after the phone will have charged, I'll update this post accordingly.

So, yesterday, I had this need to upload a file to a project in Github via Firefox in Android 2.3 Gingerbread.

Now, Github is quite a modern website, and in Android 2.3, the logical browser for visiting Github and other state-of-the-art sites is Firefox for Android or a derivative, such as GNU IceCat, Orfox, or Adblock Browser.

I have two browsers in my phone: GNU IceCat 38.8 and Firefox 44.0. Both have NoScript installed, and Github servers were whitelisted in both. Separate issues with uploading are covered at the end of this post.

The crux of the problem is having a filepicker that works.

Typically, an Android user gets a file activity dialog to pick an app through which to select a file; such as Gallery for photos and videos, or somesuch.

For a simple text file, things are a bit more complicated, but I've discovered two kinds of filepickers that I associated with after having installed two separate apps.

• One filepicker, "Choose file" with blue folder icons, seems to be related to VimTouch, a version of Vim for Android, because I noticed that filepicker after installing this great text editor.
• Another filepicker, "Find file" or "Find command" (I might err with its title) is adorned with the Terminal Emulator icon.

Both VimTouch (alternatively spelled 'Vim Touch') and Terminal Emulator were installed through F-Droid, a repository of free and open source apps for Android.

The filepicker that works, is the one I associate with Terminal Emulator.

Unfortunately, I don't know beyond my memory of my app installation activities, and beyond one app icon about how to find out which app or handler these two particular filepickers are actually associated with.

Upload issues.

Resolved on 28.04.2017.

With IceCat, there were issues relating to uploading files to GitHub, whereby file upload failed with an error. File upload to GitHub worked with Firefox for Android, but for some odd reason, did not work in IceCat.

Now, I use NoScript in Android Firefox and in IceCatMobile (based on Firefox with very small changes). Since both have slightly different NoScript whitelists, then I attributed the issue to an incomplete NoScript whitelist in IceCatMobile. But it was not at fault, and the problem was much simpler, though no less esoteric.

Turns out, that all other things being almost equal, GitHub does not recognise the Firefox-based GNU IceCat browser when uploading files, if an IceCat-only desktop user-agent (UA) string is used.

The solution is to change in IceCat's about:config page the Gecko-based user-agent override affecting the Github domain to that of Firefox, leaving the version number intact.

<Moot:> Possible issues wrt NoScript
The reason for that, is, that I edit NoScript whitelists in Vim Touch so as to get a very fine-grained whitelist on a subdomain level (3rd-level domains and below, such as sub.domain.tld ), because the browser extension in Android does not provide such functionality.

The rationale for subdomain-level whitelisting is, that my phone is rather underpowered, and subdomain-level whitelists in Firefox/derivatives make it possible to allow advanced site functionality, and at the same time, to block script-based ads and trackers. In addition, it's possible to switch off very resource-intensive site functionality by blocking certain subdomains of a website. Such features are impossible in the stock Android browser, the rendering engine of which dates back to 2011.

(I'm often contemplate writing a separate post about all that.)

So, the NoScript whitelist for IceCat is typically more fine-grained; yet oddly, file upload to Github actually worked with Firefox.

Friday, January 13, 2017

Posting URLs with multiple concurrent dots in YouTube comments

In a YouTube discussion under one of the Star Trek-related video clips, a commenter ha posted an address to a Memory Alpha page into the comments, but the address to the article was truncated, because it contained three concurrent dots:

Intended address:

http://memory-alpha.wikia.com/wiki/Star_Trek_is...

and as it turned out in truncated form:

http://memory-alpha.wikia.com/wiki/Star_Trek_is.

Note, that the two last dots are gone, and if the address is clicked on at YouTube comments, the browser is taken to a "404/Not found" page in Memory Alpha.

The article about what Star Trek is, actually does contain three dots at the end of its address, but the YouTube comments system doesn't like it, as I found this out through my Google+ notifications on the desktop and the (linked) comments at desktop YouTube.

The somewhat unorthodox solution to avoiding dots from being truncated is to insert the URL with those three ending dots and replace the two last-most dots with their percent-encoded representations. Case in point:

http://memory-alpha.wikia.com/wiki/Star_Trek_is.%2E%2E

That one dot there may remain.

The percent-encoded values are available from Windows Character Map, a similar program in UNIX/Linux, or through any Unicode character table available on the web.

One can also try with

http://memory-alpha.wikia.com/wiki/Star_Trek_is.%2E.

— with "typed dot | precent-encoded dot | typed dot" after "_is", but there cannot be any two or more concurrent normally-typed dots.

Truncation of characters in addresses pasted (or typed) into YouTube comments can also apply to other web addresses with multiple concurrent characters, but I do not know, which types of characters are more affected or less. I could lay a claim, that special and non-alphanumeric characters that are used in programming, are treated with a greater level of scrutiny.