878364 - Report HTML parsing errors in the console

Status: NEW

(DevTools :: Console, enhancement, P4)

Description

[David Bruant]

Firefox view source has an error highlighting and reporting features that is ridiculously excellent since Firefox 11 [1]
The tooltips aren't very discoverable unfortunately. It would be excellent if those errors appeared in the web console like the CSS and JS ones currently (and that an HTML button was added at this occasion alongside "CSS" and "JavaScript").

[1] http://hsivonen.iki.fi/view-source/

Comment 1

[Henri Sivonen (:hsivonen)]

Doing this could be really spammy, which is why I didn't do this in the first place. Need to consider perf, too.

Comment 2

[David Bruant]

(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.

Comment 3

[Mihai Sucan [:msucan]]

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.

Comment 4

[David Bruant]

(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).

Comment 5

[Mihai Sucan [:msucan]]

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.

Comment 6

[David Bruant]

(In reply to Mihai Sucan [:msucan] from comment #5)
> 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.
Oooh... true. For whatever reason, I thought they weren't logging when devtools are closed. My mistake.


> 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).
If you take a look at this toolbar, it lists "CSS" and "JavaScript" and it really feels weird that HTML isn't part of the party given that the 3 technologies work together on the web.
I really believe HTML has a place in this toolbar. That said, I agree the toolbar could benefit from a redesign of some sort.

Comment 7

[Henri Sivonen (:hsivonen)]

(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.

Comment 8

[Rob Campbell [:rc] (:robcee)]

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.

Comment 9

[Sebastian Zartner [:sebo]]

FWIW here's a request for this on stackoverflow:

http://stackoverflow.com/q/26425716/432681

I agree that the normal user doesn't need to see those error messages, so only turning logging on when requested should just work fine if logging in the background really slows down the browsing experience. This statement also covers CSS and JavaScript error logging. Though that should be part of a separate bug.

Regarding this bug:
The option for logging HTML errors to the Web Console might be turned off by default, though CSS and JavaScript error logging is also turned on by default, which produces a lot of messages on several pages. And personally I don't see an impact on page load performance.
Though that is something, which simply needs to be tested out.

Sebastian