In Google Chrome : - open devtools -> console - check "Preserve logs" - send `console.log("test")` - send `console.clear()` The "test" log will remain in the console here (because of "Preserve logs" : https://developer.chrome.com/devtools/docs/console-api#consoleclear). However, if you close and reopen the devtools, the log is gone. This behaviour is nice because console.clear() still removes all messages from the actual Console on the "back-end". But *if* the developer has the console open, they have a UI-only way to bypass unwanted calls to console.clear(). Let's consider implementing a similar behavior now that console.clear landed in Bug 659625.
Created attachment 8745681 [details] [diff] [review] bug1267856.wip.patch Just to illustrate the feature (new test needs cleanup)
Created attachment 8745698 [details] [diff] [review] bug1267856.wip.patch Test cleanup.
Attachment #8745681 - Attachment is obsolete: true
Brian, do we want to follow Chrome's behavior here? I think it's a nice addition, but up to you.
(In reply to Julian Descottes [:jdescottes] from comment #3) > Brian, do we want to follow Chrome's behavior here? I think it's a nice > addition, but up to you. 'Persist logs' seems like a kind of random option to affect console.clear() behavior. I wonder if that's an intentional feature or an accident. The code to handle this is super simple though, so it wouldn't be much to take it on. But, who are we helping here? If I'm thinking "I want logs to be persisted across page reloads" then do I care about console.clear() behavior? Maybe. I don't know. If I'm thinking "I wish the page wasn't able to clear the console", I don't know if temporarily preventing it in the frontend helps too much, since messages are still cleared if I haven't yet opened the toolbox. Certainly I wouldn't think to try this option as a workaround. In this case, then what would be more helpful is showing a "Console was cleared. [Prevent this]" message, where clicking [Prevent this] actually prefs off console.clear entirely from the backend. What would be great here is having data of how many sites are using this API (versus it just being used in development). Bryan, do you have an opinion about this feature?
Flags: needinfo?(bgrinstead) → needinfo?(clarkbw)
I'll defer to helen here, but I agree that we want some user control over this. In a very similar manner to the mockups I've seen for how to show people there are active filters hiding messages I think we could do something that says what you're suggesting. I would probably just hide/filter the logs such that with a click the person could bring them back into view. The more you treat it like a filter option I think the easier the interaction and undo methods would be.
Flags: needinfo?(clarkbw) → needinfo?(hholmes)
Created attachment 8747695 [details] filtering-logs.png (In reply to Brian Grinstead [:bgrins] from comment #4) > 'Persist logs' seems like a kind of random option to affect console.clear() > behavior. I have to agree; this option makes me think that someone wants logs to persist across page reloads, not when they explicitly press a "clear" button or explicitly type "console.log()". My recommendation would be to make the feature work in this way. (In reply to Bryan Clark (DevTools PM) [@clarkbw] from comment #5) > I'll defer to helen here, but I agree that we want some user control over > this. In a very similar manner to the mockups I've seen for how to show > people there are active filters hiding messages I think we could do > something that says what you're suggesting. I would probably just > hide/filter the logs such that with a click the person could bring them back > into view. The more you treat it like a filter option I think the easier > the interaction and undo methods would be. I like this as an idea. It could look something like the attachment. The relevant message in there is the second one—"You are currently persisting logs. Learn more about our filtering syntax here."
You need to log in before you can comment on or make changes to this bug.