As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 543204 - iframe.find() focuses iframe in Firefox 3.6
: iframe.find() focuses iframe in Firefox 3.6
Status: NEW
: testcase
Product: Core
Classification: Components
Component: General (show other bugs)
: Trunk
: x86 Windows XP
: -- major with 16 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on:
  Show dependency treegraph
Reported: 2010-01-30 05:47 PST by Cacycle
Modified: 2013-08-06 06:39 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Testcase (435 bytes, text/html)
2010-01-30 05:49 PST, Cacycle
no flags Details

Description User image Cacycle 2010-01-30 05:47:18 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; 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; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)

In Firefox 3.6, but not in previous Firefox versions and not in other browsers (Chrome, Safari), the find function on an iframe in designmode gives focus to the iframe.

Reproducible: Always

Steps to Reproduce:
1. Open attached testcase
2. start typing in the input box
3. onkeyup triggers iframe.find()
Actual Results:  
In Firefox 3.6, the focus shifts from the input field to the iframe

Expected Results:  
All Firefox < 3.6 and all Chrome and Safari versions do not focus the found text in the iframe but instead keep the focus on the input field.

This breaks the Wikipedia editor wikEd where it makes the find ahead search function unusable. Here is a workaround for Firefox 3.6:

var inputFieldSelectionStart = inputField.selectionStart;
var inputFieldSelectionEnd = inputField.selectionEnd;
(run iframe find);
inputField.setSelectionRange(inputFieldSelectionStart, inputFieldSelectionEnd);
Comment 1 User image Cacycle 2010-01-30 05:49:17 PST
Created attachment 424399 [details]
Comment 2 User image Ria Klaassen (not reading all bugmail) 2010-01-30 10:04:38 PST
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20100130 Minefield/3.7a1pre

Your testcase works fine for me; focus stays in input field. Maybe an add-on is triggering this? Do you see the same in safe-mode / with a new profile?
Comment 3 User image Tim (fmdeveloper) 2010-01-30 11:33:58 PST
I see the issue with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729) ID:20100115144158

This is only triggered if you type a character that exists in the iframe.

Steps to Reproduce:
1. Open attached testcase
2. Type an 'a' in the input text box
3. onkeyup triggers iframe.find()

Focus jumps to iframe
Comment 4 User image Cacycle 2010-01-30 11:39:43 PST
Problem persists with Minefield/3.7a1pre in safe mode. Also, several users of the Wikipedia editor wikEd have complained about this under 3.6.
Comment 5 User image Boris Zbarsky [:bz] (still a bit busy) 2010-04-09 22:30:43 PDT
This has nothing to do with form submission, and might not even be in core code (might be the toolkit find impl involved here).
Comment 6 User image Tim (fmdeveloper) 2011-08-27 17:12:41 PDT
Confirmed still an issue on Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110827 Firefox/9.0a1 ID:20110827030801
Comment 7 User image Simona B [:simonab ] 2013-08-06 06:39:57 PDT
Mozilla/5.0 (Windows NT 5.1; rv:25.0) Gecko/20100101 Firefox/25.0
Build ID: 20130805030205

The issue is still reproducible on the latest Nightly (not reproducible on Chrome 28.0.1500.72 m).

Removing the qawanted keyword since it didn't came with any specific requests. Please re-add it if anything specific is needed from the QA side.

Note You need to log in before you can comment on or make changes to this bug.