176142 - microsoft.com - Outlook Web interface sends wrong content-disposition to non-IE

Status: RESOLVED INVALID

(Tech Evangelism Graveyard :: English US, defect)

Description

[Brion Swanson]

When attempting to view a jpeg image Mozilla (1.2b) prompts to view or save the
file.  Aside from this odd behavior (browser should be able to view jpeg images
natively), when I specify that the program /usr/bin/eog should be used to view
this type of file and I uncheck "Ask me every time for this type of file" the
next time I go to view a jpeg, I am prompted again.

I have tried restarting the application after setting the default viewer.  I
have looked at the Helper Applications in the Preferences menu and the
application is properly registered there. Yet, nothing seems to make Mozilla
recognize that this file type has an associated viewer (even though if I click
on Advanced, it remembers what my last associated view was).

On a side note:  if I click on 'Advanced' from the file type prompt dialog and
then exit from the Advanced dialog, the 'OK' button is disabled until I click
the 'Browse' button and 'OK' or 'Cancel' out of that dialog, at which point the
'OK' button is enabled again for the main file type prompt dialog.

Comment 1

[Andrew Schultz]

is this with local files or a URL?  if with a URL, please specify what it is.

Comment 2

[Brion Swanson]

It's a URL, but unfortunately, you won't be able to test it because it's
generated and given to me by Microsoft's Outlook Web interface.  Mozilla
recognizes the type of file (image/jpeg), but doesn't remember what to do with
the file only in this case.  If I open an mpeg from another URL (say, a web
page) and tell Mozilla to remember which application I chose, it will.  Only
files from URLs given to me by Outlook Web interface cause amnesia in Mozilla. 
The URL is valid for the session, meaning I get the file if I save it or view
it, but I just can't get Mozilla to snap out of it's daze when it starts to
download an attachment from Outlook's web interface.

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

bz: This was fixed with bug 86440, right?

reporter: This should be fixed in Mozilla 1.3beta.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Actually, I think the only case in which we would fail to view a jpeg inline is
if the sending server explicitly lists it as content-disposition:attachment
(which I bet the Web version of Outlook does for email attachments).....  What
we should really be doing is disabling the "ask me again" checkbox in those
cases, since we won't be following it -- we will always prompt for "attachments".

Brion Swanson, could you check a couple of things for me?

1)  Does Mozilla still behave as you describe?
2)  How does IE behave (if you have access to IE)?
3)  What http headers does the server send?  

For item #3 you can log headers by setting the environment variable
"NSPR_LOG_MODULES" to "nsHttp:5" and "NSPR_LOG_FILE" to some filename.  After
that, start Mozilla, load as few pages as possible to get to the problem url
(the logging is _very_ verbose), then once you reproduce the problem quit
Mozilla and attach the log file to this bug using
http://bugzilla.mozilla.org/attachment.cgi?bugid=176142&action=enter

Comment 5

[Brion Swanson]

Attachment: HTTP headers requested by bzbarsky

Here are the HTTP headers for two sessions wherein I duplicated this bug in
Mozilla 1.2b and Mozilla 1.3b on Linux RedHat 8.0.  Additionally, Mozilla 1.3b
has worsened the problem by not even running the selected program (in this
case, eog).

Comment 6

[Brion Swanson]

> 1)  Does Mozilla still behave as you describe?

Yes, both 1.2b and 1.3b exhibit the same behavior.  Additionally, 1.3b does not
run the chosen program (eog) when I select 'Open with Program'.  It also does
not remember my selected program between repeated clicks on the attachment link
much less between sessions.

> 2)  How does IE behave (if you have access to IE)?

IE 6.0 running on Windows 2000 SP2 behaves as expected.  The jpeg attachement is
opened in a new window.

> 3)  What http headers does the server send?

Attached per the last comment.

Comment 7

[Brion Swanson]

I would like to note that the Galeon web browser that comes with RedHat 8.0 (and
is based on Mozilla I believe, though I don't know which version) works as
expected with the jpeg attachment.  That is, it opens a new window containing
the image.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> content-disposition: attachment;filename=seismo.jpg

is what the server says.  That means "Do not render inline".  As far as I knew,
IE responded to this header by opening a save dialog (not even allowing it to be
handled in a helper application).  Is that not correct?  I don't have access to
IE, so someone will have to do some testing....

This is the second report I've seen of not running the selected program too....
I'll look into that.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Brion, one more thing... Could you possibly load the url in question in IE
through http://webtools.mozilla.org/web-sniffer/ ?  That will tell you what
headers the server is sending; I'm wondering whether they send IE the same
headers they send us....

Marking dependency on bug 192811 for the additional issue you see with 1.3b.

Comment 10

[Brion Swanson]

Boris,  I tried running the URL through http://webtools.mozilla.org/web-sniffer
but the web-sniffer refused to tackle https:// connections which is what Outlook
Web Interface was using.

Comment 11

[Boris Zbarsky [:bzbarsky]]

hmmm.. Darin?  Ben? Are there any decent ways to sniff the headers?  (I assume
no, for an https connection IE is making.... :( )

Comment 12

[Darin Fisher]

bz: nope... the headers would be encrypted.

Comment 13

[Darin Fisher]

bz: actually, what if you fake mozilla's useragent string?  there's a preference
to override the UserAgent header sent by moz.  general.useragent.override iirc.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Oh, good point....  Brion, could you try that?

user_pref("general.useragent.override", ".....");

where the "....." should be whatever IE reports its useragent as?  (type
"javascript:document.write(navigator.userAgent)" in IE's URL bar, hit enter,
then copy it from the content area

Comment 15

[Brion Swanson]

Where do I set that user_pref?  I tried the javascript console and using
javascript:user_pref but it fails with 'user_pref not defined'.  Am I trying to
make Mozilla appear to be IE? I'm a little confused on what you're trying to do
with which browser since I have to flip between two machines (linux vs. Windows)
and manually type in URLs and such between them.  I'm happy to do it, I just
need to be sure of what I'm supposed to be doing.  Thanks!

Comment 16

[Boris Zbarsky [:bzbarsky]]

Brion, the simplest way to add that pref in a recent build is probably to type
"about:config" in the URL bar, then right-click and select to add a new string
pref (if you do this, you don't need the "user_pref" part -- just the name and
value of the pref). To be safe, restart Mozilla after doing that.

In an older build, you will want to edit the file prefs.js while Mozilla is not
running.

The goal here is to make Mozilla look like IE to the site and see whether the
behavior changes.... (that is, trying to test the possibility of the site
sending different headers to Mozilla and IE).

Comment 17

[Brion Swanson]

Attachment: http headers from Mozilla 1.2b and 1.3b with general.useragent.override set

I changed the general.useragent.override to make Mozilla (1.2b and 1.3b) look
like MSIE 6.0 and saved the http header information into the attached files
(once again bzipped).  I took a look at them based on what you told me last
time
and here's what the content-disposition of the same attachment is when IE talks

to Outlook:

  content-disposition: inline;filename=seismo.jpg

Isn't that nice?  MS Outlooks treats MS browsers differently than any other (or

at least Mozilla) browsers.  Needless to say, it works fine when Mozilla is
pretending to be IE.

Comment 18

[Brion Swanson]

bz:  I'm not sure how much help it is (if any), but I attempted to capture the
http headers of Galeon in the same manner as Mozilla (since it's based on
Mozilla) but it didn't heed the NSPR_LOG_* variables.  I was able, however, to
locate the prefs.js file and extract the general.useragent.override for you:

user_pref("general.useragent.override", "Mozilla/5.0 Galeon/1.2.6 (X11; Linux
i686; U;) Gecko/20020830");

Again, I'm not sure this will help, but I thought it might be useful to see what
Galeon is sending to MS Outlook Web Interface that appears to receive the
inline: disposition because the picture opens up properly.

Comment 19

[Brion Swanson]

Attachment: Phoenix running as Galeon 1.2.6 via general.useragent.override

bz:  Just trying other variations of the Mozilla/Outlook Web Interface puzzle;
I'm at work running Phoenix 0.4 with the following added to my prefs.js

user_pref("general.useragent.override", "Mozilla/5.0 Galeon/1.2.6 (X11;
Linuxi686; U;) Gecko/20020830");

I've recorded the http header information and attached it.  It appears that
Galeon may be doing extra work to sniff out the jpeg files since Outlook still
sends:	content-disposition: attachment;filename=seismo.jpg.  Phoenix also
works if the useragent is set to MSIE 6.0.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Yeah.. the problem is, for a while IE was the only browser that supported
"content-disposition:attachment".  Which is why Outlook treats it specially... 
(sounds like Galeon still does not support it).

This is tech evangelism, though I'd love to hear suggestions about how I can
make our treatment of content-disposition:attachment less annoying (note that IE
will just open a file picker when given such a content-disposition, giving you
no option but to save the file to disk....).  I don't really like us ignoring
the "never ask" setting like that... anything we can do to make that better? 
(private mail or a separate bug on that, please).

Comment 21

[Bob Clary [:bc] (inactive)]

tech evang june 2003 reorg

Comment 22

[Karl Dubost💡 :karlcow]

Outlook Web doesn't exist anymore. It is replaced by mail.live.com
https://mail.live.com/