Staying on the Web
John J. Barton
that are really not links. For example, look at the link on
http://code.google.com/p/fbug/issues/detail?id=2535
in comment 3 under the word 'download'. It looks like a link, but it
acts completely different.
Rather than viewing the linked page, Firefox puts up a modal dialog with
two options, neither one of them valuable.
One option is Open With, followed by a list of desktop applications. If
Firefox was on that list, then this bizarre behavior would only be
puzzling and not frustrating. But Firefox is not on that list.
The other option is Save As. This one is literally painful. To use it
you have to spend several minutes clicking clicking clicking to navigate
to some temp directory, "save" the file (by the double quotes I mean
that this is the term the UI uses, I don't want to save it I want to
open it in Firefox!), then use Firefox > File > Open > click, click,
click to the temp directory. Then I can view the link!
I think that is just plain weird. Firefox should allow me to stay on the
Web. I don't want to store any files on my machine unless I command
Firefox to do so. I don't care what the web site has done to the link, I
still want my browser to do what I want, not what the web site wants.
Firefox is my Web viewer, my Web firewall.
(Yes, I know about Sylvain's Open in Browser Extension, I know I've
posted about this before, and I'm sure there are bugzilla bugs on this.
Thanks for reading this far, I hope it gives you ideas!)
jjb
Zack Weinberg
> A frustrating and puzzling part of Firefox is the way it handles
> links that are really not links. For example, look at the link on
> http://code.google.com/p/fbug/issues/detail?id=2535
> in comment 3 under the word 'download'. It looks like a link, but it
> acts completely different.
>
> Rather than viewing the linked page, Firefox puts up a modal dialog
> with two options, neither one of them valuable.
There's nothing funny with the link itself; rather, the document at the
target URL is being served with MIME type application/octet-stream, so
the browser treats it as a bag of bits, with no useful thing you can do
with it besides save to disk. I would support UI in that modal dialog
you mention that lets you force the browser to treat the document as
text/plain or text/html, but basically, you are complaining about a
fundamental design flaw in the Web, viz. the existence of the
Content-Type header, and there's not much we can do about it at this
point.
zw
Boris Zbarsky
> Rather than viewing the linked page, Firefox puts up a modal dialog with
> two options, neither one of them valuable.
It does this at the explicit request of the website in this case. The
website sends:
Content-Type: application/octet-stream
content-disposition: attachment; filename="firebug-tracing-logs.txt"
Note that:
1) It tells us absolutely nothing about what kind of data this really
is (which is why the "open with" option is not prefilled with a
useful app).
2) It explicitly requests outside-the-browser handling (the
"attachment" part).
Now I happen to think that this is just a stupid bug in code.google.com
(in particular the fact that all attachments are served with useless
MIME types); have you filed it on them?
> I think that is just plain weird. Firefox should allow me to stay on the
> Web.
https://bugzilla.mozilla.org/show_bug.cgi?id=57342
-Boris
Charlie Powell
have many cases where I'm presented with a png/jpg/gif and need to have
the user download the image instead of viewing it. I explicitly tell
the browser to provide a download prompt via manipulation of the
headers.
If you want to view the page in firefox, I'd just suggest clicking on
'Open With:' and selecting firefox.
---
Charlie Powell
Developer, Systems Administrator
pow...@powelltechs.com
On Tue, 2009-12-01 at 11:52 -0800, Zack Weinberg wrote:
> "John J. Barton" <johnj...@johnjbarton.com> wrote:
>
> > A frustrating and puzzling part of Firefox is the way it handles
> > links that are really not links. For example, look at the link on
> > http://code.google.com/p/fbug/issues/detail?id=2535
> > in comment 3 under the word 'download'. It looks like a link, but it
> > acts completely different.
> >
> > Rather than viewing the linked page, Firefox puts up a modal dialog
> > with two options, neither one of them valuable.
>
> There's nothing funny with the link itself; rather, the document at the
> target URL is being served with MIME type application/octet-stream, so
> the browser treats it as a bag of bits, with no useful thing you can do
> with it besides save to disk. I would support UI in that modal dialog
> you mention that lets you force the browser to treat the document as
> text/plain or text/html, but basically, you are complaining about a
> fundamental design flaw in the Web, viz. the existence of the
> Content-Type header, and there's not much we can do about it at this
> point.
>
> zw
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Mike Shaver
> Now I happen to think that this is just a stupid bug in code.google.com (in
> particular the fact that all attachments are served with useless MIME
> types); have you filed it on them?
I suspect that's to avoid CSRF attacks by uploading attachments that
run script, though they could take other approaches if that is indeed
the case.
Mike
Boris Zbarsky
> I suspect that's to avoid CSRF attacks by uploading attachments that
> run script
The could still use content-disposition:attachment and a correct MIME
type and not have that concern....
-Boris
John J Barton
> "John J. Barton" <johnj...@johnjbarton.com> wrote:
>
>> A frustrating and puzzling part of Firefox is the way it handles
>> links that are really not links. For example, look at the link on
>> http://code.google.com/p/fbug/issues/detail?id=2535
>> in comment 3 under the word 'download'. It looks like a link, but it
>> acts completely different.
>>
>> Rather than viewing the linked page, Firefox puts up a modal dialog
>> with two options, neither one of them valuable.
>
> There's nothing funny with the link itself; rather, the document at the
> target URL is being served with MIME type application/octet-stream, so
> the browser treats it as a bag of bits, with no useful thing you can do
> with it besides save to disk.
Just to re-iterate your observation: "the browser treats...". It is the
browser that can be fixed here.
> I would support UI in that modal dialog
> you mention that lets you force the browser to treat the document as
> text/plain or text/html, but basically, you are complaining about a
Note that if I save the content and load it into the browser, it works
great. If I use Sylvain's Open In Browser, it works great. I just want
Firefox to work great too.
> fundamental design flaw in the Web, viz. the existence of the
> Content-Type header, and there's not much we can do about it at this
> point.
See above, I don't agree that we are helpless here.
jjb
John J Barton
> I wouldn't even consider that a flaw in the web, more like a feature. I
> have many cases where I'm presented with a png/jpg/gif and need to have
> the user download the image instead of viewing it. I explicitly tell
> the browser to provide a download prompt via manipulation of the
> headers.
But its my browser, not yours. I am grateful that you take the extra
work to help me by providing the option of saving rather than viewing.
All I am asking for the the option of viewing rather than saving.
>
> If you want to view the page in firefox, I'd just suggest clicking on
> 'Open With:' and selecting firefox.
"firefox" is not an option on the Open With dialog. (Even if it was, it
would still be weird to have to do that kind of counter-intuitive
operation to look at a web link).
jjb
John J Barton
> On 12/1/09 12:09 PM, John J. Barton wrote:
>> Rather than viewing the linked page, Firefox puts up a modal dialog with
>> two options, neither one of them valuable.
>
> It does this at the explicit request of the website in this case.
Which is really my point: one of the Firefox culture threads has been
"It's the user's browser". Web sites offer options, but should not
dictate terms. This is one area where Firefox can improve the power of
the user. All of the tools are in the browser to deal with all kinds of
content issues. The era of delegating to desktop software is ending.
Allowing these legacy applications to be invoked is fine, but not to be
in charge.
jjb
Boris Zbarsky
> Which is really my point: one of the Firefox culture threads has been
> "It's the user's browser". Web sites offer options, but should not
> dictate terms. This is one area where Firefox can improve the power of
> the user. All of the tools are in the browser to deal with all kinds of
> content issues. The era of delegating to desktop software is ending.
> Allowing these legacy applications to be invoked is fine, but not to be
> in charge.
Sure. That's why we have a bug on adding more options to that dialog, no?
-Boris
Boris Zbarsky
> Sure. That's why we have a bug on adding more options to that dialog, no?
And to be more precise, we can add options on the dialog to our heart's
content but the result will still suck in that there will be a dialog.
That needs to keep happening because a number of sites (most in fact)
use this functionality legitimately. Again, the misuse on google's part
just means the user experience there suffers no matter what; I strongly
urge you to bring it up with them.
-Boris
John J Barton
Yes, so you can interpret my post as a belated celebration of the ninth
anniversary of the filing of bug 5734 ;-)
jjb
Alex Faaborg
box, we clearly must be doing something wrong :) Firefox's current
download window behavior seems to be based more how browsers happen to
have behaved in the past, so I think it is definitely worth revisiting
the interface.
This is something that Limi, Boriss and I have been discussing. I know
John has been pushing on for a long time now, and Limi has been
pushing on it pretty hard recently as well. The concept is to
reframing the download UI to be a bit more like a print preview (see
the content, bar on top with options), sort of a "download preview".
Here is how it might work:
-If the file is small and we can render the content being downloaded,
we do
-If the browser was instructed to pop up a download dialog box, a bar
is displayed at the top of the page with commands to save the file, or
to send the file to an external application
-Similar to the download dialog box, users have the option of setting
the default behavior (preview, download, send to external app), but we
default to preview
-We try to increase the set of files that we can preview in the
browser to common types like PDF, and perhaps even other document
types (although this has significant security implications, legal
implications, and implications if we are only trying to promote open
formats)
Additionally, when a plugin is being used to render content in the
content area (and the browser did not instruct Firefox to download the
file), I believe we should display the same bar with command to
download or open in an external application. In a lot of cases the
user might be viewing a quicktime movie or listening to an MP3 and
they think "how can I download this?" The actual answer is to go to
File > Save As, but because that is so rarely done, people usually do
not successfully come to that conclusion.
In the event that a download can not be previewed (the user can't
"stay on the Web"), or the user asked Firefox to remember another
behavior for the type of content, like automatic download or
automatically sending to another app, we should change the cursor icon
to indicate the action when they hover on the link, so that they
always know what is going to happen ahead of time.
-Alex
Benjamin Smedberg
> And to be more precise, we can add options on the dialog to our heart's
> content but the result will still suck in that there will be a dialog.
> That needs to keep happening because a number of sites (most in fact)
> use this functionality legitimately. Again, the misuse on google's part
> just means the user experience there suffers no matter what; I strongly
> urge you to bring it up with them.
Why couldn't we navigate to an "XUL error page" instead of showing a dialog?
That might be a better way to handle downloads, helper apps, or in-browser
display, even.
--BDS
Boris Zbarsky
> -If the file is small and we can render the content being downloaded, we do
How does this work for a multipart/x-mixed-replace with multiple
attachments, or some parts that are attachments and some parts that aren't?
(This isn't an idle question; there are government websites, or were as
of a few years back, that had exactly this setup, and where if you
ignored the content-disposition and showed the attachments inline you
wouldn't be able to get at the data you really wanted).
> -We try to increase the set of files that we can preview in the browser
> to common types like PDF, and perhaps even other document types
> (although this has significant security implications, legal
> implications, and implications if we are only trying to promote open
> formats)
Yep. Automatic preview of HTML with scripts enabled, say, would be a
security problem.
I do think better UI around this would be very nice, though!
-Boris
Boris Zbarsky
> Yes, so you can interpret my post as a belated celebration of the ninth
> anniversary of the filing of bug 5734 ;-)
Well, all that's needed is for someone to step up, pick up biesi's
retargeting patch, address the review comments, and drive it in... Then
we'd at least be able to implement "show in browser".
-Boris
Alex Faaborg
> attachments, or some parts that are attachments and some parts that
> aren't?
>
> (This isn't an idle question; there are government websites, or were
> as of a few years back, that had exactly this setup, and where if
> you ignored the content-disposition and showed the attachments
> inline you wouldn't be able to get at the data you really wanted).
Well clearly we need to um, detect that or something :) (we haven't
figured out all of the boundary cases where this fails, just trying to
look at the UI from a high level at this point, I don't think we've
even filed bugs yet).
-Alex
Alexander Limi
where we can improve is to be as transparent & friction-less as possible
when we can, ie. better defaults for what to do with files when you click to
download.
On the other hand, when you choose to special-case something (ie. explicitly
choose to download using the right-click menu), we should give you all of
the"explicit" options — you might want to rename the file and choose a
location when you save it.
There's also been talk about using indicators in the cursor/pointer to give
you a bit of warning before you click things that aren't actually web pages
(a small envelope icon for mailto:, a small document icon for PDFs, etc),
since these sometimes give unexpected results.
Look for a more detailed write-up on this on my site (and here) soon, since
this is something I really want to improve in Firefox 3.7.
--
Alexander Limi · Firefox User Experience · http://limi.net
On Tue, Dec 1, 2009 at 2:50 PM, Alex Faaborg <faa...@mozilla.com> wrote:
> A common refrain on the UX team is that if we are using a modal dialog box,
> we clearly must be doing something wrong :) Firefox's current download
> window behavior seems to be based more how browsers happen to have behaved
> in the past, so I think it is definitely worth revisiting the interface.
>
> This is something that Limi, Boriss and I have been discussing. I know John
> has been pushing on for a long time now, and Limi has been pushing on it
> pretty hard recently as well. The concept is to reframing the download UI
> to be a bit more like a print preview (see the content, bar on top with
> options), sort of a "download preview". Here is how it might work:
>
> -If the file is small and we can render the content being downloaded, we do
> -If the browser was instructed to pop up a download dialog box, a bar is
> displayed at the top of the page with commands to save the file, or to send
> the file to an external application
> -Similar to the download dialog box, users have the option of setting the
> default behavior (preview, download, send to external app), but we default
> to preview
> -We try to increase the set of files that we can preview in the browser to
> common types like PDF, and perhaps even other document types (although this
> has significant security implications, legal implications, and implications
> if we are only trying to promote open formats)
>
> Additionally, when a plugin is being used to render content in the content
> area (and the browser did not instruct Firefox to download the file), I
> believe we should display the same bar with command to download or open in
> an external application. In a lot of cases the user might be viewing a
> quicktime movie or listening to an MP3 and they think "how can I download
> this?" The actual answer is to go to File > Save As, but because that is so
> rarely done, people usually do not successfully come to that conclusion.
>
> In the event that a download can not be previewed (the user can't "stay on
> the Web"), or the user asked Firefox to remember another behavior for the
> type of content, like automatic download or automatically sending to another
> app, we should change the cursor icon to indicate the action when they hover
> on the link, so that they always know what is going to happen ahead of time.
>
> -Alex
Lance Duivenbode
> But its my browser, not yours. I am grateful that you take the extra
> work to help me by providing the option of saving rather than viewing.
> All I am asking for the the option of viewing rather than saving.
>
intuitive form, but in this case Boris is correct - Firefox is behaving
properly as per the HTTP/1.1 spec. Specifically:
If this header [content-disposition] is used in a response with the
application/octet- stream content-type, the implied suggestion is
that the user agent should not display the response, but directly
enter a `save response as...' dialog.
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1)
Frankly (and I mean no disrespect here) I was surprised that someone who
is engaged in such a high profile project such as Firebug did not seem
to recognise the headers as being the cause of this problem. Of course
you could have been trying to illustrate your point about the need to
re-work the UI in this area, but to me it appeared to be more a 'look
Firefox is doing this wrong' post - when in fact this is an issue for
the web server admin.
Cheers,
Lance
Alexander Limi
and handle it outside the browser (i.e. download in this case). But there
are lots of other things we can make better and/or have better defaults for.
--
Alexander Limi · Firefox User Experience · http://limi.net
On Tue, Dec 1, 2009 at 6:55 PM, Lance Duivenbode <
lduivenbo...@gmail.com> wrote:
> John J Barton wrote:
>
>> But its my browser, not yours. I am grateful that you take the extra work
>> to help me by providing the option of saving rather than viewing. All I am
>> asking for the the option of viewing rather than saving.
>>
>> I understand that Firefox could handle presenting user options in a more
> intuitive form, but in this case Boris is correct - Firefox is behaving
> properly as per the HTTP/1.1 spec. Specifically:
>
> If this header [content-disposition] is used in a response with the
> application/octet- stream content-type, the implied suggestion is
> that the user agent should not display the response, but directly
> enter a `save response as...' dialog.
>
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1)
>
> Frankly (and I mean no disrespect here) I was surprised that someone who is
> engaged in such a high profile project such as Firebug did not seem to
> recognise the headers as being the cause of this problem. Of course you
> could have been trying to illustrate your point about the need to re-work
> the UI in this area, but to me it appeared to be more a 'look Firefox is
> doing this wrong' post - when in fact this is an issue for the web server
> admin.
>
> Cheers,
> Lance
>
>
John J. Barton
> John J Barton wrote:
>> But its my browser, not yours. I am grateful that you take the extra
>> work to help me by providing the option of saving rather than viewing.
>> All I am asking for the the option of viewing rather than saving.
>>
> I understand that Firefox could handle presenting user options in a more
> intuitive form, but in this case Boris is correct - Firefox is behaving
> properly as per the HTTP/1.1 spec. Specifically:
>
> If this header [content-disposition] is used in a response with the
> application/octet- stream content-type, the implied suggestion is
An "implied suggestion" from the olden days does not, in my opinion,
raise to "MUST" or even "SHOULD".
> that the user agent should not display the response, but directly
> enter a `save response as...' dialog.
>
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1)
>
> Frankly (and I mean no disrespect here) I was surprised that someone who
> is engaged in such a high profile project such as Firebug did not seem
> to recognise the headers as being the cause of this problem. Of course
> you could have been trying to illustrate your point about the need to
> re-work the UI in this area, but to me it appeared to be more a 'look
> Firefox is doing this wrong' post - when in fact this is an issue for
> the web server admin.
I respectfully disagree. One of the most important and critical
decisions made early in the Web was "browser tolerance". If every
problem in a complex distributed system has to be adjudicated between
"browser fault" and "server fault" then we would all still be trying to
get RPC to work. Sure I agree completely that this particular server is
being less than helpful. But that is not our problem. Our problem is to
give the best user experience *given* that servers are less than helpful.
I do think that analyzing the potential impact of browser behavior
changes on the server ecosystem is important, but that is the right
level, not one server at a time.
Sorry if my post came across like "firefox sux". I should take some
lessons is "nicer writing".
jjb
Alexander Limi
However, we probably have to keep the default behavors, as a lot of web
sites are designed to make use of the content-disposition behavior to make
sure people get a downloadable file instead of showing it in the browser.
If you display it in the browser, there should be an easy way to open it in
a standalone app or save it to disk without digging through the menus,
though.
--
Alexander Limi · Firefox User Experience · http://limi.net
On Tue, Dec 1, 2009 at 9:58 PM, John J. Barton
<johnj...@johnjbarton.com>wrote:
> Lance Duivenbode wrote:
Dao
> Why couldn't we navigate to an "XUL error page" instead of showing a
> dialog? That might be a better way to handle downloads, helper apps, or
> in-browser display, even.
In a new tab? Otherwise you'd leave the source page, which wouldn't make
sense if you indeed wanted to download the file.
Axel Hecht
pasting the url, and prepend view-source: as protocol.
Then firefox shows the page as plain text.
Hacky, but I'm used to it by now.
Axel
Gervase Markham
> The could still use content-disposition:attachment and a correct MIME
> type and not have that concern....
Except that some old browsers (IE 6, I believe?) don't support
content-disposition: attachment. :-(
Gerv
Benjamin Smedberg
Why wouldn't it make sense? If I click on a link which would download a
file, what's wrong with navigating to a page to download the file? It's
certainly a different behavior from today, but it doesn't seem at all worse
than the current behavior of staying on a page which is normally useless to me.
--BDS
Charlie Powell
just run through, download each one. In this example, having the page
reload to a different preview/options page would be a major annoyance,
as it would require more clicks, pageloads, and time for the user.
---
Charlie Powell
Developer, Systems Administrator
pow...@powelltechs.com
Benjamin Smedberg
> There are many-a time when I have multiple links on a page that I'll
> just run through, download each one. In this example, having the page
> reload to a different preview/options page would be a major annoyance,
> as it would require more clicks, pageloads, and time for the user.
I would expect users to, in this case, middle-click the links for download,
just as they do currently for other kinds of links in a page. But perhaps
I'm atypical or am not predicting user behavior correctly.
--BDS
Boris Zbarsky
> Except that some old browsers (IE 6, I believe?) don't support
> content-disposition: attachment. :-(
Really? I was pretty sure IE6 did.... In any case, isn't it time to
drop IE6 support? ;)
-Boris
Charlie Powell
---
Charlie Powell
Developer, Systems Administrator
pow...@powelltechs.com
Boriss
> I think we all agree that it should be possible to override this behavior.
> However, we probably have to keep the default behavors, as a lot of web
> sites are designed to make use of the content-disposition behavior to make
> sure people get a downloadable file instead of showing it in the browser.
>
> If you display it in the browser, there should be an easy way to open it in
> a standalone app or save it to disk without digging through the menus,
> though.
And of course we come closer to solving these problems the more than
can be rendered in the browser (such as pdfs). But the summary seems
to be that if you never want to deal with a dialog, and especially if
you want to set what happens to every kind of file forever and never
be prompted again, it should be possible.
Nelson Bolyard
This is Bug 185618: Offer choice to open natively with Content-Disposition:
attachment (View/Show in browser)
which, two weeks from today, will be 7 years old.