nsDataChannel::ParseData() uses PL_strlen() to compute the length of base64-encoded data, which means that whenever the data contain a null byte, they will be truncated. Test case: the following URI (same as URL field above in bug report) data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAIAAAACUFjqAAAABGdBTUEAALGPC/xhBQAAAAlwSFlzAAALEgAACxIB0t1+/AAAAAd0SU1FB9EFBAoYMhVvMQIAAAAtSURBVHicY/z//z8DHoBH+v///yy4FDEyMjIwMDDhM3lgpaEuh7gTEzDiDxYA9HEPDF90e5YAAAAASUVORK5CYII= should point to a 10*10 PNG image representing a small square. Instead, it does some quite weird things (my build says Image 13660284x1075756316 pixels and prints the URI itself in the body, but I expect this to be architecture dependent). This was introduced by an incorrect resolution of bug 53792. See also final comments on bug 47288. A patch which fixes this is forthcoming.

good catch. let me review your fix now.

David: I applied the patch and see the image of the small square being displayed. However, when I reload, I see the following assertions before it loads the page again. Seth : could you review this? ###!!! ASSERTION: nsDataChannel::Cancel: 'Not Reached', file L:\build\mozilla\ne twerk\protocol\data\src\nsDataChannel.cpp, line 255 ###!!! ASSERTION: nsDataChannel::Cancel: 'Not Reached', file L:\build\mozilla\ne twerk\protocol\data\src\nsDataChannel.cpp, line 255 ###!!! ASSERTION: Cancel failed: 'NS_SUCCEEDED(cancelRv)', file l:\build\mozilla \netwerk\base\src\nsAsyncStreamListener.cpp, line 109 ###!!! ASSERTION: nsDataChannel::Cancel: 'Not Reached', file L:\build\mozilla\ne twerk\protocol\data\src\nsDataChannel.cpp, line 255 ###!!! ASSERTION: Cancel failed: 'NS_SUCCEEDED(cancelRv)', file l:\build\mozilla \netwerk\base\src\nsAsyncStreamListener.cpp, line 109

What is going on with this bug? Seth, did you have the chance to review?

I haven't reviewed / tested yet. on my short list of things to do today.

testing this fix now...

I tested the patch. it's good. the assertions are not related to this bug. probably a bug with data urls and the mem cache, if you made me guess without looking. r=sspitzer

new bug logged on the assertions. #79896 this is ready for sr and checkin. it's necko, so you might want valeski or gagan for the sr.

Judson: Could you sr= this bug. Thanks, Neeti

cc'ing valeski for sr=?

please test the following bugs, we've changed the way we compute the length several times now: http://bugzilla.mozilla.org/show_bug.cgi?id=53792 http://bugzilla.mozilla.org/show_bug.cgi?id=35439 I believe your patch will re-introduce http://bugzilla.mozilla.org/show_bug.cgi?id=21314 I think we're chasing our tails w/ broken usages of data: urls unfortunately :-/.

I tested the above three bugs with and without the above patch. 1. For bug http://bugzilla.mozilla.org/show_bug.cgi?id=53792, we display the same data with and without the patch. 2. For bug http://bugzilla.mozilla.org/show_bug.cgi?id=35439, for the testcase http://bugzilla.mozilla.org/showattachment.cgi?attach_id=7466 We do not show #2 in the build without the patch, but in a build with the patch we show #2. For the test link http://pmt.sourceforge.net/gamma_test/ we broken with and without the patch. 3. For bug http://bugzilla.mozilla.org/show_bug.cgi?id=21314 I do not see random characters appearing at the bottom of messages in a build with the patch. Was there a specfic test case email message which showed the bug? Seth: Could you try testing bug http://bugzilla.mozilla.org/show_bug.cgi?id=21314 with the above patch. It would help if you could also verify we are causing any regressions. Thanks, Neeti

I'm overloaded right now. neeti, can you drive this?

Judson: I have tested bug http://bugzilla.mozilla.org/show_bug.cgi?id=21314 with the patch applied on linux and windows, and I do not see any random characters appearing at the bottom of messages.

as I pointed out earlier. I suspect we're just bouncing a bug back and forth. your code looks fine to me, r=valeski, but we just need to be ready for another bug to bounce back up, and determine which we want to supress.

I agree.

checked in fix

I can now see base64 encoded images using the data: protocol (cool!), but now I crash on base64 encoded text/html. For instance, the following crashes mozilla, but shows up just fine in Netscape 4.77... data:text/html;base64,PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMD AgVHJhbnNpdGlvbmFs Ly9FTiIKImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1sPjxoZWFk Pjx0aXRsZT5DcmVhemlvbmUgVXRlbnRpPC90aXRsZT48L2hlYWQ+Cjxib2R5IGJnY29sb3I9Indo aXRlIj48Zm9udCBmYWNlPSJzYW5zLXNlcmlmIiBzaXplPTM+CgombmJzcDsgCgo8aDE+UHJvdmEg ZGkgaWZyYW1lPC9oMT4KVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJv dmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkg cHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8g ZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVz dG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEg VGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJv dmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkg cHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8g ZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVz dG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEg VGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJv dmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkg cHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8g ZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVz dG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEK VGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJv dmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkg cHJvdmEKCjwvZm9udD48L2JvZHk+PC9odG1sPgoK also, base64 encoded mp3's play immediately with the system default mp3 player in Netscape 4.77, but pop up a download dialog in Mozilla...seems to confuse Mozilla. I'll post the base64 mp3 if anyone wants to test that out. jake

data:text/html;base64,PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDAgVHJhbnNpdGlvbmFsLy9FTiIKImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1sPjxoZWFkPjx0aXRsZT5DcmVhemlvbmUgVXRlbnRpPC90aXRsZT48L2hlYWQ+Cjxib2R5IGJnY29sb3I9IndoaXRlIj48Zm9udCBmYWNlPSJzYW5zLXNlcmlmIiBzaXplPTM+CgombmJzcDsgCgo8aDE+UHJvdmEgZGkgaWZyYW1lPC9oMT4KVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKCjwvZm9udD48L2JvZHk+PC9odG1sPgoK works for me on today's build. doesn't crash on linux. about the mp3 problem, I think that's by design. but log a bug on it if you think otherwise. (cc mscott on it.)

Seth, you are partially right about the text/html. I took out any line breaks and/or spaces and it rendered fine without crashing. however, Netscape 4.77 deals with the line breaks/spaces transparently. For instance, if I copy your example into the Address box and view it, it makes no difference whether there are spaces or not for Netscape 4.77 and it most certainly does not crash. To test this, try puting even one single space into into the base64 text that you provided, have Mozilla load that, and watch it crash immediately. That seems just a bit sensitive to me. I could be evil and put base64 data with line breaks/spaces in a web page to crash peoples browsers intentionally. hehehehehehehe. It isn't overly functional if it is that sensitive. I dont' think this bug is fixed until it is robust enough not to crash on something that simple. jake

jake, log a new bug on this problem.

reported bug 81185 per Seth's comment jake

reported bug 81190 about strange behavior in handling base64 encoded mp3's Jake

*** Bug 76312 has been marked as a duplicate of this bug. ***

+verifyme, so it gets attention from me later...

Verified Duplicate