Browse shouldn't open plain text links, instead should download them

[HoboPrimate]

Browse currently opens links to text files within itself, but this is undesirable because Browse is not great to read these (Read would be better), and doesn't let you edit them (Write would) and storage them (for the time being Browse doesn't have this).

A typical case where the current feature is undesired is browsing Project Gutenberg books, which are text plain files for compatibility reasons. Imagining that in the future Browse lets you save the current file it's viewing, even so it would be an extra step to get the book copied to be read, edited, shared and stored in the Journal.

I think we can assume that today plain text (.txt) files aren't being used to build webpages, (i.e., they are meant to be downloaded). And this would follow Sugar convention that each activity does a specific thing (Browse to browse the (Inter)net, Read to read books, etc.).

[HoboPrimate]

Just to clarify what I think should happen:

1. Kid clicks on link to text file
2. A Text icon appears in the Clipboard frame and begins downloading
3. Once finished, the kid can choose between the rollover menu options of the Text icon, "Remove", "Put in Journal", "Open in Write", "Open in Read".

[jg]

Eben, I don't know your plans are on mime type handling and read vs. write; when you've decided, reassign to browser.

[Eben]

That's a tricky one. We're used to associating .txt files with Write in the general case. However, I also feel like the things you find online in .txt format will more closely resemble books, and as such would be best associated with Read as the default. Of course, the kids will always be able to choose the other anyway. Let's use Read by default for downloaded .txt files, so they behave just like pdfs do upon download.

[AlbertCahalan]

There are good reasons to NOT do this.

The first is power, speed, and RAM. Starting up a second app does not come free.

The second is UI confusion. Editing the file will NOT change it on the web site. You're opening a read-only document. You can pretend that it is read-write, but you can't save it back. Nobody will see the changes -- not even the user who did the editing will see the changes upon returning to the web site.

The third is that this is a partial band-aid over a problem that needs to be solved: you can't save and edit things you find on the web. Note that an HTML file is even more likely to be what the user desired to edit, but you certainly can't hand all HTML files off to the text editor.

Consistent behavior is critical in a UI. It's best for the browser to make heroic attempts to display whatever the user browses to. Browsing is not editing. Suddenly needing to close an app (instead of hitting the "back" button) is not good UI design.

[HoboPrimate]

Replying to AlbertCahalan:

Consistent behavior is critical in a UI. It's best for the browser to make heroic attempts to display whatever the user browses to. Browsing is not editing. Suddenly needing to close an app (instead of hitting the "back" button) is not good UI design.

I think eben wasn't saying that the text file would be automatically opened by Read, only that it would be automatically downloaded to the Journal and associated with the Read activity.

But I agree with you, contrary to my original thinking when submitting this bug. Many times will a kid be browsing the (inter)net and come to all kinds of files that the browser also opens. If Browse automatically downloads all files when it could view them, then the kid will get stuff on his Journal that he may not want.

Do we(you) then assume that by default those files aren't stored in Journal, unless the kid takes action to do so?
Right now, when Browse is viewing an image (http://www.some-server.com/hello.png), you can dnd it to the clipboard and save it that way. But with text files it's trickier, as you have to select all the text, then dnd the selection to the clipboard.
What if Browse had an Edit menu, with a "copy to clipboard" button which would copy the current file Browse is viewing (be it an image, a text file, or even an html file) and copy thinks from webpages as well (text and images).

[HoboPrimate]

In my last phrase I meant to say "and copy selections from webpages as well", since when no selection was done, it could copy the entire webpage file.

[marco]

Mozilla external apps API doesn't allow us to decide what to do with text/plain currently and I don't want to patch something so low level for a behavior which is arguably better but won't make a huge difference.

Please post a bug to bugzilla.mozilla.org if you think it's worth requesting them to give control over this to the embedders.