Filtering in web console is confusing + bonus


(Mironf) #1

Hi evryone, especially Moz Devs.
I switched to FF57 and i have to say that some changes are cool but some are really bad.
Filtering in web console is confusing. In pre FF57 DevTools filtering was clear and obvius. There was Network: CSS, JS, Security, Log, Server filters.
Now there are: Erorrs, Warnings, Logs, Informations, Debuging Logs.

What the heck are Infromations about (maybe about flight to the moon)? Which erreors are shown when Erorrs filter are on (maybe about Chernobyl Recator)? etc. And why you hide those filters? Why you removed color indicators in those filters? It is even well not visible which filters are on and which are off. Why? Why? Why? Why? Why!?! Because Google Chrome made this way? If yes, this is pathetic argument.

Another issue. Sometimes I have problems with editing width and height, paddings, and
borders in box model. I assume that this is dependent from something, but there is no single word in MDN when it can be edited and when it’s not possible. In Firebug[RIP] it wass possible all the time, why to restrict this features at all?

Why there are two diagrams of box model? Which one is for editing which is only information? It is confusing.

(And those colors in dark theme, Jesus Holy Mary and other saints, why is there so much contrast! between dark an lighter areas!?)


(Nicolas Chevobbe) #2

Hello,

First, please be aware that what you label as bad is really cool for other people, and that the team is making choices to improve the tools for the majority of our user.

Filtering in web console is confusing. In pre FF57 DevTools filtering was clear and obvius.

It was simply not. The UI was complex and confused people.

There was Network: CSS, JS, Security, Log, Server filters.
Now there are: Erorrs, Warnings, Logs, Informations, Debuging Logs.

Now there are Errors Warnings Logs Info Debug | CSS XHR Requests.
You can see that “actual” logs (consoleAPI calls) are ordered by “level” (console.error , .warn, .log, .info, .debug) and other, less-used type of messages are differentiated.
There are 2 things missing, “Security” and “Server”. Server logs are no longer supported natively since there are no parts of the ConsoleAPI specification and there is a webextension to make them available.
“Security” is being discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=1410369.

What the heck are Infromations about (maybe about flight to the moon)? Which erreors are shown when Erorrs filter are on (maybe about Chernobyl Recator)?

  1. Mind your language, 2. This show all the Errors (JS Exception, Evaluation Results exception, bad use of console input helpers, …). I guess you were used to the old console frontend where you could apply fine-grained level to every sorts of messages, but overall, this is confusing. If you want to see errors, you probably want to see all the different “types”.
    We can always discuss if you think this does not work well and provide good examples showing why this is a blocker for you, and find solution (and consensus) for everyone.

And why you hide those filters? Why you removed color indicators in those filters?

Because as you noticed, Firefox and the devtools were being redesigned to look nicer and cleaner. The text label and the placement on the filter are quite explicit which made us think these color could go away. Again, if you give us some examples showing why this is an issue for you, we can discuss it and find solution.

It is even well not visible which filters are on and which are off.

I am confused, the filters do have an active and an inactive state, so you can clearly see which are enabled or not. We follow the same pattern than in all the other tools. If you say that you don’t see them because the filter bar is hidden, well, 1. you can open it, and as long as you don’t close it, it will always be opened when you open the console, 2. If there are “default” logs (error, warn, log, info, debug) hidden, we display an “X items hidden by filters” which can alert you you might miss something.

Why? Why? Why? Why? Why!?! Because Google Chrome made this way? If yes, this is pathetic argument.

console
It does not look the same at all to me.

Please note that it is actively being worked on as we try to find the right balance between cleanness and usability (See https://twitter.com/violasong/status/926189788486557697). You might want to follow https://twitter.com/FirefoxDevTools where we ask people for feedback or come and chat in our Slack

(And those colors in dark theme, Jesus Holy Mary and other saints, why is there so much contrast! between dark an lighter areas!?)

Can you tell us what you are calling dark areas ? Those color were carefully chosen to be accessible so everyone, including people with visual impairments can differentiate them. If you have specific suggestion, tell them and we can discuss it.

Overall, remember that we are people, trying to provide the best tool for our users. You can always come and give us feedback and we’ll be happy to discuss and make changes if we find they are legit.


(Frank Forte) #3

You said that a webextension is available for the server log. I could not find the extension, could you tell me which one or where to find it?

ChromePhp appears to have stopped working. In fact, it was such an inconvenience that I ended up rolling this:

I still would like to know if there is a better solution that does not require additional JavaScript tags added to my projects.


(Mironf) #4

Hello
Good news. You convinced me with most of Yours arguments. I was used to my old workflow. I have seen that color theming is going in good way, filters also. But can You explain me why there is two box model charts (in calculated and layout tabs)? I find this very confusing. And stil can’t find why some times width and height in box model chart are editable and sometimes not. There is no single word in documentaion what are the cases when it work or when it don’t.


(Patrick Brosset) #5

But can You explain me why there is two box model charts (in calculated and layout tabs)? I find this very confusing. And stil can’t find why some times width and height in box model chart are editable and sometimes not.

I agree that this can be confusing and we have talked about removing one of them. The story of where this diagram appeared is long and full of surprises :slight_smile:

We used to have a Layout tab long ago, it only contained this diagram, and that’s the only place where it appeared at the time.
At some stage, we got rid of this tab, and moved the diagram inside the computed tab.
And recently, we re-introduced an all-new Layout tab, that contains more information, in particular about CSS Grids if you have any (and more things in the future). When we did this, it made sense to also have the box-model there, because it’s really about CSS layout. And we took this opportunity to display more useful information there too, like box-sizing, float, line-height, etc… Anything that has an impact on the layout of the element.

When we did this, we didn’t remove the one in the computed tab, to avoid breaking people’s workflows, and because the 2 diagrams served different purposes somehow. One is a quick view over the computed margin, padding, border, and the other one is a more detailed view with more data.

I think we should still continue the discussion about removing one of them.

As to why width and height are sometimes not editable, I’m not sure. I’ve looked at the code and couldn’t find a condition that would allow or disallow edition of those values. So I think that might be a bug but I’ll double check.


(Mironf) #7

Thanks for Yours detailed answer :slight_smile:
On bugzilla in some thread, i once read that “width and height should be editable when it’s possible”, so mayby sometimes is not possible, but when? That is big question.


(Julian Descottes) #8

@MironF Rather than not editable, do you mean that you can edit the value but then when you try to submit, it goes back to the original value?

If that’s what you meant, it is similar to what I mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1398721


(Mironf) #9

No. Literally i can’t edit width and height by clicking on boxmodel charts, in computed and layout tabs.
e.g on https://www.smashingmagazine.com/articles/ i can’t edit width and height any of nodes (div, p, section article ect.) I checked this on Devtools FF56 on Win, FF57 on Linux, on FF49 with Firebug[RIP] and in Chromium. On FF 56 and 57 DevTools i can’t edit. On chromium and Firebug[RIP] no problem, i can eddit any elemnt with no restrictions.
There is no problem with editing padding, margin and border only width and height.

In Firebug and Chromium Dev Tools i can edit and changes are visible immediately (live).

Another issue with performance. In chromium after cliking on values in box model chart, values became editable right away. In FF56 and 57 devtools (when changes are possible) there is a small lag. After click, edit mode became active nearly after 0,5 second.


(Julian Descottes) #10

Ah indeed, thanks for the link.

Looks like we have a check only for width and height : https://searchfox.org/mozilla-central/rev/be78e6ea9b10b1f5b2b3b013f01d86e1062abb2b/devtools/client/inspector/boxmodel/components/BoxModelMain.js#411

Editing is only enabled for box-sizing content-box elements, otherwise we display them as read only.


(Mironf) #11

This is bug, or it will stay this way?


(Julian Descottes) #12

I think it should at least be displayed differently if it’s not editable (with a tooltip explaining why it’s this way).

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1422255 to discuss.