GCLI tooltip text gets cut off

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
6 years ago
26 days ago

People

(Reporter: vporof, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Created attachment 673145 [details]
help popup

STR: type dbg, return.
I couldn't find any other related bug filed, but please close this if a dupe.
Summary: GCLI help text gets cut off → GCLI tooltip text gets cut off
I'm not sure what we should do about this. We could widen the max-width of the tooltip, but where do we stop with that? People are going to create longer and longer tooltips, and not realize that other people have narrower screens, so there needs to be a limit on the length of the help text.

Also on the other side: TL;DR.

If it's not possible to meaningfully shrink the descriptions then perhaps our limits are too limiting. Might shrinking them work?

Perhaps also we should make a hard limit (via an exception) on command descriptions???
(Reporter)

Comment 2

6 years ago
Is having a fluid layout is out of the question? I mean, why couldn't we just allow text to break here as well, like in the 'help' popup?
(In reply to Victor Porof [:vp] from comment #2)
> Is having a fluid layout is out of the question? I mean, why couldn't we
> just allow text to break here as well, like in the 'help' popup?

There isn't really a help popup - there's the output of the help command, which like all output is wrapped.

This is just a menu. In a way, I'm tempted take away all the descriptions like normal menus. I think that having it wrap makes it uglier, harder to scan, and less likely to be read. I really think we can do more by being more concise in how we describe the commands.

Could we change the description text to be manual text (which is used by the help command) and introduce a more concise description text?

dbgContinue=Continue script execution
dbgStepOverDesc=Pause at next statement in this function
dbgStepInDesc=Pause at next statement
dbgStepOutDesc=Pause at next statement in calling function

Are the current descriptions accurate? What does 'main thread' mean to a JavaScript developer?
(Reporter)

Comment 4

6 years ago
(In reply to Joe Walker [:jwalker] from comment #3)
> (In reply to Victor Porof [:vp] from comment #2)
> > Is having a fluid layout is out of the question? I mean, why couldn't we
> > just allow text to break here as well, like in the 'help' popup?
> 
> There isn't really a help popup - there's the output of the help command,
> which like all output is wrapped.
> 
> This is just a menu. In a way, I'm tempted take away all the descriptions
> like normal menus. I think that having it wrap makes it uglier, harder to
> scan, and less likely to be read. I really think we can do more by being
> more concise in how we describe the commands.

Fwiw, this also happens with other commands, like pagemod, but indeed, most of the commands have *short enough* descriptions to fit in there.

I'd be happy, thought, if this menu (and the help popup) would be a tiny bit wider to allow for more wordy descriptions if necessary. For example, what happens with command 'foo bar baz omega epsilon'? There's almost no room left in there for descriptions. But that's a different bug.

> Could we change the description text to be manual text (which is used by the
> help command) and introduce a more concise description text?

That's a good enough solution.

> dbgContinue=Continue script execution
> dbgStepOverDesc=Pause at next statement in this function
"current function" sounds more appropriate
> dbgStepInDesc=Pause at next statement
> dbgStepOutDesc=Pause at next statement in calling function

> Are the current descriptions accurate? What does 'main thread' mean to a
> JavaScript developer?

I think loosely translating it would be 'script execution', so for consistency, let's also modify dbgInterrupt to read "Pause script execution"
(In reply to Victor Porof [:vp] from comment #4)
> I'd be happy, thought, if this menu (and the help popup) would be a tiny bit
> wider to allow for more wordy descriptions if necessary. For example, what
> happens with command 'foo bar baz omega epsilon'?

OK, I'm happy to grow it a bit.

> > Could we change the description text to be manual text (which is used by the
> > help command) and introduce a more concise description text?
> 
> That's a good enough solution.
> 
> > dbgContinue=Continue script execution
> > dbgStepOverDesc=Pause at next statement in this function
> "current function" sounds more appropriate
> > dbgStepInDesc=Pause at next statement
> > dbgStepOutDesc=Pause at next statement in calling function
> 
> > Are the current descriptions accurate? What does 'main thread' mean to a
> > JavaScript developer?
> 
> I think loosely translating it would be 'script execution', so for
> consistency, let's also modify dbgInterrupt to read "Pause script execution"

Is there a bug for this?
If so, I'll make this bug depend on that so I've got more data on how much to widen by.
Why don't we just fit it to the text like we do with the help popup?
(In reply to Michael Ratcliffe [:miker] [:mratcliffe] from comment #6)
> Why don't we just fit it to the text like we do with the help popup?

Because we don't want to fit very long text in. This is a menu that the user scans, so brevity is a feature and the maximum width is a leaver to encourage command authors to make their descriptions quickly scannable.
(Reporter)

Comment 8

6 years ago
(In reply to Joe Walker [:jwalker] from comment #5)
> > > dbgContinue=Continue script execution
> > > dbgStepOverDesc=Pause at next statement in this function
> > "current function" sounds more appropriate
> > > dbgStepInDesc=Pause at next statement
> > > dbgStepOutDesc=Pause at next statement in calling function
> > 
> > > Are the current descriptions accurate? What does 'main thread' mean to a
> > > JavaScript developer?
> > 
> > I think loosely translating it would be 'script execution', so for
> > consistency, let's also modify dbgInterrupt to read "Pause script execution"
> 
> Is there a bug for this?
> If so, I'll make this bug depend on that so I've got more data on how much
> to widen by.

Not that I'm aware of. We can make these changes here.
New component triage. Filter on "Lobster Thermidor aux crevettes with a Mornay sauce"
Component: Developer Tools → Developer Tools: Graphic Commandline and Toolbar
Triage. Filter on Lobster Thermidor.
Nice idea, but it's not been worked on in 4 years, and I don't see that the priority of GCLI has increased in that time, so I don't think we need to keep it on file.
Triage. Filter on Lobster Thermidor.
Actually closing this time.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX

Updated

4 months ago
Product: Firefox → DevTools

Updated

26 days ago
Product: DevTools → DevTools Graveyard
You need to log in before you can comment on or make changes to this bug.