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!
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?
Maybe the MIME settings?
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.
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)
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?
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.
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.....
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.
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.
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 email@example.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.
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.
this seems to be fixed with 2002040108 on Mac OS X 10.1.3.