Created attachment 537096 [details]
test application

Created attachment 537098 [details]
actual result

This is the output of my program running in Fedora 16:

createRequest: "file:///home/raphael/build/test/qtwebkit/page.html" 
createRequest: "file:///home/raphael/build/test/qtwebkit/smile.png" 
createRequest: "icon:smile.png" 
readIcon: -1 "" 5 
readIcon: "smile.png" 476 
DebugReply: 476 image/png 
createRequest: "convert:smile.png" 
readIcon: -1 "" 5 
readIcon: "smile.png" 476 
DebugReply: 476 image/xpm 
createRequest: "direct:smile.png" 
readIcon: "smile.png" 770 
DebugReply: 770 
bytesAvailable: 476 
readData: 14 
bytesAvailable: 462 
bytesAvailable: 462 
readData: 448 
bytesAvailable: 476 
bytesAvailable: 476 
readData: 476 
bytesAvailable: 770 
readData: 512 
bytesAvailable: 258 
bytesAvailable: 258 
libpng error: Read Error
libpng error: IDAT: CRC error

Created attachment 537099 [details]
expected result

This is the output of my program running on ArchLinux with Qt4.7 and libpng1.2:

createRequest: "file:///home/raphael/builds/test/qtwebkit/page.html" 
createRequest: "file:///home/raphael/builds/test/qtwebkit/smile.png" 
createRequest: "icon:smile.png" 
readIcon: -1 "" 5 
readIcon: "smile.png" 476 
DebugReply: 476 image/png 
createRequest: "convert:smile.png" 
readIcon: -1 "" 5 
readIcon: "smile.png" 476 
DebugReply: 476 image/xpm 
createRequest: "direct:smile.png" 
readIcon: "smile.png" 770 
DebugReply: 770 
bytesAvailable: 476 
readData: 476 
bytesAvailable: 476 
readData: 476 
bytesAvailable: 770 
readData: 770

Comment on attachment 537099 [details]
expected result

Sorry, my fault. libpng 1.4 is in Arch.

Cant' build test app:
$ qmake-qt4 
WARNING: Failure to find: test.moc

(In reply to comment #5)
> WARNING: Failure to find: test.moc
Try "qmake-qt4 -project", it will create test.moc and moc_bytearrayreply.[cpp|h]. Then replace the file test.pro afterwards again, it gets overwritten by qmake-qt4 that isn't able to detect automatically the need for webkit and network modules.

OK,

I'd suggest contacting upstream mailing list for advice,
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt

Could very well simply be a libpng bug/error as well (the error message does originate from libpng afterall).

> Could very well simply be a libpng bug/error as well (the error message does
originate from libpng afterall).
No. That's very unlikely. Either it's due to a bug in Qt / QtWebkit or because of a failing in the combination of Qt 4.8 and libpng 1.2. As said already, libpng 1.4 doesn't show the issue, though only tested with Qt 4.7 and another distribution.

I'll contact upstream ASAP. Thanks.

Trying to reassign to libpng. I have another issue with that library, see bug #757559 .

Some users of Russian Fedora Remix (based on Fedora 16 official packages) did confirm this bug.

I see no reason to believe this is a libpng bug.  It's not unlikely that qt 4.8 hasn't been tested with libpng 1.2, since the latter is pretty darn ancient.  But we're not going to rebase libpng in F16 at this point, so the onus is on qt not libpng to cope.

(In reply to comment #11)
> I see no reason to believe this is a libpng bug.
Tim, thanks for the fast response.
I can see that there are efforts to ship the actual upstream libpng 1.5.6 in Fedora 17. 
My question to you is if Qt 4.8 fc17 will or sould be built against libpng-compat or libpng. The name libpng-compat-1.5.6 is misleading and confusing: in reality, it is 1.2.

(In reply to comment #7)
> I'd suggest contacting upstream mailing list for advice,
I tried to subscribe to the mailing list. There is a strange problem with confirmation. So for now, first trying to contact the webkit maintainer.

(In reply to comment #12)
> My question to you is if Qt 4.8 fc17 will or sould be built against
> libpng-compat or libpng.

There is no way to "build against libpng-compat", because it contains no devel support files (no headers, no .so symlink).  I see that qt hasn't been rebuilt since 3-Nov, but next time it's successfully built in rawhide, it will be using libpng 1.5.

> The name libpng-compat-1.5.6 is misleading and confusing: in reality, it is 1.2.

If it were intended to survive for any length of time, I might worry about that.  It will only exist until dependent packages are all rebuilt.

Triaged back to qtwebkit (WebKit component in bz is deprecated)

My workaround is now:

(...)
		if (req.url().scheme() == "icon") {
			QByteArray bytes;
			
			// FIXME: Qt4.8 seems to do strange things to png content
			// and webkit is not able to understand.
			// see https://bugzilla.redhat.com/show_bug.cgi?id=757492
			#if QT_VERSION >= 0x040800
			#define FORMAT "xpm"
			#else
			#define FORMAT "png"
			#endif
			
			loadIcon(bytes, req.url().path(), FORMAT);
			return new DebugReply(bytes, "image/"FORMAT);
		}
(...)

Though, direct data transfer ("direct:") isn't working.

fwiw, qt-everywhere-opensource-src-4.8.0/src/3rdparty/libpng is 1.5.4
for giggles, I'll redo this test using the bundled copy

So the more we look at this, the more it looks like not a PNG issue, but an issue with the ByteArrayReply class in your code which just happens to be triggered by Qt 4.8's PNG loading code.

The evidence leading me to that conclusion:
* Using the bundled libpng 1.5.4 didn't help. (Rex tried it.)
* Replacing the smile.png with a known good PNG didn't help, either.
* All the other QtWebKit-using apps display PNGs just fine.
The difference between what works and what doesn't work is that ByteArrayReply class.

I would suggest rewriting that class from scratch, reimplementing ALL the virtual methods of QIODevice and forwarding them all as is to the backing QBuffer. (Well, you can add the QIODevice::Unbuffered flag in open because buffering a buffer is not helpful, but otherwise I'd forward everything as is.)

Oh, and close() should probably call both QNetworkReply::close() and the QBuffer's close() method. Currently it does neither.

http://doc.qt.nokia.com/qq/32/qq32-webkit-protocols.html

(In reply to comment #17)
> * All the other QtWebKit-using apps display PNGs just fine.
no. I doubt that theory. What does "All" mean in this context? At least, not the apps that'll use QNetworkReply class.
I experienced that QtWebkit of Qt4.7 did not require a content type header "image/png" explicitly set for the reply data content. QtWebkit 2.2 seems to enforce this, otherwise afaik. the transferred data will be ignored, as it seems.
Further cause of that, the internal type sniffer of Qt seems to not behave like the one been in Qt 4.7.
Summary: The behaviour of QtWebkit 2.2 is definitely different to the "common" one as expected from Qt 4.7, in which all that hackery worked just fine. :)

> no. I doubt that theory. What does "All" mean in this context? At least, not
> the apps that'll use QNetworkReply class.

As far as I can see, only stuff using that ByteArrayReply subclass included in your code sample is affected, QNetworkReply itself looks fine.

> Further cause of that, the internal type sniffer of Qt seems to not behave like
> the one been in Qt 4.7.

It might be doing some operations on QNetworkReply which ByteArrayReply doesn't implement (properly).

(But then again, images are supposed to be declared with the correct MIME type, real web servers normally send them that way.)


If you think there's an issue in QNetworkReply or in the type detection themselves, we will need some evidence that it can be reproduced with a test case NOT involving that ByteArrayReply class.

FYI, Rekonq and the kwebkitpart for Konqueror use the QNetworkAccess API including QNetworkReply to use KIO to provide the data, yet by all reports I have, they're working just fine. Show me a testcase broken the same way in Rekonq or Konqueror+kwebkitpart and I'll believe that there's a QNetworkReply bug.

(In reply to comment #21)
... see my comment #19, please.

Well, could it be an issue with glibc? There are other issues of non-qt applications, e.g. tumbler, that seem to have problems with png reading, too.

> ... see my comment #19, please.

I don't see how that link is relevant to the issue at hand. It summarizes the QNetworkAccess API, but the question at hand is whether the ByteArrayReply class in your code is compliant to the API or not.

> Well, could it be an issue with glibc? There are other issues of non-qt
> applications, e.g. tumbler, that seem to have problems with png reading, too.

shared-mime-info maybe? But it might actually be a completely different issue, too.

Feeling like that ...

http://main.makeuseoflimited.netdna-cdn.com/tech-fun/wp-content/uploads/2011/11/softwarewrong.jpg

(In reply to comment #16)
> fwiw, qt-everywhere-opensource-src-4.8.0/src/3rdparty/libpng is 1.5.4
> for giggles, I'll redo this test using the bundled copy

Are you away of this? Or is it patched in Fedora?
gui/image/qpnghandler.cpp:#include <../../3rdparty/libpng/png.h>
gui/image/qpnghandler.cpp:#include <../../3rdparty/libpng/pngconf.h>


(In reply to comment #17)
> * Using the bundled libpng 1.5.4 didn't help. (Rex tried it.)

Well, then it's a bug with Qt 4.8, for sure. As said already, it works with Qt 4.7 cause the implementation of ByteArrayReply is exactly the same 1:1 from the official patches to psi-plus (package is included in Russian Fedora). See the copyright in the file. I guess there are also differences with the webkit source part between both Qt versions.

(In reply to comment #24)
> the question at hand is whether the ByteArrayReply class in your code is
> compliant to the API or not.

Anyways, it does not make much sense to discuss a broken feature that is documented (see link of comment #19) and has worked in a previous version. It is clearly an upstream issue!

> gui/image/qpnghandler.cpp:#include <../../3rdparty/libpng/png.h>
> gui/image/qpnghandler.cpp:#include <../../3rdparty/libpng/pngconf.h>

These are under #ifdef:
#ifdef QT_USE_BUNDLED_LIBPNG
#include <../../3rdparty/libpng/png.h>
#include <../../3rdparty/libpng/pngconf.h>
#else
#include <png.h>
#include <pngconf.h>
#endif
which looks right to me.

> cause the implementation of ByteArrayReply is exactly the same 1:1 from the
> official patches to psi-plus (package is included in Russian Fedora).

That doesn't mean it's correct. Please either look for errors in it or ask the original author to do so. It might just work by accident in 4.7 (e.g. 4.7 might just happen not to be using the APIs from the interface which aren't implemented correctly).

> Anyways, it does not make much sense to discuss a broken feature that is
> documented (see link of comment #19)

Again, the fact that the API is documented doesn't actually mean that the ByteArrayReply class complies with the documented interface! This API is special in that it requires some interfaces YOU have to implement. If you don't implement them, or if you implement them incorrectly, things will not work.

I have seen that link. It is just a general overview page about the API, you have to look into the documentation of the actual classes to check whether ByteArrayReply's implementation of the required interfaces is compliant.

The fact that ALL the other QtWebKit users work, including the kwebkitpart users which definitely make use of the QNetworkAccess API (it's used to wrap KIO for QtWebKit to use), clearly points me into ByteArrayReply's direction as to the faulty component, and you still don't provide any convincing argument why it's not, you apparently haven't even LOOKED into it, nor talked to the upstream author about it.

> It is clearly an upstream issue!

Which upstream? Qt upstream or ByteArrayReply upstream? My guess is the latter.

Are you sure to have used the right gcc and linker options?

There's still an open bug, although Qt4.8 is stable now.
https://bugreports.qt.nokia.com//browse/QTBUG-8338

Just for documentation: We should better use the standardized data:// scheme for images.

http://www.websiteoptimization.com/speed/tweak/inline-images/

https://github.com/psi-plus/main/commit/2b7d1ca45031a06d4390f2c3104a3cecb55467a9