I had a chat with silbe in irc, but we don't agreed in a solution. Right now the problem we have is, we are trying to use a file name with a name is not utf-8 encodeable. Dbus sent a error, and you can't download the file. The proposed solution take the encoding of the page to manipulate the file name. Is the same we (and mozilla) are using to display and manipulate the url from the page (browser.py line 300). More ideas? Gonzalo <silbe> gonzalo_: so it happens if you try to follow ("download") a link where the URL has characters in it that are not valid in UTF-8? <silbe> I.e. if you try to follow <a href="<a href="http://www.cerlyn.com/q/test2%f1%e2%e0.odt">http://www.cerlyn.com/q/test2%f1%e2%e0.odt</a>">foo</a> ? or is it the filename= MIME attribute that gets sent by the web server? <gonzalo_> silbe: yes, if you go to <a href="http://www.cerlyn.com/q/">http://www.cerlyn.com/q/</a> and try to download the last file <Cerlyn> from a user's perspective you get the file downloaded but sugar doesn't show any filename in the download dialogs or as part of the journal name ("File{two spaces}from ...") <-- acaleechurn ha cerrado (Quit: Ex-Chat) <gonzalo_> silbe, cerlyn: but internally there are errors, because dbus does not accept the utf string in the name cerlyn: see you the file saved in the journal? <Cerlyn> gonzalo_: At least in os353 it gets saved <Cerlyn> it just lacks a name <gonzalo_> cerlyn: ok <Cerlyn> useful name anyway the journal entry is labeled with the text that should surround the downloaded file's original name or maybe only in some cases. Clicking on it just shows 'Download completed" with no further info, and Show journal doesn't work , because there is no journal entry <silbe> gonzalo_: what does interfaces.nsITextToSubURI do if the URL is in a different encoding than the web page (which I guess is where the value of uri.originCharset comes from)? <Cerlyn> Right clicking and choosing download attempts to download an "Untitled" thing to the journal which doesn't complete. Maybe had more luck yesterday for some odd reason --> timClicks (~<a href="mailto:tim@219-89-80-120.adsl.xtra.co.nz">tim@219-89-80-120.adsl.xtra.co.nz</a>) ha entrado en #sugar <gonzalo_> silbe: i don't know cerlyn: i could not download the file without the patch <silbe> gonzalo_: My fear is that it would break in the same way. And I don't know of any requirement that URLs have to use the same encoding as the medium they're used in (in this case HTML). <gonzalo_> silbe: but i think the link the browse see is in the encoding from the page --> m_anishh (qwebirc@gateway/shell/<a href="http://sugarlabs.org/x-srydaokmidwatxhk">sugarlabs.org/x-srydaokmidwatxhk</a>) ha entrado en #sugar <gonzalo_> silbe: think about that, the browse read a link with the encoding from the page <silbe> gonzalo_: exactly. but as URLs don't specify encodings, where does uri.originCharset get its value from? <silbe> oh, wait, I misread what you wrote. <gonzalo_> silbe: tjis case is different like if you put a arbitrary link in the location bar <silbe> gonzalo_: I don't think we can rely on HTML pages containing links _only_ to stuff in the same encoding as they use themselves. gonzalo_: e.g. if I take your link to the ODT file and put it on my web page (which uses UTF-8) it would still break. And I think that's a valid use case. :) <gonzalo_> silbe: but until we found a hypothetical case where can be browen, why not resolve what is broken now? <silbe> gonzalo_: because if we don't do it the right way now, we'll have to fix it _again_ later <Cerlyn> Well where do we get the name value anyway? The server can suggest a name in an HTTP header, and I'd have to look up what encoding it is there <silbe> Cerlyn: that was exactly my question. do we get it from the link (href=) or from something the server sent us? <gonzalo_> cerlyn, silbe: i dont know, is in the nsURI object <silbe> In the former case, we cannot assume anything about the encoding (though we might try some guesses, but those can go wrong). In the latter case we can probably (would need to cross-check with the standard) assume some specific encoding. <gonzalo_> cerlyn, silbe: what i am doing now in the download of the file is the same we are using in browser.py to get the url from the uri cerlyn, silbe: just in the download we was arbitrary setting the encode like utf8 silbe: can you see browser.py line 301 <silbe> gonzalo_: sorry, I need to stop here. I'd like to finished the second version of the clean-up series today and need to go to bed soon. Can you summarise our discussion (or just cut&paste it) and post it to sugar-devel (as reply to the patch), please? <gonzalo_> silbe:ok <silbe> gonzalo_: thx