Jonathan Kew [:jfkthame] Reporter
	Description • 8 years ago

When a downloadable font resource is rejected by the OpenType sanitizer, we report error messages to help identify the problem. These used to show up in the web console (along with CSS errors, etc), but in Nightly using the new console front-end, they no longer appear there.

The errors can be seen in the browser console window, but that's probably not very helpful, as web developers are more likely to be checking the web console for problems. (See also bug 1331797 comment 13.)

For an example, visit https://fonts.google.com. Note that several of the fonts fail to load. Check the browser console, and see that the relevant OTS errors are reported there; but check the web console, and they're missing.

	Nicolas Chevobbe [:nchevobbe]
	Comment 1 • 8 years ago

I do see them in the console when the CSS filter is on (see font-error.png attached), even if the styling isn't the same that it used to be (but we have a bug for better styling https://bugzilla.mozilla.org/show_bug.cgi?id=1319136).
Am I missing something here Jonathan ?

	Jonathan Kew [:jfkthame] Reporter
	Comment 2 • 8 years ago

Oh, you're right, it is possible to make them appear. But only by explicitly turning on the "Filter output" option, and then enabling the CSS option.

That seems highly counter-intuitive: if the filtering option isn't used, then everything should be displayed.

So my complaint, then, is that in the "unfiltered" web console -- which appears to be the default that authors will be presented with -- important messages are missing; and it's far from obvious in the UI that in fact filtering IS in effect.

(I'm not alone in finding this hard-to-discover: bug 1331797 comment 13.)

	Nicolas Chevobbe [:nchevobbe]
	Comment 3 • 8 years ago

> Oh, you're right, it is possible to make them appear. But only by explicitly turning on the "Filter output" option, and then enabling the CSS option.

The button isn't really "filter output", but rather, "configure the output filtering", which means that even if it isn't shown, the output is filtered with what the user chose (or the default configuration).

> That seems highly counter-intuitive: if the filtering option isn't used, then everything should be displayed.

I think this can be either way. if we show everything, people might say we're cluttering the output (there can be a lot of CSS errors for examples)

> So my complaint, then, is that in the "unfiltered" web console -- which appears to be the default that authors will be presented with -- important messages are missing; and it's far from obvious in the UI that in fact filtering IS in effect.

I hear you, we might want to do a better job at reflecting the filtering state of the console. Maybe we could have a message saying some messages are filtered-out and add the possibility to show them. I'll get in touch with UI/UX people to see how we can tackle that.

Thanks !

	Jonathan Kew [:jfkthame] Reporter
	Comment 4 • 8 years ago

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #3)
> > Oh, you're right, it is possible to make them appear. But only by explicitly turning on the "Filter output" option, and then enabling the CSS option.
> 
> The button isn't really "filter output", but rather, "configure the output
> filtering", which means that even if it isn't shown, the output is filtered
> with what the user chose (or the default configuration).

Oh, I see... the text "Filter output" next to the (mysterious) button icon isn't actually labelling it (like it does in the buttons above), it's just placeholder text for the filter field. Yes, it's slightly grayer. I claim that's a confusing UI!

> 
> > That seems highly counter-intuitive: if the filtering option isn't used, then everything should be displayed.
> 
> I think this can be either way. if we show everything, people might say
> we're cluttering the output (there can be a lot of CSS errors for examples)

That's certainly true; and I think I could be persuaded that hiding them by default is reasonable, but if so, it should be immediately clear in the UI that they're being hidden, and could be revealed.

That used to be the case in the old console UI, IIRC: the "filter" buttons were permanently visible. I assume the hidden filter bar is an attempt to save space (and simplify the default UI?), but I think it has serious usability/discoverability issues.

> 
> > So my complaint, then, is that in the "unfiltered" web console -- which appears to be the default that authors will be presented with -- important messages are missing; and it's far from obvious in the UI that in fact filtering IS in effect.
> 
> I hear you, we might want to do a better job at reflecting the filtering
> state of the console. Maybe we could have a message saying some messages are
> filtered-out and add the possibility to show them. I'll get in touch with
> UI/UX people to see how we can tackle that.

Thanks for looking into it!

	Nicolas Chevobbe [:nchevobbe]
	Comment 5 • 8 years ago

Blake, do you think we could have some UI help here ? Thanks

	Blake Winton (:bwinton) (:☕️)
	Comment 6 • 8 years ago

I'll add it to the list of DevTools UX Requests!  Thanks!  :D