Closed Bug 552285 Opened 15 years ago Closed 14 years ago

onkeyup in a focused input text field disturbs location bar and search

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 551434

People

(Reporter: bugzilla, Assigned: enndeakin)

References

Details

(Keywords: regression, testcase, Whiteboard: [sg:low])

Attachments

(1 file, 1 obsolete file)

Sample HTML code to demonstrate the bug
1.00 KB, text/html
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729) After loading a page with <body onload="document.forms[0].username.focus()"> and <input type="text" name="username" onkeyup="if((event.which||event.keyCode)==13) this.form.submit(); return false"> then typing an address into the location bar (or text into the search bar) and pressing the enter key, the form action is performed instead of loading the requested URL or performing the requested search. Reproducible: Always Steps to Reproduce: 1. Load the attachment file sample.html with FF 3.6 2. Immediately click into the location bar and enter an URL or click into the search bar and enter search text 3. Press the enter key Actual Results: The form action of sample.html is performed. Expected Results: The requested URL should be loaded or the requested search should be performed.
Version: unspecified → 3.6 Branch
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.2pre) Gecko/20100313 Namoroka/3.6.2pre Confirmed, if I enter www.cnn.com. But not if I enter www.nu.nl. :) It seems a regression from Firefox 3.5.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, regressionwindow-wanted, testcase
Yep, my suspicion is probably correct; regression from Bug 178324.
Blocks: 178324
blocking2.0: --- → ?
status1.9.2: --- → ?
Keywords: regressionwindow-wanted
blocking1.9.2: --- → ?
status1.9.2: ? → ---
Not super common, but we should fix it. Neil, can you please take a look and nominate a patch for branch landing?
blocking1.9.2: ? → -
status1.9.2: --- → wanted
Attached file testcase (obsolete) —
This is focus issue Bug 551434 - Toolbar search (search bar / keywords) work not in selected engine but in active page
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Sorry spam
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Renominating - this is now happening on a couple of sites, leading to pretty confusing behaviour :/ (I regret my original decision in comment 5)
blocking1.9.2: - → ?
The issue happens http://www.google.co.jp/firefox also. http://www.google.co.jp/firefox is default search engine of japanese edition of Firefox. [STR] 1. open http://www.google.co.jp/firefox 2.Focus location bar by Ctrl+L 3.Keydown ENTER and hold for several seconds 4.And keyup [Actual] http://www.google.co.jp/webhp?hl=ja&source=hp&lr=&btnG=Google+%E6%A4%9C%E7%B4%A2 will be loaded [Expected] stay http://www.google.co.jp/firefox
blocking1.9.2: ? → .6+
Whiteboard: [sg:low]
Component: Location Bar → DOM: Events
Product: Firefox → Core
QA Contact: location.bar → events
Version: 3.6 Branch → unspecified
I suppose if focus changes during a key event, the later key events will get fired at whatever is now focused. Perhaps there is a simple way to ensure that they fire at the same element.
We're not going to block on this for Firefox 3.6.6 as it is sg:low, though it does have some dupes. It'd still be good to get a fix for a later update though.
blocking1.9.2: .6+ → needed
Christian: if I tell you that it breaks google.co.jp (see comment 12) do you think that'd change the blocking decision? Enn: any thoughts on how long it would take to work up a fix?
blocking1.9.2: needed → ?
I don't know, it doesn't really look like it "breaks" google.co.jp: 1. The page by default focuses the search box. So if you just start typing and press enter the behavior is correct 2. Pressing ctrl+L and then tapping enter brings you back to the same page and focuses the search box, so behavior is correct 3. If you do ctrl+L and the hold enter (as in comment 12), it does switch the page but as far as I know the new page is still google, localized, and has the search box focused. Not ideal, but not horrible. Perhaps I am missing something that increases impact?
The LinkedIn case is pretty bad. 1. Go to LinkedIn 2. Login 3. Enter a new URL in the location bar or a term in the search bar and hit enter expected: navigation or search actual: linkedIn search results page (One of the duplicate bugs covers this case)
In my opinion, the question ist not "does it break google.co.jp?", but "should ff behave this way?". I don't think so. If one loads a page with an input form (focus in an input field) and after that, one types text in the location bar or the search field, one expects FF to load the requested page or search for the requested term and NOT to process the input form of the actual loaded page. Before FF 3.6 that worked as expected, this is a regression. Try my sample code on FF 3.5.x and 3.6.x and you will agree. Please fix this, e.g. in our company we cannot upgrade to 3.6 until.
Attachment #450844 - Attachment is obsolete: true
Of course I want this fixed, I'm just saying we likely won't block 3.6.6 on it because: * There is no patch with no ETA * We already shipped 4 releases with this regression * 3.6.6 code freeze is today * QA is already overloaded for 3.6.6 If a safe, safe patch comes in after code freeze we can reevaluate then, otherwise we'll push to get this in 3.6.7.
Neil, please take a look or find an appropriate new owner (not nobody) for this regression
Assignee: nobody → enndeakin
blocking1.9.2: ? → needed
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → DUPLICATE
blocking1.9.2: needed → ---
status1.9.2: wanted → ---
blocking2.0: ? → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: