The rendering of Word Documents should be worked into the browser. It would have to work like an adobe acrobat document (.pdf) does itwould automatically render in the browser. However if someone tried to open a document from their hard drive it goes into Word Viewer or Word if they are installed.
Oh, please, NO! <gag!> Maybe someone should write a plugin for this but it shouldn't be "built-in"!
I don't think this'll go far.
Agreed...not a real problem. Definately a "plugin" thing the browser itself should not be hampered with. Especially since so many usable solutions already exist. When feature for editing plugins/applications mine-types is in place, it would be as easy as to associate files of type "doc" with mswordview, available for Mac and Windows. A GNU licenced library also exists; wv, which can also translate doc to html. I use it on Linux with NC4.7 - works for me.
Since application/msword is on the list of media types at the IANA site -- http://www.isi.edu/in-notes/iana/assignments/media-types/media-types -- it is reasonable to expect Mozilla to recognize that media (MIME) type if a file is sent with that type in the Content-type: header, and allow the user to specify an application/plugin to handle it, but IMO that's as far as Mozilla should go.
Why does it matter whether it's on that list? The user should always be able to make a specific MIME type go to a specific application.
does mozilla recognise the .doc mime type?
I think so :-) My lxr.mozilla.org searches are inconclusive. Gerv
Including support for Word documents has the risk of encouraging the use of Word documents on the Web. Not good.
Sorry for the spam. New QA Contact for Browser General. Thanks for your help Joseph (good luck with the new job) and welcome aboard Doron Rosenberg
QA Contact: jelwell → doronr
confirming, adding helpwanted keyword and assigning to email@example.com until someone steps up to write the plugin.
Assignee: asa → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
There already are a few plug-ins for word docs (looks like they're Windows only, unfortunately): http://cgi.netscape.com/cgi-bin/plug-in_finder.cgi?application/msword If I try to download a word doc from http://www.hklib.org.hk/application.html, and click "More Info..." in the save dialog, I get forwarded to that plug-in finder page. (That wasn't very obvious.. I only discovered it after constructing the cgi url myself. And my browser window got hijacked to go to the plug-in page.) Does Mozilla do the same thing for pdf files, or does it prompt the user to download the plug-in?
Component: Browser-General → Plug-ins
I think this should be marked INVALID or WONTFIX (anyone agree?) because it doesn't make sense for Mozilla to nativly render Word native documents. I think the reporter may be refering to the fact that Win32 Internet Explorer invokes Word through OLE or ActiveX. A similar effect can be achieved by using a full-page plugin as we currently do for PDF (Acrobat). For Word, at least on my Windows 2000 with Office 2000, clicking on the URL link above and choosing "Open" does open the document in Word just fine.
Marking future and reassigning to chrisn.
Assignee: nobody → chrisn
Target Milestone: --- → Future
I disagree strongly with this bug. Webmasters are constantly trying to avoid IE's integration of known file types. If we add a way to avoid this, we would be adding a proprietary tag. Sam
Summary is a bit confusing, sounds like if Mozilla needs to be capable of showing word documents instead of open an embedded viewer.Someone wants to change it?
-> WONTFIX Even if someone does come up with the code, I doubt we can spare any programmer and QA resource to test it out... Better take this to www.mozdev.org or something like that
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WONTFIX
I'm trying to limit the Core:Plug-ins component to code related to the loading/hosting of plugins. As this is a request that the browser render word documents, it falls outside that scope. Thus, I'm dumping it into Core:General. This doesn't mean we're going to implement this, in fact, I'm going to verify that it's unlikely that we will. fwiw, pluginfinder seems dead, the closest seems to be: http://plugindoc.mozdev.org/winmime.php
Assignee: chrisn → nobody
Status: RESOLVED → VERIFIED
Component: Plug-ins → General
QA Contact: doronr → general
You need to log in before you can comment on or make changes to this bug.