I have the same problem

This is also there in settings editor

Assigning to @roblourens since this is a bug in Suggest enabled input.

I'm not sure about the freeze, I don't repro that. But @jrieken can you just make sure that peek command won't show up in the simple editor input? I changed the Command Palette one to have when: EditorContextKeys.editorSimpleInput.toNegated(). You can add that or it looks like other peek menu registrations have some conditions on when they are valid.

Hm, this must be a regression from @joaomoreno's submenu changes as the Peek-menu is quite old already. Will look into a fix, also marking as candidate

I have pushed a change so that the sub menu doesn't show anymore. Tho, I cannot reproduce the freeze. Not on mac nor on windows. I wonder if that's related to the welcome page not showing recent entries... Can you try without the welcome page or with a different workspace?

Adding @sbatten for more insights and FYI. You might know more about the crash potential - it seems that sometimes the Peek menu doesn't expand and than the crash happens. In my testing (win/mac) I wasn't able to repro and got the menu with a single, disabled entry

@jrieken That is the cause, You need to right click then quickly left click as if you're trying to get the peek to show with a left click; don't wait for the peak to show. I just realized that was the exact step to reproduce the error.

By clicking before the menu shows I can repo it 100% of the time, unless I am slow clicking.

Yep, It doesn't have to be from the search bar, it can be anywhere.

Not sure if this is it, but seems to be it.

from https://github.com/microsoft/vscode/blob/master/src/vs/editor/contrib/peekView/peekView.ts

protected _onTitleClick(event: IMouseEvent): void {
		// implement me
	}

Thanks @topherhoffman 👏 Once I am fast enough I can reproduce. There is an endless loop creating the submenu and trying to focus an item. Not quite sure why this only happens when being fast...

I believe this was introduced via 182db07 because it adds the preventLoopNavigation which weakens the only loop abort condition. That you have to be fast is because 250ms after hovering an element is focused (via a different code path) and you need to click fast than that.

I have cherry-picked my commit fa4ee50 onto the release branch which should make this not happen anymore - tho the underlying issue and the potential for this endless loop remains

Thanks for cherry picking. Due to that closing this issue so we get it verified for the release.
As for the underlying issue and endless loop potential I suggest that either you or @sbatten create a new issue.

To verify:

• open extensions viewlet (alternatively SCM or settings editor)
• right click into the editor/input
• make sure that there is no peek menu