1287694 - Notify users of stale sources in console logs when persistent logs is enabled

Status: NEW

(DevTools :: Console, enhancement, P3)

Description

[Jaideep Bhoosreddy [:jbhoosreddy]]

Logs in the console almost always point to a source location, typically in Debugger or View Source. When "Enable persistent logs" preference is enabled, and a page is refreshed, new logs are appended to the previous ones instead of replacing them.

In this case, the old logs can point to stale sources which are no longer valid in the console/debugger. We should show the developer which sources are stale and which are still valid.

Comment 1

[Jaideep Bhoosreddy [:jbhoosreddy]]

Attachment: console_stale_sources.m4v

Comment 2

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

In the event of a stale log, my suggestion would be:

1. Make the stale log links inactive. This means graying them out so visually they look inactive.
2. On hover, adding a "Source has since been modified" in a label, so that users understand why they've been deactivated.

For point 1, I'm willing to have a discussion. It's possible that we only want to change the link styling but still have the links themselves work—what do you think, Jaideep?

Comment 3

[Jaideep Bhoosreddy [:jbhoosreddy]]

I noticed that the new console will resolve this issue in [1]. Given that, would we still want to implement something like this in the existing console? If yes, I would prefer it be similar to the new console experience.

Also, how should it handle page refreshes to notify users of stale logs?

[1] https://github.com/devtools-html/gecko-dev/issues/68

Comment 4

[Lin Clark [:linclark]]

My opinion is that we can wait for this until new console output lands. Brian, how do you feel about that?

Comment 5

[Lin Clark [:linclark]]

> Also, how should it handle page refreshes to notify users of stale logs?

Checked in Chrome and page refreshes are displayed in the same way as page navigations, so I'd say let's copy them.

Comment 6

[Brian Grinstead [:bgrins]]

(In reply to Jaideep Bhoosreddy [:jbhoosreddy] from comment #3)
> I noticed that the new console will resolve this issue in [1]. Given that,
> would we still want to implement something like this in the existing
> console? If yes, I would prefer it be similar to the new console experience.
> 
> Also, how should it handle page refreshes to notify users of stale logs?
> 
> [1] https://github.com/devtools-html/gecko-dev/issues/68

My reading of this bug is that it's not the same thing as that issue.  There, we are adding the persisted logs option and navigation message (which already exists in the current frontend).  This bug is about somehow annotating source links that don't exist / have been modified since the navigation as such, and I don't think we have anything planned for that in the new console yet.

Question about this bug - how do we determine if a source has been changed?  i.e. on a page refresh it might be that:
1) The source doesn't exist at all on the new page
2) The source does still exist and hasn't been modified
3) The source does still exist and has been modified

Do we have a good way to distinguish between these three cases?

Comment 7

[Jaideep Bhoosreddy [:jbhoosreddy]]

(In reply to Brian Grinstead [:bgrins] from comment #6)
> (In reply to Jaideep Bhoosreddy [:jbhoosreddy] from comment #3)
> > I noticed that the new console will resolve this issue in [1]. Given that,
> > would we still want to implement something like this in the existing
> > console? If yes, I would prefer it be similar to the new console experience.
> > 
> > Also, how should it handle page refreshes to notify users of stale logs?
> > 
> > [1] https://github.com/devtools-html/gecko-dev/issues/68
> 
> My reading of this bug is that it's not the same thing as that issue. 
> There, we are adding the persisted logs option and navigation message (which
> already exists in the current frontend).  This bug is about somehow
> annotating source links that don't exist / have been modified since the
> navigation as such, and I don't think we have anything planned for that in
> the new console yet.
> 
> Question about this bug - how do we determine if a source has been changed? 
> i.e. on a page refresh it might be that:
> 1) The source doesn't exist at all on the new page
> 2) The source does still exist and hasn't been modified
> 3) The source does still exist and has been modified
> 
> Do we have a good way to distinguish between these three cases?

Yes. This bug is slightly different from the issue on GitHub, but it draws on the similar idea. The goal for this one, I believe, was not to tell the user which of the three cases has happened, but rather simply notify that something like that might have happened.
A simple message after page refresh (hinting "Sources might have changed") might be enough for this purpose, and if we want to take it further, we can disable the links from the frames rendered before refresh. The idea was to allow users easily differentiate the old log messages from the current ones.

As for distinguishing between these three cases, I don't think it is possible as we lose all that information on page reload also, afaik.

Comment 8

[Brian Grinstead [:bgrins]]

OK, in that case I don't think it's worth making modifications to the current navigation marker widget / console output since this feature is off by default and we are actively working on a replacement.

Would like Helen's feedback on if/how we should message this in the UI.  There's a suggestion in Comment 7 to add extra text to the navigation message being added in https://github.com/devtools-html/gecko-dev/issues/68, and also a suggestion in Comment 2 to grey out links that happened before the navigation.  If we don't have a way to tell if the source has actually changed, then I wouldn't want to fully deactivate the links.

Comment 9

[Jordan Santell [:jsantell] [@jsantell]]

(In reply to Brian Grinstead [:bgrins] from comment #6)
> (In reply to Jaideep Bhoosreddy [:jbhoosreddy] from comment #3)
> Question about this bug - how do we determine if a source has been changed? 
> i.e. on a page refresh it might be that:
> 1) The source doesn't exist at all on the new page
> 2) The source does still exist and hasn't been modified
> 3) The source does still exist and has been modified
> 
> Do we have a good way to distinguish between these three cases?

We could potentially differentiate between these states by checking debugger sources, but seems like overkill and costly. Also adding in source maps, we'd have to check that the original location and also the source mapped location are in parity, adding more complexity, when really, the main thing that we'd want to convey is, "this is not referencing a live script; link with caution".

I think eliminating the link could be frustrating when still valid or nearby (like adding one console log statement during debugging)

Comment 10

[Nicolas Chevobbe [:nchevobbe]]

We now have the navigation marker displayed, which solves one part of the problem.
The other part would be to disable any interaction that can't be performed after a navigation:

• clicking on the location to open the source in debugger/style editor
• clicking on a stacktrace frame to open the source in debugger
• clicking on the "jump to definition" icon displayed next to functions
• clicking on the "select in inspector" icon displayed next to HTLMElements
• expanding an object (or a property)
• cmd+click on an object to put it in the sidebar (+ context menu entry)
• context menu entry to open a network request in the netmonitor

The first step would be to have a readOnlyMessages structure in the state with all the "old messages". This would be populated on WILL_NAVIGATE action, and would cause some re-rendering (adding disabled attribute to the right elements for example).