Consistent blocklist UX with better icons & wording

[digitarald]

Follow up discussion from bug 1564913.

The goals here is to make blackboxing

1. easier to identify per file, so users don't accidentally wait to pause in them
2. more inclusive with a better name

Quick audit of dev documentation on use of blocklisting (current called "blacklisting"):

1. VSCode
   • Mostly Skip Files but uses blackbox & Ignore in documentation
   • The new wording was used because files.exclude was taken for other settings
2. Chrome
   • Eses blackboxing as feature name but explains the concept with many other words:
   • Latest: Header is Ignore a script or pattern of scripts. blackbox is used most, but also script is obscured in the Call Stack pane
   • Old: Explained omit third-party files, hides any function calls from the blackboxed scripts and exclude the calls from the call stack
   • Oldest): Uses Blackboxing, but also Library code
3. Old Edge:
   • Toolbar button Debug just my code to toggle exclusion, explained with include or exclude all the files
   • File toggles are Mark as my code vs Mark as library code
   • Docs header is Code Scoping, explained with ignore certain files, skip over any files

Looks like the top plain verbs/state are:

1. Ignore / Ignored
2. Exclude / Excluded
3. Skip / Skipped

Icon-wise simple stop sign or crossed out file might just work if used consistently; but more ideas are welcome.

Would love to hear more thoughts.

[nchevobbe]

Just a small note that this should be made clear that this only affect debugging, and not the content execution. The person who reported the issue was confused at first and was wondering if blackboxing a file makes it invisible for the content page.

[fvsch]

My preferred verb would be "Ignore". Re. Nicolas' point, I don't think any verb would make that distinction clear, we would have to expand to "Ignore this script in stack traces" or something similarly specific.

"Mark as library code" also has some precedent in Intellij IDEs (IDEA, Webstorm, etc.). You can mark a folder as different types (source roots, resource roots, excluded), with some types excluding the files in debugging but not in intellisense. See: https://www.jetbrains.com/help/webstorm/configuring-project-structure.html

Finally, based on this post "The Challenges with Single Toggle Buttons" and the bug report in bug 1564913, I think we could afford to show a label next to the Blackbox button when it's on. With the current labels:

• Off: icon only, tooltip "Blackbox source"
• On: icon with tooltip "Unblackbox source" and, to the right, "Blackboxed source"
• Maybe using red instead of blue for the active icon?

Support for blackboxed sources in the Sources pane could be improved too. Currently when a source is blackboxed it's not shown, and the context menu still says "Blackbox source" instead of "Unblackbox source".

[digitarald]

@violasong this isn't urgent, but it might be useful not to let this conversation sit for too long as we got contributors working on blackboxing. What are your thoughts on next steps?

[violasong]

I've been thinking about this but having a hard time wrapping my mind around it (as you can see from the violasong added this to Today in Victoria's Tasks 13 days ago message 😅).

Some thoughts:

• Icon: A crossed-out file seems great.
• Title/contextual menu text: I like the idea of saying Ignore Source (or Ignore Script). Is there danger in this? Would people actually try to use this to mean "Ignore in execution?" Seems like it would be fine to say something along the lines of "Ignore in Debugging" as well.
• On-state: Having the inline text next to the icon looks great
• Breakpoint functionality: Could we un-ignore after the user clicks to add a breakpoint? (Same as the recent functionality that re-enables breakpoints globally when adding a breakpoint)

[digitarald]

Would people actually try to use this to mean "Ignore in execution?" Seems like it would be fine to say something along the lines of "Ignore in Debugging" as well.

To avoid a longer wording, a title can also clarify. Integrating Debugger sources with the planned Resource blocking ("Block source URI from loading"), could also improve the differentiation by offering the actual feature in the same menu.

Could we un-ignore after the user clicks to add a breakpoint?

Makes sense. Maybe we can consider a "toast" notification to highlight that "hidden" reaction? But on the other side, if the file-is-ignored-hint is visible enough, users should be able to tell when it goes away.

@violasong @fvsch do we have remaining questions or are we ready to capture all decisions in final mockups with the right icons and wording?

[fvsch]

No more questions for me. I like where Victoria's thoughts are going overall :)

[violasong]

Re: toast, a yellow flash effect could make sense as well. I'd see this as something to think about for the next version. (For comparison, Chrome doesn't seem to do any effects when adding a breakpoint in disabled-bp mode.)

Sounds like next step is we need a crossed-out file icon? (Rest of the design seems pretty straightforward)

[violasong]

@fvsch Would you be interested in making a cross-out file icon for this bug? (Maybe we could reuse the print simulation icon and add a strikeout)

[digitarald]

Filed bug 1642811 for the renaming.