Browse cannot download data URIs

[lucian]

Data URIs  http://en.wikipedia.org/wiki/Data_URI_scheme

In Firefox, you can right click a link with a data URI and download it. This makes for some really cool tricks, like drawing a picture in a <canvas> and offering it for download as a PNG ( http://www.nihilogic.dk/labs/canvas2image/)

Steps to reproduce:
1. Load datauri.html in Browse (attached to this ticket)
2. Right-click on Text
3. In the context menu, click Download

Expected outcome: the URI gets downloaded to the Journal

Actual outcome: nothing happens. Relevant traceback attached

[lucian]

HTML file to reproduce the bug.

[lucian]

I changed my mind, I'm posting the traceback here.

Traceback (most recent call last):

File "/home/lucian/sugar-jhbuild/install/share/sugar/activities/Browse.activity/palettes.py", line 154, in download_activate_cb

downloadmanager.save_link(self._url, self._title, self._owner_document)

File "/home/lucian/sugar-jhbuild/install/share/sugar/activities/Browse.activity/downloadmanager.py", line 320, in save_link

channel.asyncOpen(listener, None)

File "/usr/lib/xulrunner-1.9.0.10/python/xpcom/client/init.py", line 372, in getattr

self.QueryInterface(iid)

File "/usr/lib/xulrunner-1.9.0.10/python/xpcom/client/init.py", line 336, in QueryInterface

raw_iface = self._comobj_.QueryInterface(iid, 0)

xpcom.Exception: -2147467262 (-2147467262)

[lucian]

xpcom.Exception: -2147467262 is NS_NOINTERFACE

I've added a print statement in xpcom/client/init.py to show iid

Apparently, the last iid requested is {9277fe09-f0cc-4cd9-bbce-581dd94b0260}, which seems to be nsIHttpChannel.

[lucian]

I've implemented a workaround in downloadmanager.py, that saves data URIs directly to the Journal. Patch attached.

This is not a proper fix, though. Someone with better knowledge of pyxpcom and xulrunner could probably do it.

[lucian]

Workaround for downloading data URIs to the Journal.

[lucian]

With Tomeu's help, I've made a much smaller patch, http_check.patch. Now the alert shows, but it's text is the actual base64 data. It's still much better than before.

Apparently, if you QueryInterface a pyxpcom object that implements nsIChannel with nsIHttpChannel, it'll think it's nsIHttpChannel.

This patch is still a bit of a workaround, but a much less invasive one.

[lucian]

improvement in the alert and journal object title

[lucian]

Data URIs now have a default filename, 'data URI'. The download alert is much less ugly.

The Journal objects now read 'data URI from data:mime/type;base64,DaTA...'

[erikos]

 http://git.sugarlabs.org/projects/browse/repos/mainline/commits/9cac83dae9eea3074b96095be10dad37cfd0f7e1