Doing this could be really spammy, which is why I didn't do this in the first place. Need to consider perf, too.
(In reply to Henri Sivonen (:hsivonen) from comment #1) > Doing this could be really spammy, which is why I didn't do this in the > first place. Currently, in the webconsole, it's possible to choose to show CSS errors or not, likewise for JS. Even if you want finer granularity, it's possible to show only warning or only errors, etc. My point is that as long as there is the option to ignore this type of message, spam isn't an issue. > Need to consider perf, too. How so? Do you do parsing with error analysis lazily when view-sourcing? I think nothing gets printed in the devtools if they're not displayed so, the same policy could be applied to avoid affecting the majority of FF users.
It would be a nice option to display HTML parsing errors in the web console, but I think that should only happen on user's demand - not during typical web browsing. Such errors are far too common and they would generate too much output (if displayed) and this may also cause performance issues.
(In reply to Mihai Sucan [:msucan] from comment #3) > It would be a nice option to display HTML parsing errors in the web console, > but I think that should only happen on user's demand - not during typical > web browsing. Yeah, exactly like CSS and JS errors now. > Such errors are far too common and they would generate too > much output (if displayed) and this may also cause performance issues. Exactly like CSS errors. Just the very bugzilla bug I'm on has ~20 CSS warnings. So the HTML reporting would need to have the same characteristics than the current CSS error reporting (only do it when devtools are open).
What I am suggesting is slightly different. CSS and JS errors/warnings are currently logged even if you do not have any dev tool open. I am not sure what impact the addition of HTML parsing errors would have to Gecko in terms of browsing performance - this is something Gecko experts know how to answer better than myself. Maybe we could turn this reporting on only when the user demands it, inside our devtools - not when the user simply opens the browser console / web console or some other tool. We could have an option in devtools to enable HTML parsing errors logging, which would be off by default - in the Options panel. I am not yet sure if we really want an additional category/option inside the web console UI (we are already getting a "crowded" toolbar). Also, we have a ton of output which we want to keep in check.
(In reply to David Bruant from comment #2) > How so? Do you do parsing with error analysis lazily when view-sourcing? There are two copies of the main HTML tokenizer loop in the Gecko binary: one with the error reporting code and one without. View Source runs the former. Other parsing runs the latter.
Agreed that this could be really spammy. Might make sense to include a validator tool for HTML but I'm reluctant to turn this on by default in the Web Console.
Priority: -- → P4
You need to log in before you can comment on or make changes to this bug.