Closed Bug 81185 Opened 23 years ago Closed 23 years ago

decoding base64 encoded text/html, using data: protocol, with spaces crashes Mozilla

Categories

(Core :: Networking, defect, P3)

x86
Windows 2000
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.3

People

(Reporter: jrspm, Assigned: jtaylor)

References

()

Details

(Keywords: testcase)

Attachments

(2 files)

tested on build #2001051520 This is a bug that I commented on in bug 78876 where I was told to report a new bug on this behavior... If the URL above is used in Mozilla, Mozilla crashes immediately. This seems to be caused by the space after "PCFE" at the beginning of the base64 data. If That space is taken out, everything works fine. This does not seem to happen on base64 encoded images or base64 encoded mp3's. Steps to reproduce: 1. Enter the above URI (URL Field) into Mozilla's Address area 2. hit Enter 3. Watch Mozilla crash Try the same thing again, but remove the space. Should work fine. Expected Results: Mozilla displays base64 encoded text/html with or without spaces without crashing Actual Results: Mozilla crahses Jake
confirming: ###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0', file ../../dist/include/nsCOMPtr.h, line 649 ###!!! Break: at file ../../dist/include/nsCOMPtr.h, line 649 (gdb) bt #0 0x165c2ded in nsDocShell::DoURILoad (this=0x838e478, aURI=0x189ac678, aReferrerURI=0x83beac8, aOwner=0x1893af00, aLoadCmd=7, aPostData=0x0, aHeadersData=0x0) at ../../dist/include/nsCOMPtr.h:649 #1 0x165c1829 in nsDocShell::InternalLoad (this=0x838e478, aURI=0x189ac678, aReferrer=0x83beac8, aOwner=0x0, aInheritOwner=1, aStopActiveDoc=0, aWindowTarget=0x3fffeea8, aPostData=0x0, aHeadersData=0x0, aLoadType=2097153, aSHEntry=0x0) at ../../dist/include/nsCOMPtr.h:863 #2 0x165d0224 in nsWebShell::HandleLinkClickEvent (this=0x838e478, aContent=0x18f19f20, aVerb=eLinkVerb_Replace, aURLSpec=0x18f883d8, aTargetSpec=0x156ae5cc, aPostDataStream=0x0, aHeadersDataStream=0x0) at ../../dist/include/nsCOMPtr.h:642 #3 0x165cf7df in HandlePLEvent (aEvent=0x18f89a20) at nsWebShell.cpp:679 #4 0x1563e443 in PL_HandleEvent (self=0x18f89a20) at plevent.c:588 #5 0x1563e2a3 in PL_ProcessPendingEvents (self=0x80a3610) at plevent.c:518 is the top of the stack.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → mozilla0.9.2
mass move, v2. qa to me.
QA Contact: tever → benc
This no longer crashes, but I get a different assertion ###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(LoadURI(uri, 0, aLoadFlags))) fail ed: '(!((LoadURI(uri, 0, aLoadFlags)) & 0x80000000))', file l:\tip\mozilla\docsh ell\base\nsDocShell.cpp, line 2151
Uh, I don't think a space is legal in base64... right? so what is the correct behavior? 1- Glue data together and silently continue? 2- Give friendly error?
Well, Netscape 4.77 displays it just fine with the space. Also, within a src attribute, it is often difficult to fit a large amount of base64 text without newlines. If spaces aren't meaningful in base64, then I'd say there is no reason to interperet the spaces a part of the base64 text. Just remove them and display the result. Again, this seems to be what Netscape 4.77 does. Also, it would be very confusing to most users trying to view the base64 text to have nothing show up just because of a single space they didn't realize was there. Jake
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Priority: -- → P3
john, can you take a look at this? Plz make sure that we don't crash if someone puts a data: in their webpage. :-)
Assignee: neeti → jtaylor
Patch attached. Striping whitespace for text/* urls.
Status: NEW → ASSIGNED
Keywords: patch
valeski, could you review this change? Is it safe to rip out ws?
stripping ws helps some data urls, and breaks others. practical usage is split. fix this bug, open up some of the other closed/resolved bugs.
Attached patch New patch (deleted) — Splinter Review
OK. This new patch fixes this bug, but doesn't break other data: urls (ex. bug # 37200) that valeski alluded to. valeski, can you review?
john says all the uri's still work. jud gave a thumbs up. sr=dougt.
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
VERIFIED: Mozilla 1.2.1, Win98 & Mac OS X I've written a test suite to cover all of data URLs, including the examples you gave.
Status: RESOLVED → VERIFIED
Whiteboard: checklinux
Keywords: testcase
VERIFIED: Mozilla 1.3a, Linux
Whiteboard: checklinux
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: