1267856 - Console.clear should not clear the console if "Enable persistent logs" is ON

Status: RESOLVED FIXED

(DevTools :: Console, enhancement, P3)

Description

[Julian Descottes [:jdescottes]]

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.

Comment 1

[Julian Descottes [:jdescottes]]

Attachment: bug1267856.wip.patch

Just to illustrate the feature (new test needs cleanup)

Comment 2

[Julian Descottes [:jdescottes]]

Attachment: bug1267856.wip.patch

Test cleanup.

Comment 3

[Julian Descottes [:jdescottes]]

Brian, do we want to follow Chrome's behavior here? I think it's a nice addition, but up to you.

Comment 4

[Brian Grinstead [:bgrins]]

(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?

Comment 5

[Bryan Clark (DevTools PM) [: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.

Comment 6

[Helen V. Holmes (:helenvholmes) (:✨)]

Attachment: 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."

Comment 7

[Dennis Schubert [:denschub]]

I'm adding this to the devtools-webcompat-team metabug, because while diagnosing, I just ran into a site that calls console.clear() repeatedly, making it almost impossible to see what's going on. That being said, this probably should have a very low probability. Sites like this only surface once per quarter or less, and if that happens, proxying the offending JavaScript file and commenting out the clear instruction only takes an additional 15mins or so. So it's somewhat infuriating, but working around doesn't take too much time at all.

Comment 8

[adomsyik]

I tested this simple HTML file containing just this code (below) using the current version of Firefox (103.0.2 (64-bit)) and discovered that it ignores the “persist logs” not only on the per-tab console log, but also the browser console.

<script>
	console.clear()
</script>

According to this PDF file on page 5 on the PDF reader (2938 on the page), it is one of the malicious page developer's method to evade debugging, by calling code repeatedly/constantly. As stated on the MDN docs, that console.clear should only be able to clear the console log if the environment allows it. Google chrome's “Preserve Log” does prevent the log from being cleared, and it will say this:

console.clear() was prevented due to 'Preserve log'

I'm pretty sure browsers shouldn't acts in ways against the user will, as browsers are a user agent, not a site agent. Which is why sites using quote on quote “DRM” (disabling context menu, select, shortcut keys) cannot disable or affect the browser's toolbar, menu bar, or any of its widgets. Because if sites can do that, than so can malicious sites, such as tech support scams and any other sites attempting to browlock your browser.

Comment 9

[lilydjwg]

I have issues logging into a site. Not compatible with Firefox? I open devtools to see if there are errors. There are, but it gets cleared in one second. The page is constantly calling console.clear() to prevent me seeing those errors.

Comment 10

[Daniel Veditz [:dveditz]]

What are the non-abusive scenarios for using console.clear()? If someone is debugging they can clear the console manually whenever it's convenient, and if they're iterating on some code and want an easy way to find when the interesting bits start there are all sorts of console ways to make that easy to find. I'd go so far as to say we should ignore console.clear() by default and make it a feature people can turn on if they want.

I have no strong opinion if overloading "Persist logs" should be the mechanism to control this feature, but I feel very strongly that we need a way to check the widespread abuse of this feature. I'd prefer an independent toggle, but if devs used to working with Chrome expect them to be tied I can live with that.

proxying the offending JavaScript file and commenting out the clear instruction only takes an additional 15mins or so. So it's somewhat infuriating, but working around doesn't take too much time at all.

... assuming the code isn't obfuscated/packed, as malicious code often is
... switching to Chrome takes even less time than that, and easier to think of doing when you're "infuriated". Hope they come back

Comment 11

[Nicolas Chevobbe [:nchevobbe]]

(In reply to Daniel Veditz [:dveditz] from comment #10)

What are the non-abusive scenarios for using console.clear()? If someone is debugging they can clear the console manually whenever it's convenient, and if they're iterating on some code and want an easy way to find when the interesting bits start there are all sorts of console ways to make that easy to find.

I used it in the past at the beginning of an action for which I was then adding lots of logs (so for example, on a button click), so I would get a clean state in the output, with only logs related to the last action I did, without reaching for the clear button first. Not a massive time saver, but it does feel a bit less cumbersome than clicking buttons in the console UI

I'd go so far as to say we should ignore console.clear() by default and make it a feature people can turn on if they want.

Here's the spec for console.clear : https://console.spec.whatwg.org/#clear
It does say that the output should be cleared if the environment allows it (which we do), so I wouldn't make it the default to not clear it.

I have no strong opinion if overloading "Persist logs" should be the mechanism to control this feature, but I feel very strongly that we need a way to check the widespread abuse of this feature. I'd prefer an independent toggle, but if devs used to working with Chrome expect them to be tied I can live with that.

I'm okay with this behavior, and I think this can be done quite easily

Comment 12

[Julian Descottes [:jdescottes]]

I retested on Chrome, and I can still see the same behavior. It seems intentional since they display the following message afterwards:

console.clear() was prevented due to 'Preserve log'

(edit: it's also on their doc: https://developer.chrome.com/docs/devtools/console/api/#clear )

FWIW, Safari does not implement this, and logs are cleared regardless of the Preserve log setting.
And overall I agree binding the 2 features seems a bit random.

I think the main use case for console.clear() is to use it from the DevTools console, not from a script in the page. It would be nice to keep this working by default. Developers are used to this feature, and even if there is a button we should try to maintain parity in terms of console commands.

Maybe we could disable console.clear() calls coming from the page by default? I'm not sure how easy it would be to differentiate the two, but I think legitimate use cases for a console.clear() from the page are quite rare.

Or even simpler, we just have a toggle to disable it, but whenever someone tries to use console.clear() from the console itself we give them an easy way to turn it on?

Comment 13

[Nicolas Chevobbe [:nchevobbe]]

Attachment: Bug 1267856 - [devtools] Don't clear output on console.clear() when persist logs is on. r=#devtools-reviewers.

This is a very naive solution, simply ignoring console.clear
messages when the preference is true.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2c092fc18bd1
[devtools] Don't clear output on console.clear() when persist logs is on. r=devtools-reviewers,bomsy.

Comment 15

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/2c092fc18bd1