1534706 - invoke getter popup breaks typing flow.

Status: RESOLVED FIXED

(DevTools :: Console, enhancement, P2)

Description

[Dave Townsend [:mossop]]

I find the invoke getter popup to be very intrusive. I like the idea of it but as it works now it completely breaks my flow.

Heres's what I want to do:

1. Open browser console.
2. Type gBrowser.currentURI.host
3. Get the result.
4. Press up because I want a different property.
5. Backspace back to gBrowser.currentURI. and type hostPort
6. get the result.

Here's what actually happens:

1. Open browser console.

2. Type gBrowser.currentURI. ... gah the popup appears and I can't type anymore, I have to ether hit escape or click somewhere to get rid of it so I can carry on typing.

3. Press up because I want a different property.

4. Backspace back to gBrowser.currentURI. and ... gah the popup has appeared again.

Comment 1

[:Harald Kirschner :digitarald]

Makes a lot of sense; autocomplete should not steal focus.

Looks like one solution is to let users continue to type – which would hide the popup. Any other ideas, Nicolas?

Comment 3

[eric]

On Linux (Ubuntu 18.04) if you hit Enter or Space in the autocomplete it also inserts that character (space or new line). If you then press backspace to get rid of the new character the autocomplete pops up again.
This means you have to grab your mouse and click the "Invoke" to actually use the feature.
Escape works since it doesn't insert a new character.

I thought this belonged here since it also breaks typing flow.

Comment 4

[:Harald Kirschner :digitarald]

Nicolas, let's try to get to find a solution as we want to find a flow that works for power users (aka FF engineers). This isn't a P1 but an important follow up that we need prioritize.

What are your thoughts on a solution?

Comment 5

[Nicolas Chevobbe [:nchevobbe]]

Maybe we could not show it anymore if the user dismissed it once? It could still be force-displayed with Ctrl+Space.
How would that feel eric, mossop?

Comment 6

[Dave Townsend [:mossop]]

I don't have a problem with the popup showing, I just don't think it should steal focus from the text box, you should be able to just keep on typing even though the popup is up.

Comment 7

[:Harald Kirschner :digitarald]

Agreed, lets try that first and see how it feels – which probably needs extra tweaking to get it right.

Handling dismissing better would be generally useful as well, maybe this can be a separate bug. But lets do some more research on how users use this.

Comment 8

[eric]

This issue usually comes up during development if I wanna access something in Vue through console which naturally nests everything quite deep so the popup shows up several times in one line.

If you can continue typing (like the autocomplete in console) then it would be easier to ignore, but not easier to use.
I would like the popup to only show once per line or maybe a setting to permanently invoke/not invoke automatically.

It also doesn't fix the issue on Linux where you have to grab your mouse to click "Invoke" since enter/space will break the flow.

Comment 9

[Nicolas Chevobbe [:nchevobbe]]

Thanks for the answers.
You might want to set devtools.webconsole.input.autocomplete to false as a work around. It won't autocomplete automatically, but you can invoke the popup with Ctrl + Space.

Comment 10

[Nicolas Chevobbe [:nchevobbe]]

Attachment: Bug 1534706 - Don't focus ConfirmDialog when displaying it.

Comment 11

[Nicolas Chevobbe [:nchevobbe]]

mossop, could you pull out https://phabricator.services.mozilla.com/D36174 and tell me if it feels nicer?
With this patch, we don't focus the popup, you can invoke the getter with tab and dismiss the popup with escape (or it goes away if there's no reason for it to be displayed)
I think it's less annoying, but It'd be great if you could assert that.
Thanks!

Comment 12

[Dave Townsend [:mossop]]

Sorry, took me a while to get to this. Unfortunately I can't seem to get the patch to apply.

Comment 13

[Nicolas Chevobbe [:nchevobbe]]

rebased and pushed again, let me know if it applies now

Comment 14

[Dave Townsend [:mossop]]

Yes this looks much better.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/607e46906b3e
Don't focus ConfirmDialog when displaying it. r=Honza

Comment 16

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/607e46906b3e

Comment 17

[Simon]

Sorry for commenting on a closed bug, but the popup still gets in the way of my flow a lot. Why does this popup even exist? The only reason i can thing of for not just invoking the getter are:

• Someone is in the dev tools on a live site.
• The getters are programmed to have serious side effects.

These conditions should be so ultra rare that I feel we shouldn't delay web devs everywhere just to prevent this issue.
I say just invoke the getter (and show result preview), dont ask permission.

Comment 18

[Nicolas Chevobbe [:nchevobbe]]

Hello Simon

(In reply to Simon from comment #17)

• The getters are programmed to have serious side effects.

These conditions should be so ultra rare that I feel we shouldn't delay web devs everywhere just to prevent this issue.
I say just invoke the getter (and show result preview), dont ask permission.

One of the goal we set for our tools is that they shouldn't be confusing. If a getter has some side effects (they don't need to be serious, it could be incrementing a counter for example), as a user I wouldn't expect the autocompletion to trigger it, and I'd scratch my head for a long time trying to figure out what's going on.
We know the popup isn't perfect, but it's better than making someone lose hours trying to figure out a bug.
That being said, we might have something in the next months to detect if a given getter has no side effect and execute it right away.