Closed Bug 1534706 Opened 9 months ago Closed 5 months ago

invoke getter popup breaks typing flow.

Categories

(DevTools :: Console, enhancement, P2)

enhancement

Tracking

(firefox70 fixed)

RESOLVED FIXED
Firefox 70
Tracking Status
firefox70 --- fixed

People

(Reporter: mossop, Assigned: nchevobbe)

References

Details

Attachments

(1 file)

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.

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?

Flags: needinfo?(nchevobbe)
Flags: needinfo?(nchevobbe)
Priority: -- → P2
Duplicate of this bug: 1540060

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.

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?

Flags: needinfo?(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?

Flags: needinfo?(nchevobbe)
Flags: needinfo?(eric)
Flags: needinfo?(dtownsend)

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.

Flags: needinfo?(dtownsend)

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.

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.

Flags: needinfo?(eric)

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.

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!

Flags: needinfo?(dtownsend)

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

Flags: needinfo?(dtownsend)

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

Yes this looks much better.

Pushed by nchevobbe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/607e46906b3e
Don't focus ConfirmDialog when displaying it. r=Honza
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 70
Assignee: nobody → nchevobbe

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.

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.

You need to log in before you can comment on or make changes to this bug.