Closed Bug 705921 Opened 13 years ago Closed 11 years ago

Option to clear web console messages on page reload

Categories

(DevTools :: Console, defect, P2)

Product:
DevTools
Component:
Console
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Firefox 24

People

(Reporter: harth, Assigned: msucan)

References

(Depends on 1 open bug)

Details

Attachments

(1 file, 2 obsolete files)

test fixes
19.46 KB, patch
jwalker
: review+
Details | Diff | Splinter Review 
A webdev mentioned this in IRC:

12:58 potch: I love that it doesn't by default, but I would like to be able to ask the console to clear on reload as well
I believe that the console could always be cleared on reload.  While it can be nice to keep console messages through navigation, etc., an actual reload means "let's try this again" at which point old messages are not useful.

The persistent console is one of my top annoyances with the Web Console, but this simple change would fix that.
(In reply to Ian Bicking (:ianb) from comment #1)
> I believe that the console could always be cleared on reload.  While it can
> be nice to keep console messages through navigation, etc., an actual reload
> means "let's try this again" at which point old messages are not useful.
> 
> The persistent console is one of my top annoyances with the Web Console, but
> this simple change would fix that.

... for you. :)

I'm pretty sure there are a group of people for whom persistence is important. People interested in comparing network request and response headers for example. Or comparing the results of console messages between changes. Or any other messages.

Having an option will cater to both groups.
I suppose Bug 655700 would also address the problem.

An option isn't really helpful, as there isn't a class of people that regularly needs to persist messages, and a class of people that doesn't.  There are some *tasks* that might require one or the other.  Even if the option is easy to change but sticky it's going to be kind of tweaky – it'll often be set the wrong way, and you'll have to adjust it and restart your debugging actions.  

It seems that it should be possible to address the specific use cases more directly.  E.g., if there's a way to get to old log messages, then you can still do comparisons.  And those comparisons will probably be easier than currently – I have actually wanted to do what you've described, but a log of any substantial size is very hard to read and understand, and very easy to be looking at exactly what you didn't intend, like the old logs when you want the new ones or vice versa.
Being able to literally do a diff of the current log, and the log during the last page load, would actually be awesome.
Another webdev (peterbe) suggested that to me today.

I agree that it would be nice to clear on reload (not on load, only on reload).

Comparing network request might be something people want to do, but I don't think this is a good reason to not implement a feature useful for a much larger group (people doing Network diffs vs people using the web console).

I also don't think it's a bad idea to introduce an option.

We already have options (position and Response Bodies). We could gather all these options into one "gear" menu (like in the Inspector).
I don't think we need an option. If so, only in about:config. (Based on the fact that more options leads to more UI noise)

The only time I need persistent logging is when I'm clicking around on different links and checking which assets are already cached or not. 

All other times, it's reloading, which means I want to start afresh.
What if on page load we collapsed old information into one line that could be expanded (put back into the web console) with a click?  Would that be too much work when folks care about old information?
If that's unreasonable for some reason, we either need a concrete, low-impact proposal or we should just add an easy-to-toggle option.

There are people that like the current behavior (see comment #0 at the beginning of the bug, where the webdev in question "love[s] that it doesn't by default"), it's unreasonable to say "make it how I like it and then don't allow alternatives".

Options aren't ideal, but we have to weigh the effort of finding and implementing an ideal solution here vs. the hundreds of other things that need solutions.
I like the idea of grouping previous page log messages - I don't know how that would interact with a console that was trimming logs that were from a while ago - there could be some places where that could act bizarrely.

I wonder if we could draw a thick line across the output for each page load, and scroll the output so the line was (just) off the top. The effect would be that for many people it would be clearer enough where the new stuff started, and it would also be obvious how to get at the old stuff. Even better the line could be drawn retro-actively.

The core problem is clutter preventing the developer from seeing the output messages quickly, so the idea that we've vaguely mulled of displaying log messages separately from the console output could also help.
Not if it is done in a little hackish way.

Add a class to all the items that are from the page before the reload, make position:absolute, top:0, background:white so only one of them will be visible. Provide a twisty arrow to expand them, thus removing that class from all those messages. This won't effect the usual behavior of web console, i.e. removing older logs after a limit, as the logs would be unaffected, just style changed.

As I said, a bit hackish :)
I like the idea of grouping the log for previous page loads, but I do not like the hackish proposal you have, Girish :) (sorry!). Web Console's output situation is already pretty bad.

Currently we can easily do:

1. clear output on reload.
2. or gray out "old" messages.
3. or add some kind of splitter between "old" and "new" messages.

After bug 778766 we can consider bigger output changes, like grouping.
So to be concrete on the UX problems with grouping:
1. A user opening a group would reasonably expect to see everything in that group, not only would that not be true
2. Items would also be disappearing but not from the top, since the top would be the page/group header
3. Sometimes entire page groups would disappear, I think that could look strange to the user too, currently it's just 'scrolling off the top'

I think the message however isn't that we should design this now, but that we should think about our options when we do come to do it.
(Not saying we should do that, but in reply to comment 10, it's better to use the "~" operator. Example: http://jsbin.com/uyevic/1/edit)

I think a splitter that would include a "clear before" button could work.
One common problem I have is that a page will produce a lot of output (especially if I am displaying network requests) and to see the bit I'm interested in I have to scroll back.  But if I forgot to clear the console first, I may scroll back to the relevant log messages from a previous page load.  I end up very confused, because everything looks basically right, except whatever I changed or added isn't reflected because I'm looking at obsolete output.  I may or may not see a separator when I scroll back.  Graying out text or something like that would help more, as I could scroll to any position and immediately see if I'm looking at output from the current page or a previous page.  (This isn't to say a separator is not also useful.)

In terms of the reluctance to add configuration: instead of configuration there could be a control, like a checkbox next to the "clear" button – that would be easy to find, and may not even need a label (just hover text).
(In reply to Ian Bicking (:ianb) from comment #14)
> One common problem I have is that a page will produce a lot of output
> (especially if I am displaying network requests) and to see the bit I'm
> interested in I have to scroll back.  But if I forgot to clear the console
> first, I may scroll back to the relevant log messages from a previous page
> load.  I end up very confused, because everything looks basically right,
> except whatever I changed or added isn't reflected because I'm looking at
> obsolete output.  I may or may not see a separator when I scroll back. 
> Graying out text or something like that would help more, as I could scroll
> to any position and immediately see if I'm looking at output from the
> current page or a previous page.  (This isn't to say a separator is not also
> useful.)

Yeah, as much as I hate to cling to overused, oversimplified design tropes: making the top of the scrollbar == the beginning of pageload is nice from a fitts point of view.


> In terms of the reluctance to add configuration: instead of configuration
> there could be a control, like a checkbox next to the "clear" button – that
> would be easy to find, and may not even need a label (just hover text).

Yeah, I imagined something as available as that, not a config-dialog preference.
I like Paul's suggestion in Comment #13 as well. I've been thinking that a light grey line with a "Reload" message would be a nice visual separator could help.

We could provide some keyboard controls to scroll to previous reload as well. Cmd/ctrl-shift-pg-up/down?
There are two problems to solve here: visual separation and quick navigation.

When doing tight edit/compile/run loops on Firefox, I've gotten into the habit of hitting enter about 10 times at my prompt before rerunning firefox.  Because the prompt itself is not enough separation between two runs of debug spew.  Getting to the start of my current run is STILL a fight between the tracking speed of my mouse and the size the scrollbar has grown to, and scrolling slowly enough to make sure I actually see the 10 blank lines that signal separation.  In the worst cases I've managed to scroll to the wrong run and waste minutes poring over the wrong logs.

A grey line will help a bit with separation, but I don't think it solves the important "get me to the beginning of this run" problem.  Other consoles are currently solving this problem (by clearing between runs) and I don't think we should ignore it.

So if there's still resistance to letting people clear on rerun (which I think is a fine solution), maybe we can add a quick "get me to the beginning of this run" button near the scrollbar.
what do you think about the cmd-shift-pgup/down shortcut. Too undiscoverable? We could even mention that next to the reload marker.
Yeah, that'd be pretty undiscoverable :/
A keyboard shortcut also requires that focus be in the console – when just inspecting logs it's not necessary to put focus into the console, and so often focus just stays in the page, where hitting Cmd-Shift-PgUp/Down probably won't do what you want.
Let's track clear-on-reload with an easily-accessible toggle (which I think we've all agreed on) in this bug, and file a separate bug for tracking separators and navigation between those separators.
done. filed bug 793996 for the reload indicator.
Blocks: 793996
(In reply to Dave Camp (:dcamp) from comment #7)
> What if on page load we collapsed old information into one line that could
> be expanded (put back into the web console) with a click?  Would that be too
> much work when folks care about old information?

I like this a lot. Clear on reload with a subtle clickable bar above the new output that will expand to show you output from previous loads. It's always collapsed by default. What was wrong with this?
(In reply to Heather Arthur [:harth] from comment #23)
> (In reply to Dave Camp (:dcamp) from comment #7)
> > What if on page load we collapsed old information into one line that could
> > be expanded (put back into the web console) with a click?  Would that be too
> > much work when folks care about old information?
> 
> I like this a lot. Clear on reload with a subtle clickable bar above the new
> output that will expand to show you output from previous loads. It's always
> collapsed by default. What was wrong with this?

Comment 12.

I think those issues are solvable by being smarter about how we expire old messages. i.e. expiring pages en-masse rather than line by line.
Blocks: console-output
Priority: -- → P2
Attached patch proposed patch (obsolete) — — Splinter Review 
Added a pref to clear output on page navigation/reload and a test.

Do we want to add this option to the toolbox Options panel? I would like that but we should also avoid adding too many options there.

Do we want clear-on-navigate to be the default behavior? I am undecided.

Thank you!

Try push: https://tbpl.mozilla.org/?tree=Try&rev=8066d4d3e49b
Assignee: nobody → mihai.sucan
Status: NEW → ASSIGNED
Attachment #754989 - Flags: review?(rcampbell)
(In reply to Mihai Sucan [:msucan] from comment #26)
> Do we want to add this option to the toolbox Options panel? I would like
> that but we should also avoid adding too many options there.
> 
Do not worry about that. It will soon require multi panes behind side menu widget anyways. Now that disable cache, javascript and font size option are on their way.
(In reply to Girish Sharma [:Optimizer] from comment #27)
> (In reply to Mihai Sucan [:msucan] from comment #26)
> > Do we want to add this option to the toolbox Options panel? I would like
> > that but we should also avoid adding too many options there.
> > 
> Do not worry about that. It will soon require multi panes behind side menu
> widget anyways. Now that disable cache, javascript and font size option are
> on their way.

are you getting design help from shorlander and crew? I'd rather you didn't add too much to the options panel without some #UX approval. Also, this doesn't belong in this bug. :)
(In reply to Mihai Sucan [:msucan] from comment #26)
> Created attachment 754989 [details] [diff] [review]
> proposed patch
> 
> Added a pref to clear output on page navigation/reload and a test.
> 
> Do we want to add this option to the toolbox Options panel? I would like
> that but we should also avoid adding too many options there.

This seems like an option that we should leave close to the console. Maybe a checkbox on the toolbar itself?

> Do we want clear-on-navigate to be the default behavior? I am undecided.

I'm not sure either. I think I'd prefer to keep this as it is now and give users a button somewhere to enable it.
(In reply to Rob Campbell [:rc] (:robcee) from comment #28)
> (In reply to Girish Sharma [:Optimizer] from comment #27)
> > (In reply to Mihai Sucan [:msucan] from comment #26)
> > > Do we want to add this option to the toolbox Options panel? I would like
> > > that but we should also avoid adding too many options there.
> > > 
> > Do not worry about that. It will soon require multi panes behind side menu
> > widget anyways. Now that disable cache, javascript and font size option are
> > on their way.
> 
> are you getting design help from shorlander and crew? I'd rather you didn't
> add too much to the options panel without some #UX approval. Also, this
> doesn't belong in this bug. :)

I am not adding something right now, But will surely contact Stephen when I (or someone else) will. For immediately now, Disable JS options is coming up, which I think can just slide along the 2 checkboxes on botom right.
Comment on attachment 754989 [details] [diff] [review]
proposed patch

Review of attachment 754989 [details] [diff] [review]:
-----------------------------------------------------------------

looks fine. Just fine.
Attachment #754989 - Flags: review?(rcampbell) → review+
(In reply to Rob Campbell [:rc] (:robcee) from comment #29)
> > Do we want to add this option to the toolbox Options panel? I would like
> > that but we should also avoid adding too many options there.
> 
> This seems like an option that we should leave close to the console. Maybe a
> checkbox on the toolbar itself?

The toolbar is already cluttered. I was thinking we have the following possibilities:

1. add a checkbox in the toolbar. (not nice, due to clutter)
2. add a checkbox item in the context menu. (not nice)
3. add a checkbox in the Options panel.
4. add a Settings button (a gear like in the debugger) with a drop down where we can show this new checkbox for persistent logs, and maybe we can move the "log response bodies" checkbox to this place as well.

Thoughts? I prefer options 3 or 4. If we pick option 4 I think we want to do this in a separate bug.


> > Do we want clear-on-navigate to be the default behavior? I am undecided.
> 
> I'm not sure either. I think I'd prefer to keep this as it is now and give
> users a button somewhere to enable it.

Agreed.
From a somewhat different direction...

If there were separators between page loads (which is mentioned in Bug 655700 I think) then that separator itself could have a preference embedded in it.  I would imagine some bar that indicated the time when the new page was navigated to, and what URL, and you could have a checkbox on that same bar.
(In reply to Mihai Sucan [:msucan] from comment #32)
> (In reply to Rob Campbell [:rc] (:robcee) from comment #29)
> > > Do we want to add this option to the toolbox Options panel? I would like
> > > that but we should also avoid adding too many options there.
> > 
> > This seems like an option that we should leave close to the console. Maybe a
> > checkbox on the toolbar itself?
> 
> The toolbar is already cluttered. I was thinking we have the following
> possibilities:
> 
> 1. add a checkbox in the toolbar. (not nice, due to clutter)
> 2. add a checkbox item in the context menu. (not nice)
> 3. add a checkbox in the Options panel.
> 4. add a Settings button (a gear like in the debugger) with a drop down
> where we can show this new checkbox for persistent logs, and maybe we can
> move the "log response bodies" checkbox to this place as well.
> 
> Thoughts? I prefer options 3 or 4. If we pick option 4 I think we want to do
> this in a separate bug.

I don't think this checkbox needs frequent access. People generally like it one way or the other. We should avoid having many places to look in order to configure this thing, so the options panel is the right place for this.

> > > Do we want clear-on-navigate to be the default behavior? I am undecided.
> > 
> > I'm not sure either. I think I'd prefer to keep this as it is now and give
> > users a button somewhere to enable it.
> 
> Agreed.

I think there are 3 reasons to prefer clear-by-default:
* It's what people expect from using other browsers (except Opera), so it's what we should deliver by default.
* I think it's the default in other places because it seems more likely that people are going to use F5 to 'have another go' and so want a clean sheet, than to be able to compare 2 situations.
* People have got used to (and annoyed by) the current behaviour, if we just add an option they're not likely to notice the change, where as someone that likes the current no-clear behaviour is going to notice, and think "that's not what I wanted, how can I turn that off".
Joe, you make good points. Thank you! I will update the patch accordingly.
Attached patch updated patch (obsolete) — — Splinter Review 
Updated the patch as agreed. Added an option to turn on/off persistent logs in the web console. Turned the pref off by default so we have clear-on-reload. Also had to fix some tests that did depend on the old behavior.

New try push: https://tbpl.mozilla.org/?tree=Try&rev=9e700fe5c2fb
Attachment #754989 - Attachment is obsolete: true
Attachment #756683 - Flags: review?(jwalker)
Attached patch test fixes — — Splinter Review 
Previous patch had failures on the try servers in the toolbox options panel test. This is the updated patch with fixes.

Green try push: https://tbpl.mozilla.org/?tree=Try&rev=886faaaf7b23
Attachment #756683 - Attachment is obsolete: true
Attachment #756683 - Flags: review?(jwalker)
Attachment #757868 - Flags: review?(jwalker)
Comment on attachment 757868 [details] [diff] [review]
test fixes

Review of attachment 757868 [details] [diff] [review]:
-----------------------------------------------------------------

+1, RT, Like, etc
Attachment #757868 - Flags: review?(jwalker) → review+
Thank you!

Landed: https://hg.mozilla.org/integration/fx-team/rev/5dd0e1ec10f5
Whiteboard: [fixed-in-fx-team]
Would it make sense to move all of our tool-specific prefs in the Options panel? Having a stray checkbox in there feels a bit awkward.
(In reply to Victor Porof [:vp] from comment #40)
> Would it make sense to move all of our tool-specific prefs in the Options
> panel? Having a stray checkbox in there feels a bit awkward.

Probably yes. Please file a follow-up bug report.
https://hg.mozilla.org/mozilla-central/rev/5dd0e1ec10f5
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 24
Comment on attachment 757868 [details] [diff] [review]
test fixes

Review of attachment 757868 [details] [diff] [review]:
-----------------------------------------------------------------

+1, RT, Like, etc
Depends on: 882470
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: