It's hard to see what filters are active in the new webconsole frontend UI

NEW
Unassigned

Status

()

Firefox
Developer Tools: Console
P4
normal
9 months ago
25 days ago

People

(Reporter: jfkthame, Unassigned)

Tracking

(Blocks: 1 bug)

unspecified
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 months 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.
Created attachment 8848400 [details]
font-error.png

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 ?
Flags: needinfo?(jfkthame)
(Reporter)

Comment 2

9 months 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.)
Flags: needinfo?(jfkthame)
> 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 !
(Reporter)

Comment 4

9 months 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!
Summary: web console fails to show errors related to downloadable fonts → It's hard to see what filters are active in the new webconsole frontend UI

Updated

8 months ago
Flags: qe-verify?
Priority: -- → P2
Whiteboard: [new-console]

Updated

8 months ago
Whiteboard: [new-console] → [console-html]
Blake, do you think we could have some UI help here ? Thanks
Flags: needinfo?(bwinton)
I'll add it to the list of DevTools UX Requests!  Thanks!  :D
Flags: needinfo?(bwinton)

Updated

8 months ago
Flags: qe-verify? → qe-verify+
QA Contact: iulia.cristescu

Updated

7 months ago
Priority: P2 → P3
Whiteboard: [console-html] → [reserve-console-html]

Updated

4 months ago
Priority: P3 → P4

Updated

25 days ago
Whiteboard: [reserve-console-html]
You need to log in before you can comment on or make changes to this bug.