Closed Bug 57246 Opened 24 years ago Closed 24 years ago

& in urlbar history not escaped

Categories

(Core Graveyard :: RDF, defect, P1)

Product:
Core Graveyard
Component:
RDF
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
mozilla0.9

People

(Reporter: BenB, Assigned: waterson)

References

Details

(Keywords: regression, verifyme)

Attachments

(1 file)

ampersand- and angle-bracket-escape members that are literals
897 bytes, patch
Details | Diff | Splinter Review 
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.
Keywords: regression
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
Severity: critical → blocker
OS: Linux → All
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.
Status: NEW → ASSIGNED
Keywords: crash
Priority: P3 → P1
Whiteboard: FIX IN HAND
Target Milestone: --- → mozilla0.9
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
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 57401 has been marked as a duplicate of this bug. ***
Nominating for rtm
Keywords: rtm
Re-opening this and marking it rtm+ so we can get the fix on the branch.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: FIX IN HAND → [rtm+]FIX IN HAND
Whiteboard: [rtm+]FIX IN HAND → [rtm+]FIX IN HAND, Fix on trunk
rtm++
Whiteboard: [rtm+]FIX IN HAND, Fix on trunk → [rtm++]FIX IN HAND, Fix on trunk
fixed on branch
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
verified on branch:
WinNT4 10/27
Linux rh6 10/27
Mac os9 10/27

needs verified on trunk
Keywords: vtrunk
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
Status: RESOLVED → VERIFIED
Keywords: vtrunk
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Lowering severity to critical, removing crash keyword.
Severity: blocker → critical
Keywords: crash, rtm → mozilla0.8
Hardware: PC → All
Whiteboard: [rtm++]FIX IN HAND, Fix on trunk
Re-tested with original instructions on win32 2001-01-16 build; WFM. Is there a 
reliable way to reproduce?
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
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.
Keywords: qawanted
Keywords: mozilla0.8
are you going to reopen this?

-qawanted, +verifyme -> need to hit this w/ the mozilla .9x verification train.
Keywords: qawanted → verifyme
I can't reproduce this.  If you find a way to consistantly reproduce this,
please re-open.  verified wfm.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: