9903 - Hasty "File->Open Web Location..." behavior

Status: VERIFIED DUPLICATE of bug 22782

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Crysgem]

Apprunner Build ID: 1999070614 (July 14 build, in truth: but that's a seperate
bug)

Follow the Method of Reproduction precisely, or the fellow-tester may find that
midwifing this bug is difficult.

0) Execute Apprunner, load any URL.
1) Await the completed loading of the page (throbber must be still!)
2) Type a new URL in the Address field, but DO NOT load the new URL (refrain
from striking Enter, as yet)
3) Pardon my PC mannerisms... strike [Alt], then [F]... scroll with the arrow
keys to "Open File or Location...", strike Enter.
4) Observe with astonishment (aye, grasshopper, this too is a necessary step) as
the beast loads the URL entered in the Address field, without so much as a "By
your leave..." or any actual input to the "Open File..." dialog.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

[e-mail]: What happens if you select another menu item using the
keyboard (other than Open File or Location)?  Does it still load the URL?

Comment 2

[Crysgem]

I cannot alas test this bug until the menu options respond to the keyboard  >:+) (see Bug 10487)

Comment 3

[Crysgem]

As I am able to test as of the 1999080312 Apprunner build, I can confirm that
the procedure as described will yet reveal the bug.

Comment 4

[Sean Richardson]

Cannot replicate with 1999-11-12-18-M11 on Windows NT,
but that is probably because the "Open File or Location..."
menu item no longer exists as such.

Followed the instructions *to the letter*, except for using
"Open Web Location" in step 3 in place of "Open File or Location..."

Tested with: 1999-11-12-18-M11 nightly binary on Windows NT 4.0sp3

Comment 5

[Sean Richardson]

It's back.  Following the original instructions with the exception of
substituting the "Open Web Location..." item for the no-longer-existing
"Open File or Location..." the page specified in the Location Bar loaded
(and the dialog remained on top).

Tested with: 1999-12-12-08-M12 nightly binary on WinNT 4.0sp3

Substituting name of menu item for dialog in summary.

Comment 6

[joki (gone)]

I realize I'm duping this on a much newer bug but it has a really good 
description on it.

*** This bug has been marked as a duplicate of 22782 ***

Comment 7

[Asa Dotzler [:asa]]

Verified duplicate of 22782.  keyboard events should only hit the current 
focused object.