Closed Bug 63137 Opened 21 years ago Closed 18 years ago

[FIX]View Source converts tags to lower case


(Core :: DOM: HTML Parser, defect, P3)






(Reporter: stevehalasz, Assigned: bzbarsky)




(Keywords: regression, testcase)


(2 files)

1. Go to
2. View->Page Source

What happens: The page source is displayed with the opening and closing text of 
the HTML tags converted to lower-case, like:
<a HREF="">...</a>

What should happen: The tags should remain upper-case, like:
<A HREF="">...</A>
I do not see this with a linux 2000-12-05-08 nightly.  I do see it with a linux
2000-12-15 CVS build. adding regression keyword, OS -> All. Could be a parser
Ever confirmed: true
Keywords: regression
OS: Windows NT → All
Component: XP Apps: GUI Features → Layout
QA Contact: sairuh
Blocks: 57724
Severity: trivial → major
worksforme -
whups, somehow the qa contact never got filled. chris, d'you see this? if not,
pls mark wfm. thx!
QA Contact: petersen
hrm, actually this is still a problem. will attach simple testcase.
Keywords: testcase
Hardware: PC → All
try parser.
Assignee: ben → harishd
Component: Layout → Parser
QA Contact: petersen → janc
This 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 --. 
Target Milestone: --- → Future
updated qa contact.
QA Contact: janc → bsharma
*** Bug 78621 has been marked as a duplicate of this bug. ***
It appears that Mozilla (linux, build id 2001062823 & earlier) presents the 
source as it appears after it has been parsed, often incorporating "corrections"
made by the parser.  Another example is if you leave the closing quote of an
attribute value (e.g. &lt;p align=&quot;left&gt; ) Mozilla will fill it in when
you view the source.

I think this is bad because I normally view the source so I can debug the
source!  In the worst case you can create an unrenderable page, look at the
source, see there's nothing there (because the parser has thrown it all out),
and make the not unreasonable assumption that CGI script is not returning
anything (this has happened to me, sorry no examples)., we have to parse the source to usefully highlight
it...  And there are bugs on all sorts of problems that arise as a result, this
being one of them.  If we decide to drop syntax highlighting, all these bugs
would disappear, of course.
No longer blocks: 57724

*** This bug has been marked as a duplicate of 57724 ***
Closed: 21 years ago
Resolution: --- → DUPLICATE
vrfy dupe
*** Bug 110095 has been marked as a duplicate of this bug. ***
*** Bug 115172 has been marked as a duplicate of this bug. ***
Reopening 57724 dependencies for independent resolution.
Depends on: 57724
Resolution: DUPLICATE → ---
This bug still happens with Mozilla 0.9.9 for me on Red Hat Linux.

Ideally, the bug could be fixed, but it seems like a low priority.
Failing an outright fix, the parsing/highlighting should be removed and the
original source displayed as a plain text file.

It is more important to have the correct source than incorrect colorful source.
seeing this on: 2002042608 winXP
*** Bug 169450 has been marked as a duplicate of this bug. ***
*** Bug 169906 has been marked as a duplicate of this bug. ***
*** Bug 208264 has been marked as a duplicate of this bug. ***
*** Bug 210372 has been marked as a duplicate of this bug. ***
Flags: blocking1.6b+
only drivers can set blocking+ flags.  if you want to request it, set it to ?

also, reassigning to default because doesn't exist anymore which
means both the assignee and qacontact on this bug are invalid.
Assignee: harishd → parser
Flags: blocking1.6b+
sorry. i viewed the help and there was no mention. figured if i could change it,
then i had permissions to do so. my mistake won't happen again.
i've changed it to requested. hope I'm not spamming.
Flags: blocking1.6b?
The simple problem here is that for known tags the token stores the tag id, not
the actual string...
Comment on attachment 135098 [details] [diff] [review]
This fixes the bug, as far as I can tell

Choess, heikki, what do you think?
Attachment #135098 - Flags: superreview?(hjtoi-bugzilla)
Attachment #135098 - Flags: review?(choess)
Comment on attachment 135098 [details] [diff] [review]
This fixes the bug, as far as I can tell

Wow, why didn't we do this before? Looks good to me, although I can't build
right now. Be aware that the GetIdentifier routine will consume the characters
:, -, _, and alphanumerics; upon hitting any other character, it returns what
it's consumed so far. But case-folding alone should be resolved by this.
Attachment #135098 - Flags: review?(choess) → review+
Assignee: parser → bz-vacation
Priority: -- → P3
Summary: View Source converts tags to lower case → [FIX]View Source converts tags to lower case
Target Milestone: Future → mozilla1.6beta
Attachment #135098 - Flags: superreview?(hjtoi-bugzilla) → superreview+
Closed: 21 years ago18 years ago
Resolution: --- → FIXED
Flags: blocking1.6b?
*** Bug 226492 has been marked as a duplicate of this bug. ***
vrfy fixed 2004011809 (url, testcase, data:text/html,<A><bB></Qq></a>)
You need to log in before you can comment on or make changes to this bug.