Closed Bug 103934 Opened 23 years ago Closed 22 years ago

full-page PNG images use QuickTime plugin to render even when told not to

Categories

(Core Graveyard :: Plug-ins, defect, P3)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
PowerPC
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
mozilla1.0

People

(Reporter: mozilla.org, Assigned: peterlubczynski-bugs)

References

(
URL
)

Details

Attachments

(2 files)

Simple embed tag with png src
290 bytes, text/html
Details
Screen shot of attempt to load local png file.
33.18 KB, image/jpeg
Details 
Mozilla uses QuickTime to render some pngs even if QuickTime is set not to
handle image/png. 0.9.4 build 2001100905 on Mac OS X 10.1.

To reproduce:
1. Open System Preferences->QuickTime->Plug-In->MIME settings. Uncheck image/png
2. Open Mozilla and visit the link above

Mozilla uses Quicktime to render the image, even though it should use its own
native code to render the image.

This is not the same problem as I reported in bug 69719.
could u mention ur quicktime version ? we had a bug on this...where...once u 
update ur quicktime version to the latest, this works fine. 
I had a similar problem a while ago, whne I installed 0.9.4. I believe I solved
it by resetting QT to its defaults, and then disabling PNG again. 
This is Mac OS X, QuickTime Plug-in 5.0.2
I noticed if I completely disable all image options in the QT Plug-in MIME
section (System Preferences) and reboot machine, the QT plug-in is still used to
rendered the PNG file. Tested under Mac OS X 10.1 using QT Plugin 5.0.2. Not
sure what MS IE or OmniWeb do when the QT image support is disabled. Let me check...


If QT image support for the QT plug-in is disabled, 

IE 5.1 downloads the file and opens Preview app to view it.
OmniWeb 4.0.5 opens and renders the file directly without QT assistance.
This comment is from bug 69719:

------- Additional Comments From Eric Carlson 2001-09-20 09:42 -------

To clarify, configuring the QT plug-in to not handle a given MIME type just 
removes the strings for that MIME type from it's resources. The browser uses 
these strings to see what a plug-in is capable of handling, so Mozilla should 
then not consider it when deciding what to do with that MIME type. If it chooses 
the QT plug-in for a MIME type that QuickTime can deal with, it will display it 
no matter what it's resources say.
Can someone try Qucktime PNG files in the embedded mode (i.e. using an EMBED
tag)? Does this behave as intended?

Can someone try both full-page and embedded on a Mac Classic build? Thanks!
Assignee: av → peterlubczynski
Status: UNCONFIRMED → NEW
Ever confirmed: true
If the png is used via the embed tag, NS/Fizzilla will render the png by itself.
If the PNG file is opened directly, the QT plug-in is always used regardless if
image MIME (in the QT plugin) is disabled. Tested under Mac OS X 10.1
Confirming that this happens ONLY on OS X and ONLY for full-page mode. Even
though the Quicktime settings have PNG unchecked, Mozilla still uses the plugin
to render the image, even after a reboot.

Could be a problem in the uriloader?
Priority: -- → P3
Target Milestone: --- → mozilla0.9.6
Maybe the MIME settings?
Summary: Mozilla uses QuickTime to render some png files even if QuickTime is set not to handle image/png → OSX: PNG images use QuickTime plugin to render even when told not to
I'm now getting a crash from inside the QuickTime plugin when QuickTime tries to 
render a standalone PNG.  This does not happen with the example PNG that's in the 
attachment, however it does happen with a PNG I created with GraphicConverter.

The example PNG is: http://web.sabi.net/ups.png (and if anyone has any idea why a 
parcel sent from Pennsylvania to Illinois goes back to Pennsylvania, let me know :-)

Here's the CrashReporter log, which seems to say that it's crashing inside the 
QuickTime plugin.

Date/Time:  2001-10-25 01:23:24 -0500
OS Version: 10.1 (Build 5L14)

Command:    Mozilla
PID:        661

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x049d9000

Thread 0:
 #0   0x758cb670 in DoConvertTextFromISOLatin1
 #1   0x758ca750 in DoAddUserDataText
 #2   0x7595fbd0 in HandleData_tEXt
 #3   0x759cb7d8 in ReadPNG
 #4   0x75969410 in ImportPNGGetMetaData
 #5   0x70249530 in CallComponentFunctionCommon
 #6   0x75969024 in ImportPNGComponentDispatch
 #7   0x7024cc1c in CallComponent
 #8   0x70254df8 in CallComponentDispatch
 #9   0x73fe3538 in GraphicsImportGetMetaData
 #10  0x758e8c50 in EatGraphicDataRef
 #11  0x7024968c in CallComponentFunctionCommon
 #12  0x758e88e8 in EatGraphicComponentDispatch
 #13  0x7024cc1c in CallComponent
 #14  0x70254df8 in CallComponentDispatch
 #15  0x74006404 in MovieImportDataRef
 #16  0x04ebd3f8 in 0x4ebd3f8
 #17  0x04eba95c in 0x4eba95c
 #18  0x04ebeb84 in 0x4ebeb84
 #19  0x04eb9430 in 0x4eb9430
 #20  0x032503d8 in 
OnDataAvailable__24ns4xPluginStreamListenerFP19nsIPluginStream
 #21  0x0325aa5c in 
OnDataAvailable__26nsPluginStreamListenerPeerFP10nsIRequestP11
 #22  0x03271cb4 in PluginListener::OnDataAvailable(nsIRequest *, nsISupports *,  *)
 #23  0x0282e6b0 in 
OnDataAvailable__18nsDocumentOpenInfoFP10nsIRequestP11nsISuppo
 #24  0x027a7ff0 in 
OnDataAvailable__13nsHttpChannelFP10nsIRequestP11nsISupportsP1
 #25  0x0278af1c in nsOnDataAvailableEvent::HandleEvent(void)
 #26  0x02799704 in nsARequestObserverEvent::HandlePLEvent(PLEvent *)
 #27  0x005c2f08 in PL_HandleEvent
 #28  0x005c2d84 in PL_ProcessPendingEvents
 #29  0x0056a0c8 in nsEventQueueImpl::ProcessPendingEvents(void)
 #30  0x028b2028 in nsMacNSPREventQueueHandler::ProcessPLEventQueue(void)
 #31  0x028b1dec in nsMacNSPREventQueueHandler::RepeatAction(EventRecord 
const &)
 #32  0x028db768 in Repeater::DoRepeaters(EventRecord const &)
 #33  0x028c6b74 in nsMacMessagePump::DispatchEvent(int, EventRecord *)
 #34  0x028c6740 in nsMacMessagePump::DoMessagePump(void)
 #35  0x028c5fd0 in nsAppShell::Run(void)
 #36  0x02683cdc in nsAppShellService::Run(void)
 #37  0x0049faf8 in main1(int, char **, nsISupports *)
 #38  0x004a0680 in main
I think you are now seeing bug 105935. The crash should not happen in the 0.9.4
dailies.
Loading the same PNG in QuickTime Player causes it to crash, too.  I forgot to mention 
that in my original message.  I have reported the problem to Apple as a QuickTime bug 
(2796503).

I'm simply adding the case because this bug could now have a more serious effect: I 
can't get my PNG displayed without removing the QuickTime plugin.  Having to quit and 
restart Mozilla, removing the plugin and adding it back again, isn't really a very effective 
workaround.

I don't have another OS X machine to test on, so it would help if someone else with 
10.1 could try loading the image URL I posted (http://web.sabi.net/ups.png) in QuickTime 
Player or Mozilla with the plugin enabled.  If they don't get a crash, then it's 
configuration-specific and this bug is just an annoyance.  QuickTime 5.0.1 in Classic 
does not crash on this image, on my system.

The reason why I suspect this may be specific to my configuration is that I've been 
having strange font problems ever since upgrading to 10.1 (certain fonts just aren't 
recognized by apps that use ATS/ATSUI for rendering, but they work fine in Carbon apps 
that just call traditional font rendering) - though why, or if, QuickTime needs fonts to 
render a PNG, I have no idea.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.6 → mozilla0.9.7
http://web.sabi.net/ups.png crashes mozilla build 2001103005, on 10.1

crashreporter log:

Date/Time:  2001-10-28 12:10:24 -0500
OS Version: 10.1 (Build 5L14)

Command:    Mozilla
PID:        292

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x0000001c

Thread 0:
 #0   0x00606058 in nsComponentManagerImpl::FreeServices(void)
 #1   0xbffff71c in 0xbffff71c
 #2   0x0063ab34 in NS_ShutdownXPCOM
 #3   0x00545698 in main

Thread 1:
 #0   0x70001308 in mach_msg_overwrite_trap
 #1   0x70006394 in mach_msg
 #2   0x700273dc in _pthread_become_available
 #3   0x700270d4 in pthread_exit
 #4   0x70020f00 in _pthread_body
 #5   0x90010008 in 0x90010008

Thread 2:
 #0   0x7000530c in syscall
 #1   0x70557590 in BSD_waitevent
 #2   0x70554a30 in CarbonSelectThreadFunc
 #3   0x70020efc in _pthread_body

Thread 3:
 #0   0x7003fe48 in semaphore_wait_signal_trap
 #1   0x7003fc48 in _pthread_cond_wait
 #2   0x705594ac in CarbonOperationThreadFunc
 #3   0x70020efc in _pthread_body

Thread 4:
 #0   0x70043988 in semaphore_timedwait_signal_trap
 #1   0x70043968 in semaphore_timedwait_signal
 #2   0x7003fc38 in _pthread_cond_wait
 #3   0x7028366c in TSWaitOnConditionTimedRelative
 #4   0x7027cf10 in TSWaitOnSemaphoreCommon
 #5   0x702c14c8 in TimerThread
 #6   0x70020efc in _pthread_body


PPC Thread State:
  srr0: 0x00606058 srr1: 0x0200f030                vrsave: 0x00000000
   xer: 0x0000001c   lr: 0x0063ab34  ctr: 0x006012b8   mq: 0x00000000
    r0: 0x0063ab34   r1: 0xbffff640   r2: 0x0017d000   r3: 0x00000000
    r4: 0x00000000   r5: 0x00000000   r6: 0x80000000   r7: 0xbffff664
    r8: 0x001846d4   r9: 0x0018472c  r10: 0x447bc000  r11: 0x22000244
   r12: 0x0017704c  r13: 0x00000000  r14: 0x00000036  r15: 0x00058eb0
   r16: 0x00000001  r17: 0x80160e88  r18: 0x0005a938  r19: 0x00001607
   r20: 0x00000000  r21: 0x0000001c  r22: 0x70004bc4  r23: 0x70004c58
   r24: 0x7016b214  r25: 0x006bac3c  r26: 0x8081ab5c  r27: 0xc0d19400
   r28: 0x00000000  r29: 0xbfffef00  r30: 0x6b36c6dc  r31: 0x00000001

**********

Date/Time:  2001-10-31 19:32:48 -0500
OS Version: 10.1 (Build 5L14)

Command:    Mozilla
PID:        299

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x04545000

Thread 0:
 #0   0x758cb660 in DoConvertTextFromISOLatin1
 #1   0x758ca750 in DoAddUserDataText
 #2   0x7595fbd0 in HandleData_tEXt
 #3   0x759cb7d8 in ReadPNG
 #4   0x75969410 in ImportPNGGetMetaData
 #5   0x70249530 in CallComponentFunctionCommon
 #6   0x75969024 in ImportPNGComponentDispatch
 #7   0x7024cc1c in CallComponent
 #8   0x70254df8 in CallComponentDispatch
 #9   0x73fe3538 in GraphicsImportGetMetaData
 #10  0x758e8c50 in EatGraphicDataRef
 #11  0x7024968c in CallComponentFunctionCommon
 #12  0x758e88e8 in EatGraphicComponentDispatch
 #13  0x7024cc1c in CallComponent
 #14  0x70254df8 in CallComponentDispatch
 #15  0x74006404 in MovieImportDataRef
 #16  0x047b83f8 in 0x47b83f8
 #17  0x047b595c in 0x47b595c
 #18  0x047b9b84 in 0x47b9b84
 #19  0x047b4430 in 0x47b4430
 #20  0x02e5f478 in OnDataAvailable__24ns4xPluginStreamListenerFP19nsIPluginStream
 #21  0x02e69c8c in OnDataAvailable__26nsPluginStreamListenerPeerFP10nsIRequestP11
 #22  0x02e8131c in PluginListener::OnDataAvailable(nsIRequest *, nsISupports *,  *)
 #23  0x0244abd8 in OnDataAvailable__18nsDocumentOpenInfoFP10nsIRequestP11nsISuppo
 #24  0x023a3460 in OnDataAvailable__19nsStreamListenerTeeFP10nsIRequestP11nsISupp
 #25  0x023b76b4 in OnDataAvailable__13nsHttpChannelFP10nsIRequestP11nsISupportsP1
 #26  0x0239a02c in nsOnDataAvailableEvent::HandleEvent(void)
 #27  0x023a8a68 in nsARequestObserverEvent::HandlePLEvent(PLEvent *)
 #28  0x006685bc in PL_HandleEvent
 #29  0x00668438 in PL_ProcessPendingEvents
 #30  0x0060f6a8 in nsEventQueueImpl::ProcessPendingEvents(void)
 #31  0x02483178 in nsMacNSPREventQueueHandler::ProcessPLEventQueue(void)
 #32  0x02482f3c in nsMacNSPREventQueueHandler::RepeatAction(EventRecord const &)
 #33  0x024ac66c in Repeater::DoRepeaters(EventRecord const &)
 #34  0x024978c0 in nsMacMessagePump::DispatchEvent(int, EventRecord *)
 #35  0x0249748c in nsMacMessagePump::DoMessagePump(void)
 #36  0x02496de8 in nsAppShell::Run(void)
 #37  0x0228fd2c in nsAppShellService::Run(void)
 #38  0x005453f4 in main1(int, char **, nsISupports *)
 #39  0x00545f9c in main

Thread 1:
 #0   0x70001308 in mach_msg_overwrite_trap
 #1   0x70006394 in mach_msg
 #2   0x700273dc in _pthread_become_available
 #3   0x700270d4 in pthread_exit
 #4   0x70020f00 in _pthread_body
 #5   0x90010008 in 0x90010008

Thread 2:
 #0   0x7000530c in syscall
 #1   0x70557590 in BSD_waitevent
 #2   0x70554a30 in CarbonSelectThreadFunc
 #3   0x70020efc in _pthread_body

Thread 3:
 #0   0x7003fe48 in semaphore_wait_signal_trap
 #1   0x7003fc48 in _pthread_cond_wait
 #2   0x705594ac in CarbonOperationThreadFunc
 #3   0x70020efc in _pthread_body

Thread 4:
 #0   0x70043988 in semaphore_timedwait_signal_trap
 #1   0x70043968 in semaphore_timedwait_signal
 #2   0x7003fc38 in _pthread_cond_wait
 #3   0x7028366c in TSWaitOnConditionTimedRelative
 #4   0x7027cf10 in TSWaitOnSemaphoreCommon
 #5   0x702c14c8 in TimerThread
 #6   0x70020efc in _pthread_body

Thread 5:
 #0   0x7003fe48 in semaphore_wait_signal_trap
 #1   0x7003fc48 in _pthread_cond_wait
 #2   0x702505cc in TSWaitOnCondition
 #3   0x7027cef8 in TSWaitOnSemaphoreCommon
 #4   0x7024386c in AsyncFileThread
 #5   0x70020efc in _pthread_body

Thread 6:
 #0   0x7003fe48 in semaphore_wait_signal_trap
 #1   0x7003fc48 in _pthread_cond_wait
 #2   0x7055b9b4 in CarbonInetOperThreadFunc
 #3   0x70020efc in _pthread_body


PPC Thread State:
  srr0: 0x758cb660 srr1: 0x0200d030                vrsave: 0x00000000
   xer: 0x20000004   lr: 0x758cb640  ctr: 0x7000608c   mq: 0x00000000
    r0: 0x00000020   r1: 0xbfffe390   r2: 0x04502680   r3: 0x00000000
    r4: 0x00000000   r5: 0x00000000   r6: 0x00000000   r7: 0x00000000
    r8: 0x00000007   r9: 0x00000000  r10: 0xbfffe310  r11: 0x04502424
   r12: 0x7024f950  r13: 0x00000000  r14: 0x00000033  r15: 0x00059310
   r16: 0x00000001  r17: 0x80160e88  r18: 0x0005c098  r19: 0x00001807
   r20: 0x00000000  r21: 0x0000001c  r22: 0x70004bc4  r23: 0x70004c58
   r24: 0x7016b214  r25: 0x006bac3c  r26: 0x8081ab5c  r27: 0xc0d19400
   r28: 0x00000000  r29: 0xbfffef00  r30: 0x6b36c6dc  r31: 0x00000001

**********


That stack is for bug 105935 but the buildID indicates it was made about 6 hours
after dp's checkin! Petersen, can you verify bug 105935?
I'm seeing this on Win95. My MIME settings for QuickTime specify that the
plug-in not be used to display pngs. The images on web pages render fine in
Mozilla, but standalone images are displayed using the QT plug-in. (using build
2001112003)
Keywords: mozilla1.0
Summary: OSX: PNG images use QuickTime plugin to render even when told not to → OSX: full-page PNG images use QuickTime plugin to render even when told not to
Whiteboard: [only for full-page plugins]
Target Milestone: mozilla0.9.7 → mozilla1.0
This affects Win32 as well and it's very annoying!

I've gone into the QT control panel and disabled support for image/png &
image/x-png and it still tries to render it. The plugin that handles this format
is npqtplugin4.dll, which is part of QT 5.0.1. Short of deleting it, I believe
QT will always be invoked to handle fullscreen PNG.

Surely stuff like html, css, xml, jpg, gif, png etc. should be handled
internally no matter what plugins are installed?
OS: MacOS X → All
Hardware: Macintosh → All
Summary: OSX: full-page PNG images use QuickTime plugin to render even when told not to → full-page PNG images use QuickTime plugin to render even when told not to
wfm using build 2001112903 on Win2k with QT 5.0.2.

On Win32 platforms, this bug is fixed when using QT 5.0.2+. Not 5.0.1 and lower
version. Don't know about other platforms. See bg 104506 for plug-ins release notes.
Yeah, I recall seeing in other bug report that 5.02 fixes the problem, but I
guess not on Mac, see comment #3.
Hardware: All → Macintosh
Whiteboard: [only for full-page plugins] → [fixed on Win32 with Quicktime 5.02, only for full-page plugins on Mac]
This is an annoyance to Bugzilla users because PNG attachments to bugs are given
this treatment by the attachment viewer.
The version of QT I had installed was 5.0.2. In about:plugins I noticed that it
also listed an older version of the plugin I had in a Netscape 4.x profile. I
installed the new plugins in that profile and now about:plugins no longer lists
a plugin for that profile, and png images are now displayed correctly. 

Why would Mozilla list a plugin contained in a 4.x profile?
This bug exposes a problem in Mozilla that it should not be allowing plugins or
helpers to override it's "core" data types, at least not by default.


win2k:
I still saw this bug today with QT 5.0.2 (image/png unchecked in QT settings)
and mozilla 2001112603. Then I uninstalled QT, downloaded the newest version of
QT 5.0.2 (standalone installer) and installed this one. Now everything works fine.

Wouldn't bug 19118 (Plug-In manager) solve this annyoing problem?
I saw a couple people in this bug using windows, and there's a workaround:

When you change quicktime's options in windows' control panel, it re-writes the
plugin files, and you have to copy the new ones from Quicktime's plugin
directory to Mozilla's plugin directory again.

The problem I have now is that after I disable png through quicktime, Mozilla no
longer knows how to handle PNG. Ick.

This is still a problem with QuickTime 5.05 on Mac OS X, and using latest
Mozilla Mac OS X build (2002012503). I have also disabled PNG rendering in the
QuickTime plug-in.

Is this a problem with the QuickTime plug-in? If so, Apple desperately needs to
fix this. Mozilla 1.0 can't come out with broken full-page PNG rendering.

Oddly, the QuickTime plug-in reported in about:plugins says version 5.02. I will
investigate and report if it is fixed when I upgrade to a later plug-in.
The QuickTime plug-in is in all versions I have at version number 5.0.2, whilst
the main package is 5.0.5. Has this been reported as a bug to Apple, or is it
not their problem?
*** Bug 122177 has been marked as a duplicate of this bug. ***
This happens on Windows XP too. Here's what I see:

* npqtplugin.dll is the Quicktime 5.02 plugin that handles PNGs. See:
C:\Program Files\QuickTime\Plugins
* You can view which mime types a plugin handels by going to the "Properties" of
the DLL in Windows Explorer, looking at the "Version" tab, then under the
"MIMEType" catagory
* When changing MIME handlers in the Quicktime Control Panel, the information in
the DLL catagory is updated. This is what tells the browser what MIME-types the
plugin will handle

If you disabled Quicktime's handeling of PNG's but it still renders them, the
problem might be that DLL you are using in Mozilla does not have the updated
MIME info. 

As a workaround, use the correctly modified DLLs with the right MIME info.

A better soltuion could be if Apple could modify the Quicktime Control Panel to
use our Windows registry keys to locate instances of the DLL:
http://www.mozilla.org/projects/plugins/install-scheme.html

Another possible solution on our side is to "sweep" for Quicktime in its
installed location. But that may have other side-effects.....
Hardware: Macintosh → All
Whiteboard: [fixed on Win32 with Quicktime 5.02, only for full-page plugins on Mac]
I'm on win98 with a cvs build pulled 1-27-02 and quicktime 5.0.2. I have png
handling unchecked in the quicktime preferences. I've also manually copied the
plugin files from the quicktime plugin directory to mozilla'a plugin directory
(I think that covers everything :)). When viewing a bugzilla attachment with
type image/png quicktime still gets callled to render it. When I try and open a
local png file it says "Starting Plugin for type image/png" in the status bar
and simply displays what I assume is a broken plugin icon. I'll attach a screen
shot of the last case.
Hardware: All → Macintosh
Whiteboard: [fixed on Win32 with Quicktime 5.02, only for full-page plugins on Mac]
You may still have a Quicktime plugin in your plugin search path that's enabled
for PNG.

Visit about:plugins,
find which plugin is doing PNG support,
and remove it.
heh, another mid-air. It turns out it was picking up the netscape 4.x plugin. I
had looked at about:plugins before, I just didn't pay attention to the full
path. Oops. 
I think this is evolving into two seperate bugs: mac os x, and windows. In my
oppinion this should be split.

I just tested a few more things:
Omniweb will not use qt for png no matter what, so it is out of consideration.

ie's behavior is is like this:
with plugin with enabled: uses qt
with plugin without enabled: downloads
without plugin without enabled: downloads
without plugin with enabled: throws up a "i can't handle this. what do you want
me to do" type dialog.

the difference between the first and the last is, imho, signifigant. the setting
and not the plugin controls ie's behavior. ie will try to use the plugin if the
setting tells it to, even if the plugin does not exist.

as to the settings changing the plugin its self, no files in the plugin have
been changed since it's instalation.
Whiteboard: [fixed on Win32 with Quicktime 5.02, only for full-page plugins on Mac]
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to adt@netscape.com.  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
Bug 131230 has been created to disable full-page plugin support for internal
image decoder mime types. There is patch in that bug and it will fix this bug as
well.
Depends on: 131230
Target Milestone: mozilla1.2 → mozilla1.0
this seems to be fixed with 2002040108 on Mac OS X 10.1.3.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
yes, verif.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: