110461 - view/edit all attachments discriminates against browsers that can't do IFRAME

Status: RESOLVED WONTFIX

(Bugzilla :: Attachments & Requests, defect)

Description

[timeless]

Mozilla/4.78 [en] (Windows NT 5.0; U).

image/gif 10/19/01 17:57 none Edit You cannot view the attachment on this page 
because your browser does not support IFRAMEs. View the attachment on a 
separate page.

we are going to fix it so that image/* will be dumped into right?
and can someone please explain why we don't dump everything else into <object>?

Please don't actively insult my web browser when it's fully capable of doing 
something quite sane.

Comment 1

[Dave Miller [:justdave]]

It might not be appropriate to just dump the attachment into the page itself,
since it could be huge.  How do you suggest solving this?  We could probably do
it with images, but we'd have to sniff the image size before linking it because
it still could be a really huge image...

Comment 2

[timeless]

I don't see how an <img> is any different from an <iframe> if you decide to 
limit iframes then you can use the same alg for <img>.

Comment 3

[Dave Miller [:justdave]]

The difference is an IFRAME is scrollable.  If the picture is huge, it still
takes up the same amount of screen real-estate on your screen on the view-all
page.  If it used an IMG tag instead of IFRAME, then if the picture was huge, it
would actually be huge, and would take up that amount of space in your browser
window that you would have to scroll past before you get to the next attachment.

Of course, you could always just write that off as one of the drawbacks of using
an older browser and live with the extra scrolling :-)

Comment 4

[Matthew Tuck [:CodeMachine]]

Maybe pass user-agent to the template and sniff it there.  We should probably
pass user-agent to all templates.

Comment 5

[Gervase Markham [:gerv]]

Dave: your "large" image problem is very much an edge case. I've never seen
enormous images attached to Bugzilla bugs and, even in that rare case, all that
happens is the user has to scroll a lot. 

We should definitely do inline-image for non-IFRAME browsers. 

Gerv

Comment 6

[Bradley Baetz (:bbaetz)]

bug 102957 got moved to 2.18, so moving this to match, as its not a show stopper
for 2.16.

Comment 7

[timeless]

Attachment: lots of fallback code

Comment 8

[timeless]

Comment on attachment 88391 [details] [diff] [review]
lots of fallback code

1. IE doesn't like application/x-javascript
i'm going to copy bonsai's CGI.pl hack
2. my IE doesn't have XMLSerializer

I have fixed 1. and almost have most of IE working, except i need a bit more
time to twiddle an alternative for 2, but landfill's httpd is down.

Comment 9

[Joel Peshkin]

Unloved bugs targetted for 2.18 but untouched since 9-15-2003 are being
retargeted to 2.20
If you plan to act on one immediately, go ahead and pull it back to 2.18.

Comment 10

[Max Kanat-Alexander]

This bug has not been touched by its owner in over six months, even though it is
targeted to 2.20, for which the freeze is 10 days away. Unsetting the target
milestone, on the assumption that nobody is actually working on it or has any
plans to soon.

If you are the owner, and you plan to work on the bug, please give it a real
target milestone. If you are the owner, and you do *not* plan to work on it,
please reassign it to [e-mail] or a .bugs component owner. If you are
*anybody*, and you get this comment, and *you* plan to work on the bug, please
reassign it to yourself if you have the ability.

Comment 11

[Frédéric Buclin]

Besides lynx which cannot use <iframe> but also cannot display images anyway, I don't know any recent browser which cannot display <iframe>.