To be clear, the distinction is that basically space is "activate focused element" and you want enter to be "activate default dialog action, ignoring focused element"?

If we did this, would we want enter to behave like space if there were no "default dialog action" (e.g. the bookmark bubble had no "done" button)?

No, I just think the combobox shouldn't handle Enter/Return (at least on Windows).
If there were no default 'done' button, the key would no-op on a closed combobox.

Native Windows comboboxes differ here (based on GDI/WPF?)... So it's a toss up.
(NO-OP: Control Panel->Personalization->Change screen saver->"Screen saver" type)
(OPENS: Win10 Settings App->Personalization->Background->"Background" type)

Hmm.  I kinda think the enter-does-something behavior is intuitive and generally better than doing nothing, but it's worse for you in this specific use case because of its convenience, when unmapped from the combobox, to trigger a non-focused element.  I mean, if we made enter do nothing _at all_ in this dialog, rather than making it activate the dropdown, I struggle to think you'd find that a win.

GDI/WPF may indeed be the source of the native control behavior difference, which would suggest Microsoft is moving in the direction of having enter activate these.

My inclination would be to hem and haw a bunch and then close WontFix, but I don't feel confident.  *hems*  *haws*

Sure, no-op enter is lame, but enter-to-accept-bubble/dialog is nice.
As a heavy bookmark user, I liked CTRL+D, Tab, "FolderPrefix", Enter.
Now I have to do something like CTRL+D, Tab, "FolderPrefix", then:
1) Hit Tab three more times to focus Done, then Enter.
2) Hit Shift-Tab to focus the textfield, then Enter (for the enter-to-accept behavior).
3) Reaching for the mouse.
I wonder if Enter to accept makes sense if we only do it for some controls...

But, given the GDI->WPF trend, and most users probably don't heavily bookmark via keyboard, I'm willing to concede this.
I just think it was changed without considering this use case.

I think we definitely didn't consider this use case.

I think it would probably be better to have enter never handled by comboboxes than handled by some and not others.  So I wouldn't do something like, make enter trigger comboboxes only if the view is inside some kind of a dialog with a default button.  But this also implies that enter shouldn't trigger comboboxes in Blink yet not here.  So I think if we wanted to make enter not trigger these, we'd want to make that change in web content as well.  I don't know what sorts of ramifications that would have.

luckily since we changed the meaning of escape you can do

Ctrl+D, tab, "FolderPrefix", Escape

:)

That's true, I'll try using Esc for a while to accept/close bookmark bubbles.

Feel free to retarget this bug if we don't want Enter to (sometimes) accept dialogs.
Otherwise, Feel free to WontFix this bug if we do want Enter to open comboboxes.

I don't know if I feel empowered to speak for "we", but I do think current behavior is good. The good thing about WontFix'ing is that it's a reversible action, so I'll go ahead and take the plunge.