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)
Tracking
()
VERIFIED
FIXED
mozilla0.9.3
People
(Reporter: jrspm, Assigned: jtaylor)
References
()
Details
(Keywords: testcase)
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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
Comment 1•23 years ago
|
||
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
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?
Reporter | ||
Comment 5•23 years ago
|
||
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
Comment 6•23 years ago
|
||
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
Assignee | ||
Comment 7•23 years ago
|
||
Patch attached. Striping whitespace for text/* urls.
Status: NEW → ASSIGNED
Keywords: patch
Assignee | ||
Comment 8•23 years ago
|
||
Comment 9•23 years ago
|
||
valeski, could you review this change? Is it safe to rip out ws?
Comment 10•23 years ago
|
||
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.
Assignee | ||
Comment 11•23 years ago
|
||
Assignee | ||
Comment 12•23 years ago
|
||
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?
Comment 13•23 years ago
|
||
we should also make sure uri's in these bugs don't break w/ this patch. assuming
they're ok. r=valeski
http://bugzilla.mozilla.org/show_bug.cgi?id=77850
http://bugzilla.mozilla.org/show_bug.cgi?id=47288
http://bugzilla.mozilla.org/show_bug.cgi?id=78876
http://bugzilla.mozilla.org/show_bug.cgi?id=76312
http://bugzilla.mozilla.org/show_bug.cgi?id=79896
http://bugzilla.mozilla.org/show_bug.cgi?id=53792
Comment 14•23 years ago
|
||
john says all the uri's still work. jud gave a thumbs up. sr=dougt.
Assignee | ||
Comment 15•23 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 16•22 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•