Reproduce: 1. Enter an URL with an "&", e.g. <http://online.babylon.com/cgi-bin/trans.cgi?layout=site.txt&lang=ger&word=hello>, into the urlbar 2. Restart Mozilla Actual result: Mozilla doesn't start, console output: XML Error in file 'file:///home/ben/.mozilla/ben575/localstore.rdf', Line Number: 266, Col Number: 76, Description: not well-formed Source Line: <RDF:li>http://online.babylon.com/cgi-bin/trans.cgi?layout=site.txt&lang=ger&word=hello</RDF:li> Expected result: &<> in RDF are escaped.

I think, this is a regression caused by bug 53922. I am using a my own opt Linux build from Oct 19 01:16:19 CEST 2000.

This one is really really really bad.... I'm using build 2000101820 on Win2k and if I start Mozilla with -console my Mozilla crashes!!! If I start if without the -console it runs fine! And it's all caused by an & in item in the nc:urlbar-history

I don't think, it's a blocker. You can manually edit localstore.rdf and delete the offending entry. I am surprised that it runs, if you have no console.

I'll have Radha take a look at this too ...

Chris, Can you look at this bug. Do you know what could be causing it?

oops! failed to notice that it is already assigned to waterson

That's why I added you to the cc list. :-)

In my debug builds, I see a crash in my trunk builds(which has the fix for 53922) as well as in the branch builds which doesn't have the fix. So, I'm not sure if 53922 regressed this, Here is the stack trace for the crash I got, RDFServiceImpl::GetDataSource(RDFServiceImpl * const 0x00aea9b0, const char * 0x0330b3a0, nsIRDFDataSource * * 0x0012ee10) line 1135 + 15 bytes XPTC_InvokeByIndex(nsISupports * 0x00aea9b0, unsigned int 14, unsigned int 2, nsXPTCVariant * 0x0012ee00) line 139 nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x0180ce70, nsXPCWrappedNative * 0x0334e9c0, const XPCNativeMemberDescriptor * 0x0334efb0, nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 1, long * 0x00dd925c, long * 0x0012efb4) line 913 + 43 bytes WrappedNative_CallMethod(JSContext * 0x0180ce70, JSObject * 0x00e131a8, unsigned int 1, long * 0x00dd925c, long * 0x0012efb4) line 228 + 34 bytes js_Invoke(JSContext * 0x0180ce70, unsigned int 1, unsigned int 0) line 790 + 23 bytes js_Interpret(JSContext * 0x0180ce70, long * 0x0012fac4) line 2589 + 15 bytes js_Execute(JSContext * 0x0180ce70, JSObject * 0x00d385b0, JSScript * 0x03356d80, JSFunction * 0x00000000, JSStackFrame * 0x00000000, unsigned int 0, long * 0x0012fac4) line 962 + 13 bytes JS_ExecuteScript(JSContext * 0x0180ce70, JSObject * 0x00d385b0, JSScript * 0x03356d80, long * 0x0012fac4) line 3042 + 27 bytes nsJSContext::ExecuteScript(nsJSContext * const 0x0180b150, void * 0x00dd7020, void * 0x00d385b0, basic_nsAWritableString<unsigned short> * 0x00000000, int * 0x00000000) line 724 + 42 bytes nsXULDocument::ExecuteScript(JSObject * 0x00dd7020) line 5487 + 33 bytes nsXULDocument::OnStreamComplete(nsXULDocument * const 0x027b33dc, nsIStreamLoader * 0x0334f0b0, nsISupports * 0x00000000, unsigned int 0, unsigned int 7652, const char * 0x00dbcc98) line 5435 + 18 bytes nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x0334f0b4, nsIChannel * 0x02f4a9f0, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x100a66c8 gCommonEmptyBuffer) line 121 + 78 bytes nsResChannel::EndRequest(unsigned int 0, const unsigned short * 0x100a66c8 gCommonEmptyBuffer) line 719 + 50 bytes nsResChannel::OnStopRequest(nsResChannel * const 0x02f4a9f4, nsIChannel * 0x03350f70, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x100a66c8 gCommonEmptyBuffer) line 713 nsFileChannel::OnStopRequest(nsFileChannel * const 0x03350f78, nsIChannel * 0x03350e00, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x100a66c8 gCommonEmptyBuffer) line 647 + 45 bytes nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x03350190) line 302 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03350140) line 97 + 12 bytes PL_HandleEvent(PLEvent * 0x03350140) line 576 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00ac54b0) line 509 + 9 bytes

My trunk builds would recover and run, once I remove the offending url from localstore.rdf. I do see the problem in the branch which doesn't have my changes. Can someone confirm the same in branch builds? Thanks

BenB's right: the changes for 53922 exercised a new code path in nsRDFXMLContentSink, and exposed a latent bug.

rjc, could you code review the change? I was failing to ampersand and angle-bracket escape RDF literals before writing them out: just copy-n-paste'd the escaping code from nsRDFXMLDataSource::SerializeAssertion().

radha: If you've not landed the changes for 53922, then there shouldn't be any problems with &'s in URLs. I'm not seeing the crash you report...

r=rjc

patch is simple, matches the environment, symmetrical with other changes, and I see no way to improve it locally with new string tech ... such improvement would require changes higher up, like in the |rdf_...| reading and writing routines (which desparately need to reduce string copying). sr=scc

fix checked in

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

Nominating for rtm

Re-opening this and marking it rtm+ so we can get the fix on the branch.

rtm++

fixed on branch

verified on branch: WinNT4 10/27 Linux rh6 10/27 Mac os9 10/27 needs verified on trunk

Verified Fixed on Mozilla trunk builds. linux 110606 RedHat 6.2 win32 110104 NT 4 mac 110104 Mac OS9 Setting bug to Verified and removing vtrunk keyword

I've seen this recently again. REOPENing. Symptoms apart from error msgs on the console were that no window settings were stored: Toolbars hide/unhide, mailnews thread pane columns etc.. Also, the urlbar history was empty.

Lowering severity to critical, removing crash keyword.

Re-tested with original instructions on win32 2001-01-16 build; WFM. Is there a reliable way to reproduce?

I don't have any. But the babylon url showed up in my localstore.rdf, with "&" unescaped. Dunno, how it got there. I didn't run any binary older than 2000-12-15 on that profile when the problem occured. IMO, this bug is too bad to mark it WFM.

are you going to reopen this?

-qawanted, +verifyme -> need to hit this w/ the mozilla .9x verification train.

I can't reproduce this. If you find a way to consistantly reproduce this, please re-open. verified wfm.