212907 - don't pop up auto-complete menu on paste

Status: RESOLVED DUPLICATE of bug 79069

(SeaMonkey :: Autocomplete, defect)

Description

[Jamie Zawinski]

Here's what happens:

  1: I select the text of a URL in another window
  2: I create a new Mozilla window
  3: I middle-click in the URL field
  4: I hit RET
  5: I am sent to a Google search for that URL, instead of to 
     the URL itself

This is because, after step 3, the menu popped down with only
a single entry on it, "search Google for ________", and the RET
causes that to be selected.

This only happens if the URL in question is not in your history
already -- if it is, then the contents of the menu is different.

I'm pretty sure this only started happening with Mozilla 1.4 --
I don't recall randomly finding myself on Google with 1.3.


Mozilla 1.4
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701

Comment 1

[Jesse Ruderman]

Why would hitting RET select an autocomplete menu item?  Did you have your mouse
over the autocomplete menu?

Comment 2

[Jamie Zawinski]

You know, it's possible that my mouse might have slipped down a few pixels and
been over the "Search" item on the menu by the time I hit return.

But this is just another example of the keyboard handling of this goofy
autocomplete menu.  Hitting RET should not select from that menu.  Do this:

    - type "foo" in the URL bar
    - click somewhere else to dismiss the menu
    - focus on some other program
    - bring focus back to Mozilla by clicking elsewhere in the window
    - hit RET
    - Mozilla tries to load "foo.com", since it accepted the RET as
      text-field confirmation, since its internal focus was pointed at
      the text field.

THAT is the expected behavior: nobody expects to be in some crazy point-to-type
focus mode when typing URLs into the URL bar.

It's simple: this thing should *not* behave like a normal combo-box!  This thing
is a goofy completion accessory bolted onto the side of a text field.  It's not
a "real" option menu or combo box.  It's more like a tooltip.  Users expect all
text-field keybindings to do the usual text-field thing.  You're letting menu
keybindings override the text-field keybindings and that's insane.  This is the
fundamental problem with bug 109758 too.  

Should hitting RET when over an HREF dismiss the tooltip?  Of course not.

If I could get tab-completion without having the damned menu pop up at all, I'd
do that.

Comment 3

[Jesse Ruderman]

I think you meant "yes" by the parts of that 7-paragraph comment that were
on-topic.  Do you agree that this is a dup of bug 79069, "Enter key should only
go to selected autocomplete item if keyboard was used to select item"?

Comment 4

[Jamie Zawinski]

No, if I'm correctly interpreting what hewitt wrote in bug 79069, I don't think
this is a dup of that.

He seems to be saying "the RET key is sometimes interpreted by the menu and
sometimes not, and should always be interpreted by the menu when the mouse is
over the menu."

That's not what I'm saying here.  What I'm saying is, "the menu should never
interpret keystrokes ever, they should only be interpreted by the text area."


I'm sorry you seem to think it's "off topic" of me to try and explain the wrong
behavior that I'm seeing, and what the right behavior would be.

Comment 5

[Jesse Ruderman]

Hewitt didn't write anything in bug 79069.  The reporter ([e-mail])
seems to be saying "the RET key is sometimes interpreted by the menu and
sometimes not, and only be interpreted by the menu if you used the keyboard to
select an item in the menu" (which is the opposite of your interpretation). 
Unless you're opposed to being able to use the down arrow key to select
autocomplete entries, this is a dup of bug 79069.

Comment 6

[Tony Mechelynck [:tonymec]]

No rebuttal to comment #5 in 4½ years -- setting dupe as per that comment.