Closed Bug 43556 Opened 24 years ago Closed 22 years ago

merge nsMIMEService w/ the extension handler

Categories

(Core Graveyard :: File Handling, defect, P1)

Product:
Core Graveyard
Component:
File Handling
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jud, Assigned: mscott)

References

Details

(Keywords: arch, memory-footprint, topembed+) 

right now the application handler service is seperate from the mime service when 
the two should be merged as they share the same underlying content.
This feature is needed to properly retrieve mime type information from the user
and the system defaults as well as the hard coded strings the mime service is
currently built on today.

Nominating for nsbeta2. Without this, we can't properly figure out mime types
for files we encounter outside of those hard coded content types.

Bug 43574 depends on this.
Blocks: 43574
Keywords: nsbeta2
not only do we have the static MIME type list problem w/ out this, but we're 
duplicating table code here which bites. this info needs to be centralized for 
maintenance reasons as well.
marking feature and needinfo.
Whiteboard: [feature][needinfo]
I don't think this is a feature....what more info do you need? I can come talk.
what kind of info is needed? between scott and I, it feels covered to me.
Is this required for the helper apps stuff or just a "good idea" to do anyway?
  If it's not required for the helper apps, or for other mail/news mime mapping
needs, then why should it be a beta 2 blocker?  I think this is the stuff the
PDT folks want to know ...


Hey Don, to answer your questions. By "mergine with the extension handler" I
mean make the mime service use the OS and user provided mime type information
the external handler has as well (or in replace of the hard coded string table).


With regards to what this is needed by:
1) mailnlews send uses this service to correctly set the content type of
attachmens it sends. Many attachments aren't getting the content type set
correctly because we don't find them in this hard coded table. So that's one
spot where it hurts us.
 (Bug #43574)
2) The other spot is when you click on local files or http files that don't
explicitly have the content type set on them. If these documents require a
helper app, necko is telling us the content type for these is unknown because it
can't find the content type in the hard coded string.

Hope that helps...
Putting on [nsbeta2-] radar. Not critical to beta2.  Adding "nsbeta3" keyword 
for consideration of a fix for that milestone.
Keywords: nsbeta3
Whiteboard: [feature][needinfo] → [nsbeta2-]
over to beta2+. This will reduce code duplication which impacts footprint.
Keywords: nsbeta3 → embed
Whiteboard: [nsbeta2-] → [nsbeta2+]
moving to M17.
Target Milestone: --- → M17
*** Bug 22954 has been marked as a duplicate of this bug. ***
Adding myself to cc: list.
Add cc to myself.
adding estimated completion date.
Whiteboard: [nsbeta2+] → [nsbeta2+] Est. 7/15
*sigh* I really really want this for nsbeta2 but given the decisions in the
leads meeting I definetly can't claim that I would hold nsbeta2 for this. We all
need to be down to one bug by tomorrow and this isn't going to be that one bug.
Marking nsbeta2- and adding nsbeta3 keyword. This will be the first thing I work
on for beta3.
Keywords: nsbeta3
Whiteboard: [nsbeta2+] Est. 7/15 → [nsbeta2-]
Blocks: 44692
Blocks: 38822
Keywords: arch, footprint
giving it the plus for embedding and footprint purposes per leger's seamonkey
leads email.
Status: NEW → ASSIGNED
Whiteboard: [nsbeta2-] → [nsbeta2-], [nsbeta3+]
*** Bug 47712 has been marked as a duplicate of this bug. ***
adding priority setting.
Priority: P3 → P1
PDT downgrading to P3 and putting [PDTP3] in the status whiteboard. Small
reduction in code footprint doesn't seem like P1 to us.
Priority: P1 → P3
Whiteboard: [nsbeta2-], [nsbeta3+] → [nsbeta2-], [nsbeta3+][PDTP3]
PDT: this isn't about footprint.  See Scott's comments from 6/23.  See also bug
47712, bug 38822, bug 43574 and bug 44692.


changing priority back to P1 so pdt can reconsider....i think they just
misunderstood this bug. This bug is a critical correctness bug for properly
handling extensions and content types the OS knows about that don't fall into
the hard coded list of strings the mime service currently uses.
Priority: P3 → P1
Ok, sorry, that's the fun of triaging a couple hundred bugs at a time :-)
*** Bug 43574 has been marked as a duplicate of this bug. ***
Whiteboard: [nsbeta2-], [nsbeta3+][PDTP3] → [nsbeta2-], [nsbeta3+][PDTP1]
Update: I have this impelemented in my tree for windows. I'm starting to work on
the Mac now. We should be finished and reviewed by tomorrow afternoon.
Okay I think we are ready to go on this one. I'll get code reviews from valeski
and paul chen (I had to make some changes to nsInternetConfigService.cpp) tomorrow.
Whiteboard: [nsbeta2-], [nsbeta3+][PDTP1] → [nsbeta2-], [nsbeta3+][PDTP1] ETA: 9/13
adding myself to CC
I fixed this last Thursday night. Windows and Mac nsMIMEService implementations
are using the windows regsitery and internet config for determining mime type
information.

As a result, the following things should be working now:
1) Outgoing mail with attachments should have the correct content type assigned
to the attachments. to Test, on windows send a .xls and a .doc file to yourself.
receive the message and view source. You should see that the content types for
these attachments matches the type (msword, msexcel, etc.). Before, we would
have said the content type was unknown.

2) I believe plugins needed this as well. I'll let av comment about what should
be tested in that arena to verify this fix.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Thanks, Scott. Just sample code on how to retrieve mime type out of the file 
extension.
For plugins, shouldn't the mozilla plugin registry be checked before going out 
to the native OS?  Plugins register file extensions with the browser - see 
nsPluginHostImpl::RegisterPlugin - 
http://lxr.mozilla.org/seamonkey/source/modules/plugin/nglsrc/nsPluginHostImpl.c
pp#1676

True. And I think we do this if the plugin is available, there is a method 
IsPluginEnabledForExtension if I remember correctly. But we also need to know a 
mime type when there is no plugin registered to tell the default plugin where to 
go to get the needed plugin. That's what I think should fix 44692.
setting QA to esther for verification
QA Contact: tever → esther
QA Contact: esther → pmock
This is related...  In full screen mode when I try to load a file with a MIME 
type associated with one of my plug-ins, I get the "Save" box that allow me to 
specify a helper.  I have a plug-in in the plugins directory that handles this 
MIME type, it should load it full screen.  In the DLL info, the MIME types it 
supports are registered and Netscape 4.x and IE have no problem with this.

For kicks I added the following to mimetypes.rdf in my profile just to see if 
it would help (it didn't):

  <Description about="urn:mimetype:application/x-interact"> 
    <NC:value>application/x-interact</NC:value> 
    <NC:description>InterAct Exercise</NC:description> 
    <NC:editable>false</NC:editable> 
    <NC:fileExtensions>ipt</NC:fileExtensions> 
    <NC:handlerProp>
      <NC:handler about="urn:mimetype:handler:application/x-interact"> 
        <NC:saveToDisk>true</NC:saveToDisk> 
        <NC:handleInternal>true</NC:handleInternal>
        <NC:externalApplicationProp>
          <NC:externalApplication> 
            <NC:prettyName></NC:prettyName> 
            <NC:path></NC:path> 
          </NC:externalApplication> 
        </NC:externalApplicationProp>
      </NC:handler> 
    </NC:handlerProp> 
  </Description> 

Grab the plug-in here: http://demomml.intellipro.com/npdebug.zip
Test here: http://demomml.intellipro.com/i0101001.ipp

Yes, my server has the MIME type registered (if you click on advanced when you 
get the popup, you'll see the correct MIME type show up).

Tested in latest nightly windows build.
Still not working in 0.9.6 build.  This is the last item keeping our plug-in 
from working in Mozilla.  The home stretch!  Please reopen this bug or create a 
new one if warranted.
This is still appearing, can we get going on this again, please?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Removing PDT grafitti from the status whiteboard.
Whiteboard: [nsbeta2-], [nsbeta3+][PDTP1] ETA: 9/13
Have I filed this in the right place?  This seems like the sort of issue that 
would affect more than just my plug-in in full screen mode.
Fixed in 0.9.7!
Depends on: 120590
What still needs to be done here?  This bug is fixed as originally described
(the mime service and the extension handler are one).  Is this a tracker for
futher issues?  Is this waiting on bug 120590?  Should this just be closed out?
Keywords: embed → topembed
Keywords: topembed → topembed+
I believe this was reopened because it actually wasn't fixed back in 0.9.7.
rpotts indicated such to me over the phone.
Target Milestone: M17 → ---
Why in the heck does it take three years to fix this, when it makes all plugins
virtually unusable, and therefore keeps Netscape 6 from being of much use to
most people?
I'm extremeley confused. This bug was fixed ages ago. We've been reading
mimetypes from the OS (which is what this bug was about) for some 2+ years in
our apps. If there's something in particular that is not working it should be
tracked in a new bug. This is definetly in 0.9.7. We implemented it back in
September of 2000. reclosing.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → FIXED
Fine.  Then up the priority on the real bug, 38822, to P1/critical, which it
should have been all this time, and get it fixed! 

The essence of bug 38822 is that no plugins are started based on full-page http
MIME types, except apparently for a hack for PDF and real player mime types. 
38822 cites the Quick View plugin, I can only speak for the SwiftView plugin
(www.swiftview.com):

I downloaded the nightly build on 1/28/02, installed on Windows ME,
installed our SwiftView plugin (via Internet Explorer, since there still is no
Smart-Update installation support in Mozilla), copied the npsview.dll to the
Mozilla plugins directory (since we haven't added Mozilla/NS 6 to our installer
since they don't work yet), and find that:

Good:
 - there is now a help...about...plugins (wonderful!) - and refresh shows our
plugin correctly.  Just to be sure, I restarted Mozilla, and:
 - typing a path to a file in the address bar correctly starts and runs our
plugin.

Failed:
 - typing a URL to a file of our plugin's suffix in the address bar, or clicking
on a file: or http: url on a web page try to run the Windows application
registered for the suffix instead of the plugin.
 - an EMBED of a SwiftView-suffix file starts our plugin, but it's unable to
display the file in the page  It only works in a mode we support that displays
the file in an external window.  This we could investigate further, perhaps find
a workaround on our end...but it has always worked fine in NS 4.x...and has been
broken this way in Mozilla since at least Feb 2001.

-> file handling, as I understand it.
Component: Networking → File Handling
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.