& in urlbar history not escaped

VERIFIED WORKSFORME

Status

()

Core
RDF
P1
critical
VERIFIED WORKSFORME
18 years ago
17 years ago

People

(Reporter: BenB, Assigned: Chris Waterson)

Tracking

({regression, verifyme})

Trunk
mozilla0.9
regression, verifyme
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
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

Comment 2

18 years ago
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
(Reporter)

Comment 3

18 years ago
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.

Comment 4

18 years ago
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

Comment 7

18 years ago
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
(Assignee)

Comment 10

18 years ago
BenB's right: the changes for 53922 exercised a new code path in
nsRDFXMLContentSink, and exposed a latent bug.
(Assignee)

Comment 11

18 years ago
Created attachment 17534 [details] [diff] [review]
ampersand- and angle-bracket-escape members that are literals
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Keywords: crash
Priority: P3 → P1
Whiteboard: FIX IN HAND
Target Milestone: --- → mozilla0.9
(Assignee)

Comment 12

18 years ago
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().
(Assignee)

Comment 13

18 years ago
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

Comment 15

18 years ago
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
(Assignee)

Comment 16

18 years ago
fix checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 17

18 years ago
*** Bug 57401 has been marked as a duplicate of this bug. ***
Nominating for rtm
Keywords: rtm

Comment 19

18 years ago
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

Comment 20

18 years ago
rtm++
Whiteboard: [rtm+]FIX IN HAND, Fix on trunk → [rtm++]FIX IN HAND, Fix on trunk
(Assignee)

Comment 21

18 years ago
fixed on branch
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 22

18 years ago
verified on branch:
WinNT4 10/27
Linux rh6 10/27
Mac os9 10/27

needs verified on trunk
Keywords: vtrunk

Comment 23

17 years ago
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
(Reporter)

Comment 24

17 years ago
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 → ---
(Reporter)

Comment 25

17 years ago
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
(Assignee)

Comment 26

17 years ago
Re-tested with original instructions on win32 2001-01-16 build; WFM. Is there a 
reliable way to reproduce?
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 27

17 years ago
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

Updated

17 years ago
Keywords: mozilla0.8

Comment 28

17 years ago
are you going to reopen this?

Comment 29

17 years ago
-qawanted, +verifyme -> need to hit this w/ the mozilla .9x verification train.
Keywords: qawanted → verifyme

Comment 30

17 years ago
I can't reproduce this.  If you find a way to consistantly reproduce this,
please re-open.  verified wfm.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.