Build ID: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101103 Firefox/4.0b8pre ========================================================================= Prerequisites: Make a simple test page using html 4.1 or html 5 tags, and insert some mistakes for the console to catch. Example: You can misplace one of the tags, or forget to close "</tag>". Or you can just load offline the iframe test page from the attachment. (open index.htm) Also, install Safari, or any other browser with embedded debugger. ========================================================================= Steps: 1. Open a blank tab 2. Load the Console 3. Load your test page with the console on 4. Repeat steps 1,2,3 with the Safari console ========================================================================= Behavior: You will notice that Safari console finds the html mistakes and echoes some errors on screen. It would be nice to add this to our console too

I'm not sure if gecko produces errors/warnings for these. Mihai has some patches that surface a lot more errors in the web console. I've cc'ed Mihai on this bug for comment... if gecko does produce this sort of error, then it will likely start appearing when Mihai's patches land. If it doesn't, I don't think we want to do this in Firefox 4 but we should keep this in mind for the next release.

I looked through all of the Gecko code that outputs warnings or errors to the nsIConsoleService, of all types. No indication of such warnings/errors ever being produced. Only the strict XML parser logs errors. The relaxed HTML parser doesn't seem to do that. We'd need to hack the Gecko code to log such errors. We should definitely fix this bug for the next Firefox release.

yeah, I think our parsers just ignore unknown tags as per the HTML spec. I agree that it would be useful to catch errors, but should probably be a preference to enable it. HTML strict mode? CC-ing Henri and Boris for a consult.

(In reply to comment #4) > I agree that it would be useful to catch errors, but should probably be a > preference to enable it. That's bug 512229. Additionally, I've been planning to highlight parse errors in View Source eventually. (My WIP patch for new View Source has some preparation for this. I expect to get back to working on it once my blocker and security bug queue empties for Firefox 4.)

We should leave this bug open because ultimately the Web Console will need some additional UI to allow filtering of "HTML Warnings". This would be a nice feature because it would eliminate the need for standalone HTML validator tools.

(In reply to comment #6) > This would be a nice feature because it would eliminate the need for standalone > HTML validator tools. An HTML5 validator reports more than just the parse errors, so if you wanted to obsolete standalone validators, you'd need to port/reimplement all the above-parser stuff in Validator.nu.

You're right, there is a lot more to a high quality validator.

good stuff, Henri. Thanks for the info.

So what is the thinking on this? Is this a DevTools/Console bug or a parser bug? or no bug at all?

(In reply to comment #10) > So what is the thinking on this? I'm currently implementing highlighting for mismatched tags for View Source. Once that's done, we can consider if we want to be able to run some or all of the error reporting code when the page load starts with the console open. > Is this a DevTools/Console bug or a parser > bug? or no bug at all? There's no way for DevTools to fix this without code changes in the parser, so in that sense, this is a missing feature in the parser.

(In reply to comment #11) > I'm currently implementing highlighting for mismatched tags for View Source. > Once that's done, we can consider if we want to be able to run some or all of > the error reporting code when the page load starts with the console open. > Ok, cool. running all error reporting regardless of the console being open would be ideal - as we will observe the errors. > > Is this a DevTools/Console bug or a parser > > bug? or no bug at all? > > There's no way for DevTools to fix this without code changes in the parser, so > in that sense, this is a missing feature in the parser. Ok, cool. that is what I thought. thanks. I will just close this as a dupe of your bug.