From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010628 BuildID: 2001062815 Entities are not highlighted in attribute values (ie they are blue, like oter characters in the attribute values). This hides a very common bug : <a href="form.html?var1=11&var2=22">go</a> which should be <a href="form.html?var1=11&amp;var2=22">go</a> Reproducible: Always Steps to Reproduce: 1. View a source with entities

CCing boris.

OK... Currently when doing highlighting we just get a single attribute token that in this case would be '"form.html?var1=11&var2=22"' (or the same thing with &amp; instead of &). So to fix this would require a lot more granularity on the part of the parser in the creation of tokens.... I don't really know how to do that. I don't even know whether it would be desirable, in light of the fact that the parser is not used solely for view source... Also, don't we handle the broken "form.html?var1=11&var2=22" in quirks mode? Does the view source parser ever use strict mode? The comment parsing I've seen it do has certanly been quirks parsing... Harish?

Boris: Ever since strict DTD got yanked parser always functioned in quirks mode. However, the layout has the ability to switch modes.

Harish, is that really the case? Then why do we do different comment parsing on strict vs quirks pages? And why does the behavior of things like &var in attributes differ based on the strict vs quirks thing? Is all that layout's doing?

Boris: Ok, I lied..a bit :-/. My previous statement does not apply for a couple of things, comment parsing nsresult CCommentToken::Consume(....) { nsresult result=PR_TRUE; if (aFlag & NS_IPARSER_FLAG_STRICT_MODE) { //Enabling strict comment parsing for Bug 53011 and 2749 contradicts!!!! result=ConsumeStrictComment(aChar,aScanner,mTextValue); } else { result=ConsumeComment(aChar,aScanner,mTextValue); } return result; } & a part of CDATA parsing nsresult CTextToken::ConsumeUntil(...) { ...... if (theTermStrPos != endPos) { if(!(aFlag & NS_IPARSER_FLAG_STRICT_MODE) && !(aFlag & NS_IPARSER_FLAG_TRANSITIONAL_MODE) && !theLastIteration && !aIgnoreComments) { nsReadingIterator<PRUnichar> endComment(theCurrOffset); endComment.advance(5); if ((theStartCommentPos == endPos) && FindInReadable(NS_LITERAL_STRING("<!--"), theCurrOffset, endComment)) { theStartCommentPos = theCurrOffset; } ..... } , since the layout does not have all the information necessary to handle these cases.

Ah. OK. And attribute parsing happens over in layout land anyway, so we don't worry about it in the parser... I'll try to figure out a way to handle this gracefully, but this'll be a pretty low priority for me, so adding helpwanted keyword.

his bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

*** This bug has been marked as a duplicate of 57724 ***

Reopening 57724 dependencies for independent resolution.

I think the proper place to fix this would be in nsViewSourceHTML.cpp, not in the parser proper. It should be pretty trivial, really.

An alternative fix would be to rewrite the parser to be able to generate tokens inside of attributes and (P)CDATA sections.

Fixed since at least the switch to the current view source back end.