29917 - A HREF Target with "/" or "*" symbol causes crash

Status: VERIFIED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Jerome Kwok]

1. Target with "/" character will crash Mozilla.  Make a page with the following 
code.  Click on it and Mozilla M14 will crash.  M13 does not have this problem.

<a href="http://www.mozillazine.org/" target="mozilla/zine">MozillaZine</a>


2. Location box of the parent window updated incorrectly.  Make a page with the 
following code.  Click on it and Mozilla will open a new window browsing 
Mozilla.org.  Back to the parent Mozilla window, and the location box will show 
the URL "http://www.mozilla.org" instead of the URL of the page viewing.  Click 
"View Source" the Mozilla will view the source of mozilla.org instead of the 
page viewing.  M13 does not have this problem.

<a href="http://www.mozilla.org" target="_blank">Mozilla</a>


3. Visit http://compuwise.home.dhs.org using resolution 800x600 or higher.  
Click on any link on the page (all links in the page will open a new window).  
Then back to the parent window, you'll find the alignments are shift right.  I 
don't know what particular code causes this problem.  But M13 does not have this 
problem.

Comment 1

[Gagan]

target is dom/layout? don would know...

Comment 2

[Jerome Kwok]

Problem 3 will also occur when right-clicking any links.
http://www.firingsquad.com/news also has the similar problem.  Right click any
link in the page, the ad banner will float.

Comment 3

[Doron Rosenberg (IBM)]

reporter - are oyu stills eeing this with m15 builds?

thanks

Comment 4

[Jerome Kwok]

Problem 3 has been resolved.

Problem 1 & 2 still exists using the 2000040215 build win32.  For problem 2, the
parent window's location box will be, still, incorrectly updated when clicking
links which open new windows.  But the view source is OK.

Comment 5

[Sean Richardson]

Problem 2 appears to be bug 31211, "Session History "inherited" from spawned 
window", M16.

[e-mail], please report only one issue per bug report...
please consider using the bugzilla helper at 
http://www.mozilla.org/quality/help/bug-form.html to file bugs.
It helps ensure that the bug report you submit will be immediately useful.

Also, it helps to provide a sample page including the code you are referring
to, either by pointing to such a page in the URL field, or by creating
an attachment that contains a short testcase. That's the next step here,
to be able to test and confirm the presence of problem 1.

Comment 6

[Jerome Kwok]

Attachment: target with "/" symbol

Comment 7

[Jerome Kwok]

Thanks for your guideline. 

I made a sample page demostrating problem 1.  I filed these bugs together 
because it seems that they are caused by one checkin.  These 3 bugs exist since 
one day's nightly build.

Yes, problem 2 seems to be the same or similar as 31211.  Then let's focus on 
problem 1 in this record.

Comment 8

[Jerome Kwok]

Problem 1 still exists in build 2000041409, tested with the attachment page.

Comment 9

[Sean Richardson]

I was a bit surprised to come to this conclusion, but examining the HTML 4.01
spec, it appears that a value like "mozilla/zine" for the target attribute
is valid.

The spec for the <A> element,
http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2 points to 
http://www.w3.org/TR/REC-html40/present/frames.html#target-info which points to
http://www.w3.org/TR/REC-html40/types.html#type-frame-target which points to
http://www.w3.org/TR/REC-html40/sgml/loosedtd.html#FrameTarget

It appears that %FrameTarget is CDATA.
http://www.w3.org/TR/REC-html40/types.html#h-6.2 says
 > For some HTML 4 attributes with CDATA attribute values, the specification 
 > imposes further constraints on the set of legal values for the attribute 
 > that may not be expressed by the DTD.
The restictions appear to be
1. must start with an alphabetic character:
   http://www.w3.org/TR/REC-html40/types.html#type-frame-target
2. the value is case-insensitive:
   http://www.w3.org/TR/REC-html40/present/frames.html#h-16.3

I'm surprised that %FrameTarget was not defined to be ID or NAME, but it looks 
like that wasn't possible if "_blank", etc, were to be allowed.

Comment 10

[Sean Richardson]

Confirming with the 2000-04-16-16-M16 nightly binary on WinNT.

Sorry, missed doing this with the last comment, but moving to the "HTML Element"
component

Comment 11

[rickg]

Here's the stack trace:

NTDLL! 77f7629c()
js_ErrorToException(JSContext * 0x031d9b50, const char * 0x0320bdf0, 
JSErrorReport * 0x00000000) line 554 + 35 bytes
ReportError(JSContext * 0x031d9b50, const char * 0x0320bdf0, JSErrorReport * 
0x00000000) line 264 + 17 bytes
js_ReportErrorVA(JSContext * 0x031d9b50, unsigned int 0, const char * 
0x015ed2a8, char * 0x0012f5cc) line 313 + 17 bytes
JS_ReportError(JSContext * 0x031d9b50, const char * 0x015ed2a8) line 2977 + 19 
bytes
GlobalWindowImpl::CheckWindowName(GlobalWindowImpl * const 0x031d6860, JSContext 
* 0x031d9b50, nsString & {???}) line 2817 + 38 bytes
GlobalWindowImpl::OpenInternal(GlobalWindowImpl * const 0x031d6860, JSContext * 
0x031d9b50, long * 0x0115ade0, unsigned int 2, int 0, nsIDOMWindow * * 
0x0012fa08) line 2401 + 23 bytes
GlobalWindowImpl::Open(GlobalWindowImpl * const 0x031d6864, JSContext * 
0x031d9b50, long * 0x0115ade0, unsigned int 2, nsIDOMWindow * * 0x0012fa08) line 
1527
nsBrowserContentHandler::HandleContent(nsBrowserContentHandler * const 
0x0320c1d0, const char * 0x0320c410, const char * 0x0270f42c, const char * 
0x0320e210, nsISupports * 0x02937260, nsIChannel * 0x0320f210) line 2085 + 84 
bytes
nsURILoader::DispatchContent(nsURILoader * const 0x028bdf60, const char * 
0x0320c410, int 1, const char * 0x0320e210, nsIChannel * 0x0320f210, nsISupports 
* 0x00000000, nsIURIContentListener * 0x00000000, nsISupports * 0x02937260, char 
* * 0x0012fc78, nsIURIContentListener * * 0x0012fc80, int * 0x0012fc70) line 810 
+ 53 bytes
nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x0320f210, nsISupports * 
0x00000000) line 312 + 165 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x0320e0e0, 
nsIChannel * 0x0320f210, nsISupports * 0x00000000) line 255 + 16 bytes
InterceptStreamListener::OnStartRequest(InterceptStreamListener * const 
0x0320c480, nsIChannel * 0x0320f210, nsISupports * 0x00000000) line 1118
nsHTTPServerListener::FinishedResponseHeaders() line 974 + 48 bytes
nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x0320cf90, 
nsIChannel * 0x0320d6f4, nsISupports * 0x0320f210, nsIInputStream * 0x0320f80c, 
unsigned int 0, unsigned int 1231) line 384 + 8 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x0320ddf0) 
line 406 + 47 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0320e040) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x0320e040) line 575 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x02933340) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00010894, unsigned int 49403, unsigned int 0, 
long 43201344) line 1030 + 9 bytes
USER32! 77e71820()

Back to travis, since it appears to be his code (via cvs-blame).

Comment 12

[travis]

Most likely due to changes mccabe made in the JS Error Script reporting.  
Flipping over to him.

Comment 13

[Chris Petersen]

Since TARGET is a commonly used attribute, I suggest that this problem should be 
fixed in beta 2.

Comment 14

[Blake Ross]

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

Comment 15

[John Morrison]

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

Comment 16

[John Morrison]

Testcases from other, duplicate reports: 

target="nav,main"
   http://bugzilla.mozilla.org/showattachment.cgi?attach_id=7474

target=*_blank*
   http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8398

I note that duplicate bug #35063 was [nsbeta2+]; I assume that this should 
get the same designation (although I disagree with that rating -- unless 
someone has data to show otherwise, I think this is a rare crash. However, 
I expect the fix is not too difficult anyways).

Comment 17

[Andreas Franke (gone)]

This crash is currently shadowed by bug 38644 ``<A TARGET="foo" ...> crashes in
nsURILoader::SetupLoadCookie''. That bug has been introduced between 5/5 and
5/7, it's stack trace is completely different, and it is triggered by a much
larger set of target values. Marking dependency.

Comment 18

[leger]

Putting on [nsbeta2+][6/01] radar.  This work must be done by 06/01 or we may 
pull this for PR2.  We could release note for beta2 if we had too.

Comment 19

[Andreas Franke (gone)]

The dependency to bug 38644 is obsolete now since the testcase there does not
crash any more, thanks to pollmann for his fix to bug 32898 on 5/10.
Also bug 38476 (which contains the same stack trace as this bug) is has been
fixed, probably due to the other part of pollmann's fix on that day.

On PC/Linux, build 2000052109, neither the attachment to this bug nor the 
attachments from John's comment seem to be crashers any more.
Can this bug be closed out, or is anyone still seeing this?

Comment 20

[Mike McCabe]

Worksforme...

WARNING: Illegal character in window name a/b, file nsGlobalWindow.cpp, line
3022

petersen, can you confirm?  If so, let's close this.

Comment 21

[Chris Petersen]

This problem isn't occuring in the May 22 builds (2000052208) for Mac, Win 98, 
and Linux.

Comment 22

[Mike McCabe]

Great!  Resolving as WORKSFORME.

I've checked the code and confirmed that this does *not* attempt to write to the
console service.  Instead, it uses NS_WARNING() from nsDebug.h... which calls
nsDebug::Warning...

It might make sense for nsDebug.cpp to use the console service to report some
warnings that make sense to expose to the user.  Different bug, though.  Added
comment to 6211.

Comment 23

[Chris Petersen]

This problem is no longer occuring in the May 30th builds. Marking verified works 
for me.

Comment 24

[Heikki Toivonen (remove -bugzilla when emailing directly)]

SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.