Clicking on logPoints location

[nchevobbe]

In Bug 1557138 we want to make it easier to show what a logpoint expression is when the user click on the location in the console.

Here are some scenarios:

• The user added a logPoint with the following expression a, b, c (in the middle of other logPoints). This produces undefined, false, 1, in the middle of other logs, and the user isn't sure to what expression/variable these values are related.
• The user added a logPoint, and from the console, simply want to remove it as it's not needed anymore.
• The user added a logPoint foO.name which produces an error in the console (because foO does not exist). They want to fix this into foo.name.

The idea we had was to make it so that when the user click on a logPoint location message in the console, we would automatically open the file at the correct location + the logPoint input so the user can read and/or edit what was the expression.

@jasonLaster worries that we may put to much emphasis on the "editable" state, which would confuse error who only want to read the value (or simply navigate to the file). The logPoint expression is displayed in the breakpoint panel, may be cropped, but the whole value is available in a tooltip when hovering it.

One of the counter proposal would be to "flash" the background of both the source line (which we currently do) + the expression in the breakpoints panel (and not auto-open the expression input)

---

For what it's worth, when clicking a logpoint location in Chrome, a new source is opened in the debugger, with a comment explaining that it's a logPoint (I don't think this is good :) )

---

What's your thoughts on this?

[jasonLaster]

Thanks for the writeup.

We intentionally use the source location as we want to keep the log point in context as much as possible.

At the moment we rely on tooltips to help users see the message. There's a tooltip for the breakpoint and the breakpoint panel message.

It would be nice to make editing more discoverable.

• At the moment, users can double click on the breakpoint message to edit. It would be fun to build a fun hint UI that shows up and can be dismissed.
• I am reluctant to make clicking the console link the easiest way to edit because it feels like an anti-pattern, go to the console to edit a breakpoint...
• We are planning on building a better breakpoint editing UI in the fall maybe this fits under that

My suggestion for flashing was mostly to help users see which breakpoint they had navigated to. Flashing the breakpoint, line, and message would make that clearer. It does not help users edit a breakpoint though.

[chujunlu]

I agree with @nchevobbe last comment in patch. Clicking location of a logPoint error message in console, the user's intention is likely to be editing that logPoint expression. Maybe for error, open logPoint panel to facilitate editing; for normal log message: signal user the intended logPoint.

[fvsch]

@jasonLaster worries that we may put to much emphasis on the "editable" state, which would confuse error who only want to read the value (or simply navigate to the file).

I tend to agree.

Clicking location of a logPoint error message in console, the user's intention is likely to be editing that logPoint expression.

I'm not seeing it, personally. What signals do we have from users that it's the topmost likely intention in this context?

Update: not convinced that editing is a primary use case, but showing the editor is the best way we currently have to show the log point expression, so I'm not against opening the editor when clicking its location in Console.

[digitarald]

I like the idea of opening the edit dialog by default, as editing logpoints is somewhat hidden behind double-clicking the BP entry or the BPs context menu. Impact is minimal as the editing dialog can be easily closed by ESC or blurring the input, a single click or keystroke. I don't fully trust the alternative of flashing the target breakpoint as our flashing animations often fall short in duration and contrast to be really visible.

As a follow up, we can come up with a better editing workflow when we streamline the conditional/logpoint edit form eventually.

[fvsch]

Small digression: I wonder if we should just keep log points and conditional breakpoints visible at all times in the source in Debugger? Perhaps with a tweaked design that makes the mini-editor shorter. Then you can see the log expression at any time, edit it, delete it.

Personally, having this stuff hidden has always been a painful experience. I forget what the color-coding means, I click the breakpoint indicator and it deletes stuff?? Maybe I'm just bad at this.

[violasong]

Yes! Love this idea of keeping log points conditional breakpoints visible at all times!

(As a general UX observation, this reminds me of our badges in Markup view - how we were worried about cluttering things up; but actually, this interactive bonus annotation UI is much more valuable per square pixel than the raw source, so it deserves the prominence. Decluttering can be made elsewhere, like HAMLing the HTML)

[digitarald]

Aside continued in #80.

Do we have mostly a quorum for showing the dialog (for now) for jump to source?

[jasonLaster]

I think so... lets give it a try and see how it feels. we'll likely revisit this when we look more into editing.

I think an always visible expression could be nice if we have a minimal ui