Closed Bug 258285 Opened 20 years ago Closed 19 years ago

Find Toolbar sometimes appears (pops up) when typing/entering arbitrary characters in textareas/form input fields, FAYT (find as you type) activated

Categories

(Toolkit :: Find Toolbar, defect)

Product:
Toolkit
Component:
Find Toolbar
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.8final

People

(Reporter: Maniac, Assigned: aaronlev)

References

(Depends on 1 open bug)

Details

(Keywords: fixed1.8, testcase, Whiteboard: Read Comment #145 and #164 before commenting any further)

Attachments

(11 files, 3 obsolete files)

Example of page that this bug occurs on
3.59 KB, text/html
Details
minimized test case
2.16 KB, text/html
Details
test case with more pass/fail cases
3.69 KB, text/html
Details
interesting focus break in the testcase - blue border means :focus
8.16 KB, image/png
Details
Tiny testcase, that causes FAYT -- the patch doesn't fix this version of the problem
255 bytes, text/html
Details
Linux only testcase
481 bytes, text/html
Details
A little bit better -- fixes Linux testcase. Also removes som old needed code.
14.95 KB, patch
Details | Diff | Splinter Review
Actually remove SetSuppressFocus() calls from SendFocusBlur(), which only cause problems and no longer are needed for the fix they were orignally added for
10.65 KB, patch
MatsPalmgren_bugz
: review+
bryner
: superreview+
asa
: approval1.8b4+
Details | Diff | Splinter Review
Linux testcase - with logging
1.42 KB, text/html
Details
trace - fastback OFF (for the "Linux testcase")
7.31 KB, text/plain
Details
trace - fastback ON (for the "Linux testcase")
7.36 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040905 Firefox/1.0 PR (NOT FINAL)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040905 Firefox/1.0 PR (NOT FINAL)

This one is realy hard to reproduce :-(. It happens during normal browsing
process with no apparent special actions that could cause the bug.

It occurs sometimes, mostly when I browse our corporate Bugzilla installation
when I open just another regular window. I enter characters in an input field.
first character is accepted but then Find Toolbar activates and steals focus
from the field. You can close it and try to continue typing but after the next
one it appears again and steals focus (I guess I can even hear it saying: 'You
don't think it should be easy, dont't you?').
Some additional notes:
- FT's field retains all previous characters and appends new ones.
- FT's field is red as if the word is not found on a page (which is correct). I
think it's an evidence that FT actually searchs the word.

Also I'm not at all certain, but I beleive that this appears on those windows
that fail to focus the location field on opening (may be there's another bug for
it).

Reproducible: Sometimes
Steps to Reproduce:
Ah... I suddenly found a way to reproduce. It involves the extension
'RadialContext' (http://www.radialthinking.de/radialcontext/). These are _exact_
steps (including cursing :-) ):

1. Create a simple testcase, store it to an HTML file on disk:

<html>
<body>
  <input type=text>
</body>
</html>

2. Install RadialContext (if not installed), restart FireFox
3. Make 'Blank Page the homepage for new windows
4. Open new window with RadialContext (gesture upper-left, up)
5. Start typing address of the test file in the new window, without clicking
anywhere.
6. Find Toolbar activates and searches your typed URL since location toolbar is
not focused.
7. Loudly say something you use to say in cases like this. Hit 'Esc' to hide
Find Toolbar.
8. Hit Ctrl+L to focus Location Bar and type the URL of the test file (like
'file:///C:/....', hit 'Enter'.
9. After test file loads, use 'Tab' to focus the only <input> in the content window.
10. Now start typing something and watch the effect described in bug.

So, this may be a bug in the extension, not in FireFox. But I believe that mere
ability of this behaviour - activating FT when focus is inside the input field -
is not right.

I shall email Jens Tinz, author of RadialContext, about this bug. May be he
could help here.
Note:

Here is the function RadialContext uses to create a new window:

	newWindow : function() {	
		var url= "";
		var prefs=
Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefService).getBranch("");
		if(prefs.getIntPref("browser.startup.page")== 1)
			url= prefs.getCharPref("browser.startup.homepage");

		window.open(url); 
	},
(In reply to comment #2)
> Note:
> 
> Here is the function RadialContext uses to create a new window:
> 
> 	newWindow : function() {	
> 		var url= "";
> 		var prefs=
>
Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefService).getBranch("");
> 		if(prefs.getIntPref("browser.startup.page")== 1)
> 			url= prefs.getCharPref("browser.startup.homepage");
> 
> 		window.open(url); 
> 	},

Yep, I saw this in rcFunctions.js and, thinking that evil could be related to
Javascript's way of opening new windows tried to synthesize a testcase:

<html>
<body>
  <input type=text>
  <button onclick="window.open('');">New Window</button>
</body>
</html>

But this didn't work. After focusing Location Bar, loading same file and typing
into the input Find Toolbar didn't appear. May the bug appear due to the way
that the extension cancels standard chrome context menu? May be this is some
focusing problems (just peeking ideas from the top of my head)?
I believe that this might also have something to do with, or be reproducable
with, frames.

Attaching a file which reproduces the problem, however it only appears to
reproduce when it is inside a frame.

The attached file is the "URL Upload" form from the Gallery
(http://gallery.menalto.com) product.  This page is loaded inside a very simple
frameset (one full-browser frame, one hidden, empty frame)
I also started seeing this bug since upgrading to Firefox 0.10PR, and as Ivan
reported, it's hard to reproduce.  I just visited the example site listed in
this report as an attachment and did not see the bug.

When the bug manifests, I see the exact same behavior that Ivan cites: being
able to enter one character into a text box, after which FAYT traps subsequent
characters.  Refocusing on the text box allows entering one more character
before FAYT triggers again.

FWIW, I do not have extension RadialContext installed. 
I've also run into this problem with Firefox 1.0PR.  I haven't been able to find
a consistent reproducable test case, but it regularly manifests itself and
forces a restart of firefox.  I am seeing this on a RH linux system, so it is
not Windows specific.  The behavior is obviously more than just an annoyance,
because when it begins, you can't enter anything into any input field containing
a " ' " or " / ", and you must then restart Firefox to finish filling in the form.

> When the bug manifests, I see the exact same behavior that Ivan cites: being
> able to enter one character into a text box, after which FAYT traps subsequent
> characters.  Refocusing on the text box allows entering one more character
> before FAYT triggers again.

Exactly the same behavior noted here.

> FWIW, I do not have extension RadialContext installed. 

Nor do I.

*** Bug 260461 has been marked as a duplicate of this bug. ***
> and you must then restart Firefox to finish filling in the form.

For me restarting is not required. The buggy behavior is only present in one
window and opening new window helps. Could try this also when you next time
encounter it?
I just had this bug manifest again, ironically enough while using the bugzilla
search page to find this page to see if any new comments had been filed.  I had
to turn off FAYT to be able to enter text into the comment field here. 

While the problem behavior was active, it remained in effect in different text
fields on a given page, and across new tabs opened at random; it seemed like
once it was triggered, any text field exhibited the problem. (Perhaps that's the
wrong way to look at it.  Once FAYT was triggered, the behavior is in effect no
matter where you move the focus).

I *think* I've got another clue.  My fingers slipped while typing the search
string that seemed to trigger the bug and some random characters got typed
almost simultaneously (sort of a finger-mash event).  I think one of them was a
forward slash...which maybe triggered FAYT while focused in a text box.  

This would be a minor bug in handling of text fields if there was a way to get
out of FAYT mode, but closing the toolbar or hitting esc didn't cancel the mode
- you could type a single character into a text box and then FAYT triggers again
with no apparent way out other than relaunching FF.

I was able to get the same behavior once by intentionally typing a forward slash
in a text box, but I can't seem to reproduce this now: //// - worked just fine,
 even though I have re-enabled find as you type in advanced options.  

Bottom line: still not reproducable, but I'm wondering if anyone else observing
this bug could have accidentally hit one of the FAYT trigger keys just before it
manifests?
This bug occured for me on the check out page at mcmaster.com. The only way to
enter text in a box was to shut off FAYT. I'm not sure what happens if you need
to enter a forward slash in the text box with FAYT shut off, but I will check
next time I'm placing an order.
I can consistently reproduce this bug in the 'rename' and 'properties' windows
of the Gallery application (gallery.sourceforge.net).
I'm seeing a similar (but perhaps not identical bug). Sometimes, when I type a '
or / in a text area, it brings up the Find Toolbar. In fact, it's doing it right
now. I can type other characters with no problem.

I've also noticed that when this bug manifests, the arrow keys, page up, page
down, etc no longer work for navigation in the text area.

I don't have RadialContext installed.


I also had this bug, where the find as you type feature was stealing the focus
from text entry areas on web forms. I have never installed or used "radial
context" so I know it's not related to that extension.

The good news is that I haven't had this bug at all for the last few days. I'm
wondering if maybe the bug is related to Tabbrowser Extensions - because I also
updated this extension recently.
Exactly the same situation here.
Linux/Firefox1.0PR 
This problem didn't occured in the previous realease.

I checked before posting here: I restart Firefox when I have this issue and load
a page on which I had the issue, to see if it occurs again, and it doesn't.
So I guess sometime in the browser session, something, which I can't pin point
now, happens and triggers this behaviour. But it's not permanent.
Though it's annoying like hell when it happens.
I don't have RadialContext nor TabExtensions (or what was that), though I have
couple other extensions. I guess that rules out those two extensions for this
behaviour.
My 2 cents is that there must be something going bad with the new search bar.
There is also a privacy/security issue because password input box will fill in
as the user types in the password. Someone looking at the screen would be able
to see the plain text password. (The password input still gets filled in
correctly with *'s) At least when this happened to me, I was able to type
without having to close the fayt toolbar.
Flags: blocking-aviary1.0?
*** Bug 260398 has been marked as a duplicate of this bug. ***
*** Bug 264671 has been marked as a duplicate of this bug. ***
*** Bug 259867 has been marked as a duplicate of this bug. ***
I've started to experience this happening while using phpMyAdmin, when I press
either the / or the ' keys. I can reproduce it in that tab (two tabs over in the
same window) but not in this tab as I enter the bug.

I'm using debian-experimental, so the OS of this bug should probably be changed
to 'All' (I can't do it as I'm not the owner of the bug.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Summary: Find Toolbar _sometimes_ pops up when entering characters in input fields, FAYT activated → Find Toolbar _sometimes_ pops up when entering ' or / in input fields, FAYT activated
*** Bug 264876 has been marked as a duplicate of this bug. ***
Please, Jesse, don't change the summary. It's another bug. This bug is about
popping up of toolbar on arbitrary character. I'm now conducting experiments
with JS code opening new window, preventing default event handlers etc. Looks
like this bug caused by some focusing misshifts... I'll sum up my results later.

Attention everyone seeing this only on ' and / and in other _tabs_, not windows,
this is likely to be another issue. Jesse would you file a new bug?
Summary: Find Toolbar _sometimes_ pops up when entering ' or / in input fields, FAYT activated → Find Toolbar _sometimes_ pops up when entering arbitrary characters in input fields, FAYT activated
Ok.  I reopened bug 264876.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041018 Firefox/1.0

This is becoming really annoying, it happens to me 2 times in the last 10
minutes on two different websites (including mozillazine). This is annoying
because FF has to be closed, even copy/paste does not work anymore. I don't know
what is causing this...
In fact i've found a workaround to this bug. If buggy behavior appears in a new
window it helps switching to previous one with a mouse click and returning to
the new one also with mouse click.

If this doesn't help then it may be another issue.
(In reply to comment #23)
> 
> ... even copy/paste does not work anymore. I don't know
> what is causing this...

it helps sometimes if you open Help/about and close it again to get copy/paste
working again


This bug and bug 264876 sound like focus issues to me.
re comment #21.  I would be careful in assuming that the case of people seeing
it with ' and / only and those seeing it with arbitrary characters are
definitely different issues.  It is possible that those seeing it only with '
and / have accessibility.typeaheadfind set to false and those who see it on
arbitrary characters have it set true.
(In reply to comment #27)
> re comment #21.  I would be careful in assuming that the case of people seeing
> it with ' and / only and those seeing it with arbitrary characters are
> definitely different issues. 

I'm not assuming them as such. True, they could be the same issues as well. But
resolving as duplicate means that these are definitely the same issues which I'm
not certain either.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0

After a long discussion with W. Gianopoulos on mozillazine, I search the source
of this bug and I found what is exactly causing it in my case: a little program
named TrayIt! that minimizes any window to the system tray when you right-click
on the close button of the window (It is located here:
http://www.teamcti.com/trayit/trayit.htm). I don't know how it exactly works,
but I think it simply sends a SW_HIDE message to the associated window procedure
of the window and add an icon in the system tray. When you double-click on the
icon, it certainly removes it from the system tray and sends a SW_SHOW to the
window procedure.

Here are the steps to reproduce:
1. Download and launch TrayIt!
2. Launch firefox and go to a website with a text area (www.spreadfirefox.com
for example)
3. Try to type /test in a text area, it should correctly work
4. Right-click on the close button to minimize the window to the system tray
4. Double-click on the system tray icon to restore the window
5. Reload the page
6. Type /test in a text area

What happens? Find toolbar pops up and always steals the focus. I tested it with
a new profile and no extension (So in my case, this is not linked to RadialContext).

I saw this bug many times because I am used to keep firefox opened, I just
minimize it to the system tray to keep some space in the taskbar.

Perhaps is it linked to #264876: Depending on how FAYT is set, the find toolbar
pops up with the same conditions chosen in 'Tools -> Options -> Advanced ->
Accessibility'. If automatic mode is chosen, it will pop up on any character,
otherwise it will pop up on / or ' characters.

I don't know if it will be considered as a FF bug, but it surely does something
wrong at one time or another.

Sorry for the size of this comment, I hope it will be useful.
> http://www.teamcti.com/trayit/trayit.htm). I don't know how it exactly works,
> but I think it simply sends a SW_HIDE message to the associated window procedure
> of the window and add an icon in the system tray. When you double-click on the
> icon, it certainly removes it from the system tray and sends a SW_SHOW to the
> window procedure.

Ah... This looks pretty reasonable. My assumption (though may be lame) is that
Firefox's window come up and become active and focused in some way that doesn't
make Find Toolbar beleive that some input field in this window is focused. So it
starts catching characters causing this bug. As far as I remember from my Win32
API experience there are more than one way concept of active/focused window but
I don't remember exactly.

Francois, could you try a workaround I mentioned earlier? E.g. open another
window and switching with a mouse to it and back to affected window. Does it
clear the buggy behavior?
Yes that works. It's not very handy but at least I don't have to close the
window and all its tabs.
Hellooooooo??
I thought I HAD SAID I am using Firefox 1.0PR ON _LINUX_?!!?!
So I do not think (duh) it has to do anything at all with any Win32 API. 
Please someone change the target OS to All?!
the issue applies the mac port as well
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 266739 has been marked as a duplicate of this bug. ***
*** Bug 266775 has been marked as a duplicate of this bug. ***
I've gotten this bug a number of times on Firefox 1.0PR, Windows XP SP2, no
extensions.  I actually got it on Google once.  Is there any chance we can put a
blocking-aviary1.0? flag on this?
It has already been set as -, so if nobody comes with a patch, it will certainly
be in 1.0
I can report having had this problem at least from 1.0PR till 1.0RC2 (latest
version at the moment).
It is always reproducable with my gallery v1.4.1 in the 'add photos' popup in
the 'Or, upload any images found at this location..' text field. Since that
album is not public I won't provide a link to it, but this may help a bit.

> It is always reproducable with my gallery v1.4.1 in the 'add photos' popup in
> the 'Or, upload any images found at this location..' text field. Since that
> album is not public I won't provide a link to it, but this may help a bit.

Is it possible to strip the code opening popup to some minimal testcase which
would always show a bug? 
*** Bug 262187 has been marked as a duplicate of this bug. ***
The weird thing is, that when the page (that I was refering to in my previous
message) is a pop-up, the behaviour is present (find toolbar appearing). 
But when I open that exact same page in a normal window the behaviour is NOT
present. Does this make any sense?
If this does not help I'll try to create an example page. Let me know.
I've seen this happen when typing into bugzilla comment boxes (like this one,
although it didn't happen on this occasion)
I have experienced the same behaviour with Firefox(Debian official package
0.99+1.0RC1-4). I was thinking it was Debian specific but this bug listing tells
me that other people have seen this in Mozilla.org's official builds also. The
only problem for me has been inability to reproduce this bug at will. And I
haven't been able to reproduce the behaviour in the Moz.org's official 1.o build
yet.
This bug is still present in version 1.0 final.
That's why I've created an example page where the bug behaviour is reproducable.

Visit:
http://www.rolo.dds.nl/firefox/index.html

Regards, Roald
(In reply to comment #44)
> This bug is still present in version 1.0 final.
> That's why I've created an example page where the bug behaviour is reproducable.

I can confirm this bug using your example for Firefox 1.0 PR. But reloading the
popup didn't always fix the focus problem. First time it did, second time it didn't.
(In reply to comment #44)
> This bug is still present in version 1.0 final.
> That's why I've created an example page where the bug behaviour is reproducable.
> ( http://www.rolo.dds.nl/firefox/index.html )

Can't reproduce this bug with your example page using Firefix 1.0 [Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0]
 


(In reply to comment #45)

> Can't reproduce this bug with your example page using Firefix 1.0 [Mozilla/5.0
> (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0]

I am also unable to reproduce the bug with that page (v1.0 on WinXP), although I
encountered this bug for the first time yesterday while on the Mozillazine
forums.  I was simultaneously looking for updates to extensions by
double-clicking the update icon in the toolbar, and that was running in the
background window.  The bug went away after I closed the background window. 
This may have been coincidental.
(In reply to comment #44)
> This bug is still present in version 1.0 final.
> That's why I've created an example page where the bug behaviour is reproducable.
> 
> Visit:
> http://www.rolo.dds.nl/firefox/index.html
> 
> Regards, Roald

Confirming on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0 at this URL.
I confirm that I can reproduce the problem with the test case at
http://www.rolo.dds.nl/firefox/index.html

My info:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
on Win XP Pro SP2.
extensions installed:
Live HTTP Headers, DOM inspector (from installer).

As I just installed the 1.0 release from a clean profile (I deleted my profile
folder after uninstalling 1.0pre1) I know what options I changed:
I only enabled the "Begin finding when you begin typing" option.

A few things about this bug:
* When the bug is triggered, clicking on different fields in the window won't
fix it: the find will always steal focus.
* When the bug is triggered, switching to an other window (firefox or not) and
back (with the mouse or keyboard shortcut), will make things work normally (as
in: find doesn't trigger in an edit text).
* If I start typing in an edit text, regardless of what I type, the find toolbar
steals the focus (I don't need to start typing with / or ').
* If I start typing something that is not present in the page, for example try
typing "4qwerty", then the text appears both in the edit text and in the "find
toolbar". Hitting "backspace" will only delete characters in the "find toolbar",
not in the edit text.

Besides find stealing focus, once the bug is triggered (I'm dealing with it as I
type this... each apostrophe is moving focus to the find toolbar) the cursor
edit keys no longer work in the textarea field.  Home, end, arrow keys,
shift-home, shift-end, etc. are all broken.  Backspace and delete continues to work.
*** Bug 269011 has been marked as a duplicate of this bug. ***
*** Bug 255286 has been marked as a duplicate of this bug. ***
*** Bug 269709 has been marked as a duplicate of this bug. ***
Hi!  I'm having this too.  Curiously, I was having it in THIS VERY WINDOW, while
browsing this bug!

As with other people, I can sometimes get it to go away by giving focus to a
text entry field.  For me, the trigger character is '.

Note that it happens a lot on text entry fields on vBulletin sites, for me...
Which is INCREDIBLY frustrating.

I have FAYT off, and I have never turned it on, nor will I ever, because I find
the feature lathesome and hateful.  :)

I am using FireFox 1.0, and I also had this problem with 1.0PR.  In both cases,
running under Windows XP Pro.
Ooh, another data point:  When this is happening, arrow keys are totally
ignored, even though the text entry field otherwise works.  Happening right now
on this page.  Can't navigate with arrow keys, and any apostrophe pops up FAYT.
*** Bug 271236 has been marked as a duplicate of this bug. ***
(In reply to comment #49)
> I confirm that I can reproduce the problem with the test case at
> http://www.rolo.dds.nl/firefox/index.html
> 

this "test case" doesn't reproduce the problem for me (WinXP, Firefox 1.0, TBE,
Adblock, and more extensions). At least not today. But I have experienced the
bug at seemingly random times on random pages, and without typing a / or ' to
trigger FAYT. Also, I don't have "tray-it", so I don't think that program is the
cause. At least not on my computer.
> this "test case" doesn't reproduce the problem for me (WinXP, Firefox 1.0, TBE,
> Adblock, and more extensions). At least not today.

I just tried the so-called "test case" with Adblock disabled - but the bug was
still not triggered.
*** Bug 274108 has been marked as a duplicate of this bug. ***
The testcase does trigger the bug for me.  Is it true that no developers have
been able to repro this with the testcase?
I can confirm it on the testpage, again with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107
Firefox/1.0. I *do* have TrayIt, but it's occurring on my laptop too, which
doesn't have said application installed. Could be triggering something extra,
but it's not the main cause. It happens on all sorts of sites for me, usually at
least once or twice a day...
*** Bug 275767 has been marked as a duplicate of this bug. ***
Summary: Find Toolbar _sometimes_ pops up when entering arbitrary characters in input fields, FAYT activated → Find Toolbar sometimes pops up when entering arbitrary characters in form input fields, FAYT (find as you type) activated
(In reply to comment #44)
> This bug is still present in version 1.0 final.
> That's why I've created an example page where the bug behaviour is reproducable.
> 
> Visit:
> http://www.rolo.dds.nl/firefox/index.html
> 
> Regards, Roald

I am also seeing this with the test case.

One thing I noticed that has not been mentioned.  Once the "pop-up" is opened,
if you right-click and select "View Page Source" the bug is no longer present in
the pop-up.

1.  Open test case
2.  press / or ' in a text field ==> find bar opens, times out, and closes
3.  right-click in pop-up and select "view page source"
4.  again  press / or ' in a text field of the pop-up  ==> find bar does not open
> Visit:
> http://www.rolo.dds.nl/firefox/index.html

While investigating this bug, I also noticed that if you simply switch the focus
to the browser and then back to the pop-up window, the bug is not present.

1.  Open test case above
2.  press / or ' in a text field ==> find bar opens, times out, and closes
3.  click on the title bar of the browser page that opened the test case
4.  click on the title bar of the pop-up window
5.  again  press / or ' in a text field of the pop-up  ==> find bar does not open


I looked into the focus states involved in the bug:

  when bug is present (step 2 above):
  -----------------------------------
  document.commandDispatcher.focusedElement = null
  document.commandDispatcher.focusedWindow =  [object ChromeWindow] 
  window = [object ChromeWindow] 

  when bug is not present (step 5 above):
  -----------------------------------
  document.commandDispatcher.focusedElement = [object HTMLInputElement]
  document.commandDispatcher.focusedWindow =  [object Window] 
  window = [object ChromeWindow]


The reason the bug is present is the null .focusedElement state (needs to be
"[object HTMLInputElement]" to block FAYT from working).

I think this might be a sign of a bigger problem, since none of the elements in
the pop-up window seem to be focused.  For example, in state 2 above the arrow
keys have no effect on the cursor in a text field.  Also, any text copied in a
text box in this state results in an empty paste string.  Once you get to state
5 above, the arrow keys and copy command works correctly.

I just tried this in Mozilla 1.7.5 and am seeing some of the same issues.

There is no find bar, but the arrow keys do not move the cursor in the text
boxes unless you focus off the pop-up and then back on.
Attached file minimized test case — 
I have found that if I comnment out the
"document.forms.admin_options_form.admin_select.blur();" command in the test
case, the bug is no longer present.

I reduced the test case to two:
 - one with the blur() command which causes the bug
 - one without the blur() command which does not cause the bug

It seems the problem is if we blur something in the main browser after opening
a seperate window and click only on the pop-up _without_ first clicking on the
browser, the focus is not set correctly in the pop-up
I'm not able to repro' the bug with the last testcase.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041220
Firefox/1.0+
(In reply to comment #67)
> I'm not able to repro' the bug with the last testcase.
> 
> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041220
> Firefox/1.0+

Are you able to reproduce it in the original test case (i.e. comment 64)?

If so, then I am stuck.  I can reproduce the bug 100% of the time with the
reduced test case on my machine (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8a6) Gecko/20041203 Firefox/1.0+).

I know I saw some code that delt with focus issues on the Mac, maybe this is
only on Win machines?
This test case includes some more interesting Pass & Fail states.

It really looks like this is a timing issue with .blur().  If you use a
setTimeout  for the blur (i.e.
setTimeout('document.forms.dropdown.text.blur();', 0);), the bug is not
present.
I confirm that this last test case works exactly like specified:
the first 3 links trigger the bug while the 3 others don't.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

extensions installed: live http headers.
using setTimeout will ensure that the code doesn't execute before the window is
visible, so that bears out what we were discussing on IRC with this being
related to how focus is being set.
Interesting side-effect, not sure if it helps track this down...

Once in this state, as reported earlier the copy command doesn't work correctly.
 However, if you copy text (e.g. in another program) and use shift-ins to paste,
everything is back to normal.  Arrow keys work again, ' does not trigger FAYT.
This is getting really annoying as it interrupts every key depression. Does seem
random but I thought it might only occur on pages which are or were not the
first tab. I've gone back to an earlier version of Firefox 1.0 (November) so I
will see if it occurs again. It doe seem to have started only recently.
I've also experienced this bug. There doesn't appear to be any pattern to its
occurrence or typical type of site that it occurs on (just that the site has to
have form fields), at least not one I can see. It won't go away without a
restart, though I have to admit I've never tried making it go away by creating a
new window (I generally browse with tabs).

I also do not have the RadialContext extension.

It is not the result of using the ' or \ characters.

WinXP, FF1.0 milestone.
Depends on: 279324
I don't agree that this bug depends on bug #279324. That bug hasn't even been
confirmed yet and I can't reproduce his results. While I can say that I have had
the findbar pop up when typing in form fields and had the findbar "steal" what I
was typing, there doesn't appear to be a pattern to it that I can see. I just
had it happen twice in a short period, both times not long after I had restarted
firefox and had been to only a few sites before the problem occurred. However,
I've been to these sites many times before and most times they don't cause this
problem, so it doesn't appear to be site-specific (only that the site needs to
have form fields for the problem to show itself).

I have however confirmed on my computer that when the problem does occur, if I
create a new window, the problem will go away in the new window. The problem
will, however, persist across tabs in an affected window.
(In reply to comment #44)
> This bug is still present in version 1.0 final.
> That's why I've created an example page where the bug behaviour is reproducable.
> 
> Visit:
> http://www.rolo.dds.nl/firefox/index.html
> 
> Regards, Roald

I can confirm this page reproduces my problem. The first time I try to enter
text in one of the fields, the first letter enters in the right field and all
subsequent letters go only in the findbar.

When I refresh with F5 and try typing more, the letters type simultaneously in
the proper field and in the findbar. Refreshing does not stop the problem from
happening.

The problem does not transfer over to other windows that were open at the time.

WinXP SP1, FF1.0 milestone.
(In reply to comment #69)
> Created an attachment (id=170088) [edit]
> test case with more pass/fail cases
> 
> This test case includes some more interesting Pass & Fail states.

Can confirm all fail and pass cases.

Don't know if this was intended, but when clicking on all fail links, the page
where the links are does not change. When clicking on all pass links, the page
advances to a new page containg text like "[object Window]" and "2" and I must
click the back button to return to the testing site.
Recently had to restore my system and installed latest version of Firefox from
scratch. Problem does not seem to arise now even on the bug page mentioned. 
(In reply to comment #24)
> In fact i've found a workaround to this bug. If buggy behavior appears in a 
> new window it helps switching to previous one with a mouse click and 
> returning to the new one also with mouse click.

This workaround seems to work for me. It doesn't matter what other window, i.e.,
it can be a window from a non-Firefox application like Microsoft Outlook. Just
clicking the other window and then clicking the Firefox window stops the faulty
behaviour. Thought this might be a clue to what could be wrong.

I'm using Windows 2000 SP4, Firefox 1.0 ("Mozilla/5.0 (Windows; U; Windows NT
5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0").
(In reply to comment #79)
> (In reply to comment #24)
> > In fact i've found a workaround to this bug. If buggy behavior appears in a 
> > new window it helps switching to previous one with a mouse click and 
> > returning to the new one also with mouse click.
> 
> This workaround seems to work for me. It doesn't matter what other window, i.e.,
> it can be a window from a non-Firefox application like Microsoft Outlook. Just
> clicking the other window and then clicking the Firefox window stops the faulty
> behaviour. Thought this might be a clue to what could be wrong.
> 
> I'm using Windows 2000 SP4, Firefox 1.0 ("Mozilla/5.0 (Windows; U; Windows NT
> 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0").

Yes this works for me as well. Just opening a new Explorer window helps.

I'm using WinXP Home SP2 & Firefox 1.0
(In reply to comment #80)
> (In reply to comment #79)
> > (In reply to comment #24)
> > > In fact i've found a workaround to this bug. If buggy behavior appears in a 
> > > new window it helps switching to previous one with a mouse click and 
> > > returning to the new one also with mouse click.
> > 
> > behaviour. Thought this might be a clue to what could be wrong.

As I reported it in #49, focus changes with or without using the mouse should
work around this bug, but changing focus within the window that is having the
problem will not help.
In the points I raised in #49, I think the last one might also help find out
what is going on with this bug, as this should be easy to track down (clearly a
focus/listener problem).
The point was:
* If I start typing something that is not present in the page, for example try
typing "4qwerty", then the text appears both in the edit text and in the "find
toolbar". Hitting "backspace" will only delete characters in the "find toolbar",
not in the edit text.
(In reply to comment #81)
> The point was:
> * If I start typing something that is not present in the page, for example try
> typing "4qwerty", then the text appears both in the edit text and in the "find
> toolbar". Hitting "backspace" will only delete characters in the "find toolbar",
> not in the edit text.

This is not always the case. Sometimes only the first character entered in a
form field actually gets in the field, and the rest only go to the findbar. So
of course hitting backspace won't delete characters in the form field since
there aren't any (and the cursor isn't focused there).
There are some days when this really really drives me nuts.
I've noticed that recently this seems to be backspace activated. Dunno if it
always was, but it seems to be now. Not always, but sometimes.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8b2) Gecko/20050221
Firefox/1.0+ 
This is reproducible (and annoying) at Fark.com.  Typing ender HTML tags will
trigger the find and remove focus away from the TEXTAREA.  For example:

1. Type <b>blah</b>
2. At the /, the FAYT search comes up.
3. At the b, the b is at -both- the find entry field and the TEXTAREA.
4. At the >, -only- the > is in the find entry field.
5. It does not matter if the > was an alphanumeric instead.  The same behavior
occurs.

Unforunately, I can't (Grrr...BUG at quote!) even go to the other TEXTAREA at
Fark.com (in the other window) because I'm (!!!), ahem, I am getting hit by
another bug that is not allowing me to type at the Fark.com form any more. 
(Apparently, all keyboard input is going to this window, despite the focus on
the first one.)  
Okay, now the problem went away with I turned back on FAYT (it was actually off
on my preferences).  I turned it off again, and the problem still isn't here. 
Yay, I can use HTML tags and contractions (for now).
This bug is reproducible 100% of the time on more than one system I've used.

1. Use Thunderbird as mail client.
2. Receive Livejournal comment notification e-mail.
3. Click reply to comment link in said e-mail.
4. Start typing text in the Livejournal textarea and the bug will occur whenever
an apostrophe is entered.

Works without fail.  This has been going on since 1.0.1 AFAIK.

I seem to find that pressing F8 seems to stop this behavior for some reason.
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
Firefox/1.0.4)
Flags: blocking-aviary1.1?
Blocks: majorbugs
This is happening a lot with the builds from the past few days. The testcases
are just as much testcases as any page with a textarea in my opinion. They don't
reliably reproduce anything.

I can say one thing though, if it helps, everytime this bug occurs, minimising
the window, then maximising again makes it go away.

(In reply to comment #44)
> This bug is still present in version 1.0 final.
> That's why I've created an example page where the bug behaviour is reproducable.
> 
> Visit:
> http://www.rolo.dds.nl/firefox/index.html

I just did an install on a windows XP Pro SP2 that never had any version of
Firefox installed with the default install of Firefox (didn't import anything,
didn't change any of the preferences) and I can reproduce the problem with this
page everytime.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
Firefox/1.0.4

The testcase in attachment 169859 [details] has always exposed the bug for me.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
Firefox/1.0.4
Testcase in https://bugzilla.mozilla.org/attachment.cgi?id=169859 wasn't causing
the bug for me, but I've found out why. This testcase shows the bug only if pref
"dom.disable_window_flip" set to false or absent in prefs.js. This is default
state in a new Firefox' profile, but my profile had this set to "true".

Still I can reproduce the bug without testcase as I described in comment 1 but
testcase is certainly way better :-). So whoever will try to fix this bug, set
"dom.disable_window_flip" to "false".
I don't know if it's just me, but when this happens to me, I always find my page
goes back one (like clicking the left shoulder button on my mouse, or pressing
backspace)I don't know if the find bar pops up before or after the page goes
back to the previous one. I searched for this as a seperate bug, but I couldn't
find it.
No longer blocks: majorbugs
The bug would happen to me occasionally before but with the recent builds it's
gotten so annoyingly frequent that FF was unusable unless FAYT was disabled.
After disabling FAYT, the problem is still persisting, although less frequently.
This, however, led me to an interesting observation.

It seems it isn't a problem with the Find Toolbar itself. As it was pointed out
before, not only the FAYT steals the focus but also copy/paste ceases to work
(and that applies to whole application), you can't move caret in the input
fields etc. When FAYT is disabled, all this still happens, even though the Find
Toolbar doesn't obviously steal the focus. Hence, this must be a problem with
input fields themselves which break down and the Find Toolbar focusing is only
one of the symptoms. It has to be more about the lack of focus on the input
field than about focusing Find Toolbar which is only an effect of the previous.
Therefore I think that the right approach would to investigate the text fields.

And I would really ask to make this a blocker for aviary1.1 (as already
requested) because this bug forces user to restart the program, leads to losing
already typed text (which can’t even be retrieved by copying, thank god for the
ctrl+n workaround) and is fairly common as seen by the number of votes. For new
users it’s probably the most annoying and discouraging type of bug possible.

I too am experienceing the keyboard shortcuts problem in textareas. Ctrl + A,
Shift + Home, Ctrl + V etc. not working as mentioned in comment 94.

With recent builds this is extremely reproducable, and with all pages, not just
these testcases. Installing "Rocker Navigation" from UMO also seems to cause
this to occur frequently for certain pages.
That's a new bug, probably not related to this one. It should be filed
separately, with keyword 'regression' and preferably with regression window,
assigned appropriately (it's more of a focus issue, I believe) and marked
'1.8b3?'. If it's not yet filed of course.

Adding even more comments to *this* bug doesn't help much.
(In reply to comment #96)
> With recent builds this is extremely reproducable, and with all pages, not just
> these testcases.

I have been having the problem a lot more here recently as well. It is very
frustrating. I don't know if anyone else has mentioned this, but if it starts
this behavior then you minimize firefox, then maximize again, it stops.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050528
Firefox/1.0+ ID:2005052808
Depends on: 295931
> That's a new bug, probably not related to this one. It should be filed
> separately, with keyword 'regression' and preferably with regression window,
> assigned appropriately (it's more of a focus issue, I believe) and marked
> '1.8b3?'. If it's not yet filed of course.

Seems related to bfcache: Bug 295931
I see this in FF 1.0.4, and I think I've narrowed it down to having the update
window (or similar) in the background.  If I click the update icon in the upper
left corner, and then go back to my page, the FAYT feature takes over.  If I
type in a form field, I usually get the first character before the rest show up
in the FAYT bar.  If I return to and close the update window, the problem is fixed.

Something that may be another problem entirely: I've tried finishing my typing
into the FAYT field, selecting it, using the context menu to "Copy", but then
couldn't "Paste" into the form field.  I don't know if it's a problem with the
FAYT or the form focus.
I confirm comment 100 with
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050519
Firefox/1.0+

The update window did find some extensions and when it did (or possibly when it
was still searching, I'm not sure) this bug appeared.
I can't reproduce it the second time though, so I can actually write this...
Has no one been able to solve this extremely annoying bug yet???
From user support forum http://forums.mozillazine.org/viewtopic.php?t=274012
Firefox 1.0.4
Mac OS X 10.3.9
Adblock, Autofill 0.2, Netcraft Toolbar 1.0.1 extensions
User reports random, not apparently reproducible occurrences but does NOT report
having to restart the browser to get rid of it (re comment #94).
I do have to restart Firefox to fix this!

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414
Firefox/1.0.3
(In reply to comment #104)
> I do have to restart Firefox to fix this!

Minimizing doesn't work for you?
(In reply to comment #105)
> (In reply to comment #104)
> > I do have to restart Firefox to fix this!
> 
> Minimizing doesn't work for you?

Minimizing doesn't work for me either.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050512 Firefox/1.0.4
(In reply to comment #106)
> (In reply to comment #105)
> > (In reply to comment #104)
> > > I do have to restart Firefox to fix this!
> > 
> > Minimizing doesn't work for you?
> 
> Minimizing doesn't work for me either.
> 
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050512 Firefox/1.0.4


Doesn't work for me, either.  When this bug manifests, nothing I try can get rid
of it, making posting to forums like Mozillazine and others extremely
frustrating, making me go back to using (shudder) IE for a time.

The problem went away with recent nightly builds, but then on the 0601 builds it
returned with a vengence.  The 0601, 0602 and 0603 nightlies all exhibited the
bug.  Now, though, using Bangbang's latest 0604 nightly, the bug is gone again.
Such an odd beast.  Note that I tried nightlies from several builders and they
all exhibited the problem, so it wasn't simply Bangbang's build.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050604
Firefox/1.0+ (bangbang023)
Can you people please stop commenting in this bug with useless comments?

It seems like a known issue in the 1.0.x builds (and possibly the trunk ones,
but I don't see it since I don't use FAYT) so stop posting comments that say
you've encountered this problem.

FAYT is not a feature you can't live without, so disable it if this issue bugs
you (until a fix is available). 

Although since FAYT is more exposed in the GUI now, it might be wise to give
this bug some more attention for 1.1.
(In reply to comment #108)
> Can you people please stop commenting in this bug with useless comments?
> 
> It seems like a known issue in the 1.0.x builds (and possibly the trunk ones,
> but I don't see it since I don't use FAYT) so stop posting comments that say
> you've encountered this problem.
> 
> FAYT is not a feature you can't live without, so disable it if this issue bugs
> you (until a fix is available). 
> 
> Although since FAYT is more exposed in the GUI now, it might be wise to give
> this bug some more attention for 1.1.

Could you not post comments that completely ignore the underlying issue? :-)
That is the problem: I and others have FAYT completely disabled in Options and
about:config yet the bug still happens.  I wish I could disable it, if you know
of a way to disable it, please let us know.  Otherwise, don't chastise people
for something you know nothing about.

The bug STILL EXISTS in the 0604 code, btw, I wrote too soon that it didn't
(oops, typed a ' and the bug reappeared, even with FAYT completely disabled).

Caleb's point was:
Yes, there is a problem.  we don't need everyone saying whether they can
reproduce it or not.  
Things started acting up in the Deer Park Alpha build such as not being able to
use spacebar (or pgup/pgdown) to scroll the page. I happened to also try
entering text into a textbox on a different tab and FAYT kept popping up. I
minimized the window as suggested earlier, and that did fix both the spacebar
scrolling and FAYT popup issues.

Perhaps those are linked somehow maybe focus being in multiple places. I suppose
it could have been because FAYT was eating up the spaces I tried to enter with
the spacebar, but then pgup/pgdown still function to move the page if you
manually open FAYT.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050531
Firefox/1.0+ with accessibility.typeaheadfind and
accessibility.typeaheadfind.linksonly set to true.
Apostrophe seems to be a real trigger here. Just tried it and yup. In fact, it
brings up the find toolbar, but won't find on anything. I just tried it on
"apost" and it came up empty. If I type ctrl-f for find and put in the same
"apost", it comes up and finds the first instance of "apost" on this page, as it
should.
Need testcase keyword.
Keywords: testcase
bug 285294 & bug 264876 possible dupe against this???
I don't think this bug is quite what we think it is, and I don't think it's
actually related to FAYT. This appears to be a general focus problem, firefox is
not correctly setting focus at some point along the road. I have noticed what I
think is a relation to loading tabs in the background and this bug, but
unfortunately due to the inconsistent nature of the bug it's pretty hard to test.

Some telltale signs that the bug will happen on a textbox:
-the copy and paste functionality won't work between anything, be it words from
a page to an input field or a words to windows notepad. As a side note, While
this bug was accouring I used ctrl-c to copy a bit of text off a page and
instead got the entire HTML source, but have never been able to duplicate it.
-additionally to the above: the enabled-disabled state of context menu functions
of copy-paste act strangely when the bug has occurred, some I have observed: all
options enabled with selected page text, all options disabled within a textbox
even though there is text in the clipboard, copy enabled but unfunctional
-the forward/backwards/homee/etc.. keybord buttons don't work on the URL bar

Also, when the FAYT erroneously pops up, it will only find the first 3 letters
of the searched term, after that it claims the phrase is not found.
Sorry for the double comment but just to clarify the above comment, By
forwards/backwards/home I mean the Arrow keys and Home/End buttons, not the
browser functions. Just realised how badly i worded it on a reread.
It doesn't really seem to be a "bug". It seems it works as it's supposed to,
it's just a poor design. If I type an apostrophe on any page, including this
one, the find menu opens. The apostrophe is listed as the keyboard shortcut for
find. I just don't think who ever designed that feature was counting on people
posting to forums. I am active in many forums, so this is a major problem for
me. As much as I hate IE, I may have to start using it again. 
It doesn't really seem to be a "bug". It seems it works as it's supposed to,
it's just a poor design. If I type an apostrophe on any page, including this
one, the find menu opens. The apostrophe is listed as the keyboard shortcut for
find. I just don't think who ever designed that feature was counting on people
posting to forums. I am active in many forums, so this is a major problem for
me. As much as I hate IE, I may have to start using it again. 
It doesn't really seem to be a "bug". It seems it works as it's supposed to,
it's just a poor design. If I type an apostrophe on any page, including this
one, the find menu opens. The apostrophe is listed as the keyboard shortcut for
find. I just don't think who ever designed that feature was counting on people
posting to forums. I am active in many forums, so this is a major problem for
me. As much as I hate IE, I may have to start using it again. 
Justin, this bug occurs for me even when I *don't* press / or '. Not that that
would be behaving as designed either. The bug is pretty well-established. Please
see comment #108.
(In reply to comment #119)
> It doesn't really seem to be a "bug". It seems it works as it's supposed to,
> it's just a poor design. If I type an apostrophe on any page, including this
> one, the find menu opens. The apostrophe is listed as the keyboard shortcut for
> find. I just don't think who ever designed that feature was counting on people
> posting to forums. I am active in many forums, so this is a major problem for
> me. As much as I hate IE, I may have to start using it again. 

Right. That's intended. However, this also happens sporradically in text input
areas, which can be a really big pain if you're a big forum or email enthusiast
haha. They know about it, it's just a matter of getting around to fixing it.
(In reply to comment #115)
> -the copy and paste functionality won't work between anything, be it words 

Bug 299514 was filled for these symptoms.


Running on an almost-DPa2 build, this WFM on all testcases, where before it
failed.  I think this may actually be fixed with some of the focus fixes that
bryner wrote to support fastback.  If someone can reproduce on Deer Park Alpha 2
or later, and can provide clear steps to reproduce, please renominate.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
(In reply to comment #123)
> Running on an almost-DPa2 build, this WFM on all testcases, where before it
> failed.  I think this may actually be fixed with some of the focus fixes that
> bryner wrote to support fastback.  If someone can reproduce on Deer Park Alpha 2
> or later, and can provide clear steps to reproduce, please renominate.

I can easily reproduce it on a nightly build from 20050711 with the testcase
https://bugzilla.mozilla.org/attachment.cgi?id=169859 and with the default prefs
as I mentioned in comment 92
Flags: blocking-aviary1.1- → blocking-aviary1.1?
*** Bug 275503 has been marked as a duplicate of this bug. ***
*** Bug 273119 has been marked as a duplicate of this bug. ***
*** Bug 274749 has been marked as a duplicate of this bug. ***
*** Bug 286950 has been marked as a duplicate of this bug. ***
So are there any other testcases that don't involve moving focus around in
popups?  Like in normal pages?  Or is this back to just being that bug?
Flags: blocking-aviary1.1? → blocking1.8b4?
It happens in real pages sporadically while interacting with extensions and
other windows in system. See for example comment 1. Mentioned extension does
nothing scary: just opens a window and prevents default right-click action, but
opened windows becomes almost inoperable.

Why testcase https://bugzilla.mozilla.org/attachment.cgi?id=169859 isn't good
enough? Looks like it just emulates situation when something in system steals
focus while new browser window is opening. It may easily happen for example
because of popping up IM message window.
This happens for me even if I have FAYT disabled in my preferences.  FAYT keeps
stealing focus from the form.  Seems to be intermittent, but when it happens it
keeps stealing focus very frequently (every few characters) and makes entering
text into the form difficult.
*** Bug 276599 has been marked as a duplicate of this bug. ***
*** Bug 264876 has been marked as a duplicate of this bug. ***
*** Bug 297978 has been marked as a duplicate of this bug. ***
*** Bug 253292 has been marked as a duplicate of this bug. ***
(In reply to comment #131)
> This happens for me even if I have FAYT disabled in my preferences.  FAYT keeps
> stealing focus from the form.  Seems to be intermittent, but when it happens it
> keeps stealing focus very frequently (every few characters) and makes entering
> text into the form difficult.

I can now prevent the bug from happening and it has no bearing on the status of
FAYT.  To prevent the bug, I disable the BFCACHE
(browser.sessionhistory.max_viewers set to 0).  By doing that, I no longer have
the focus issues, copy/paste works as it is supposed to, FAYT doesn't pop up
when it isn't supposed to, autoscroll works as it is supposed to.  Setting that
to any non-zero number, however, the problems return, even on the latest trunk
build (currently using 20050719).
Flags: blocking1.8b4? → blocking1.8b4+
(In reply to comment #136)

Confirmed.

> (In reply to comment #131)
> > This happens for me even if I have FAYT disabled in my preferences.  FAYT keeps
> > stealing focus from the form.  Seems to be intermittent, but when it happens it
> > keeps stealing focus very frequently (every few characters) and makes entering
> > text into the form difficult.
> 
> I can now prevent the bug from happening and it has no bearing on the status of
> FAYT.  To prevent the bug, I disable the BFCACHE
> (browser.sessionhistory.max_viewers set to 0).  By doing that, I no longer have
> the focus issues, copy/paste works as it is supposed to, FAYT doesn't pop up
> when it isn't supposed to, autoscroll works as it is supposed to.  Setting that
> to any non-zero number, however, the problems return, even on the latest trunk
> build (currently using 20050719).  


Guys, this bug was present long before fastback was implemented (look in comment
0 it's created even before Firefox 1.0). So may be fastback exposes this
behavior more but it is certainly not the reason.
*** Bug 301468 has been marked as a duplicate of this bug. ***
(In reply to comment #138)
> Guys, this bug was present long before fastback was implemented (look in comment
> 0 it's created even before Firefox 1.0). So may be fastback exposes this
> behavior more but it is certainly not the reason.

I can confirm this bug before fastback, and also with new nightly builds with
BFCACHE off...so I believe that fastback does make the behavior worse and more
frequent, but it is not the initial cause of the find toolbar popping up.
Blocks: 282239
Assignee: firefox → nobody
QA Contact: fast.find
Whiteboard: [bfcache regression?]
likely still an issue, but recent bfcache fixes related to focus should reduce
the degree to which it was aggravated

/cb
Whiteboard: [bfcache regression?]
-'d for 1.5, we think we're somewhat better, but please renominate if we're
still worse than 1.0

/cb
Flags: blocking1.8b4+ → blocking1.8b4-
Flags: blocking-aviary2.0?
I used to experience this bug occasionally, and it was very annoying.

However, since installing today's nightly (20050726) this bug is now happening
much more frequently.

Whereas it used to happen once every few days, it has happened to me many times
in the last half hour alone.
I have to agree.

in the last two days I have experienced this alot and it's really annoying since
you have to restart the browser because you simply can't enter a text into a
textbox (like here) 'cause everytime you hit "'" you end up in the find box.

I'm certainly not in the position to re-plus it for 1.5, but I'd like to express
my concerns about minusing it since i know quite a bunch of people who are
really mad about this behavior.
For those not wanting to go through lots of angry comments, here's how to
reproduce it:

* Set the "dom.disable_window_flip" pref to "false"
* Open attachment 169859 [details] and follow the instructions

It seems that the state of the "dom.disable_window_flip" pref controls: "Allow
script to raise window".
When set to false, scripts are allowed to raise/lower windows, when set to true,
they aren't.

The pref is being set to true when people select the "Disable common annoyances"
 option in the Options > Content dialog.
http://lxr.mozilla.org/seamonkey/source/browser/components/preferences/content.js#179

I've yet to understand the connection of the pref to this bug, though.
I'm renominating this bug since it pretty much causes the browser to break.
Flags: blocking-aviary1.5?
Whiteboard: Read Comment #145 before commenting any further
i've got dom.disable_window_flip set to true and i'm still seeing this (albeit
fairly rarely, not sure how often others are seeing it).
How to have two things with focus:
1. add this to usercontent.css: *:focus {border: 10px solid blue}
2. reproduce the bug. notice that focus seems to behave OK
3. Set focus to first textbox, then use your mouse to click to another FF
window
4. click on the last textbox. Notice that the first textbox still has focus,
and last textbox also has focus, and everything is fixed - you can type now
*** Bug 302484 has been marked as a duplicate of this bug. ***
*** Bug 302507 has been marked as a duplicate of this bug. ***
This bug has become a real nuisance since i installed the trunk nightly from
2005/07/26. I had very few appearences of this bug in the past months with the
trunk nighlies, too few to count them. But with this nightly it happenes
multiple times a day. Somebody seems to have twiddled with the innards of
Firefox that are responsive for this bug, but he made things worse.

Actually it just happened while i am was typing in this form. I opened a new tab
with CTRL-T, click on a bookmark for a translator site and wanted to type some
more text in this form and FAYT popped up. I could reproduce this behaviour a
few times, now it is gone.

And, BTW, another symptom of this bug is that you can't do copy&paste with keys
anymore until you min/maximize the window to get rid of the bug.
Even choosing copy from the context menu doesn't copy anything to the clipboard.

This thing needs to be fixed.
This bug doesn't need any more comments from people who are annoyed by it. Read
comment 145 and don't add anything unless you have NEW information that will
help to reproduce *reliably* or fix the bug.
Possible relationship with bug 220900?  This is a focus-dependent task, and it
is following the same problems as #220900.
Blocks: 220900
I ran into the problem again and knew it was happening before FAYT poped up
because like I mentioned earlier, spacebar/pageup/pagedown for scrolling stops
working. I noticed that the cursor was blinking in the search box and stayed
there even if I clicked on an empty spot and hit spacebar. It stayed there even
through different tabs (I used the mouse to select the other tabs), and I found
an input box to type into and sure enough, FAYT poped up. After FAYT showed up
with some text, the cursor was no longer in the search box.

I don't remember exactly what I did to initiate the search
(enter/alt-enter/etc), but I couldn't get it to happen again. But at least for
this case, I typed some text to search, got the search results and then opened a
couple tabs as well as loading a page over the search results. (I first noticed
spacebar not working on the page that I loaded over the search results.)

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+
I have FAYT disabled because I found it will pop up in text forms and not go
away but now with it disabled it started finding when I try to type an apostophie
Would fixing bugzilla bug 250309 help to get around this at least for now?
It has nothing to do with that bug.  This is really a dupe of bug 220900, from
the look of things, which is basically the generic "focus is wrong sometimes"
bug that's been around forever.
*** Bug 302896 has been marked as a duplicate of this bug. ***
When I experience this bug it is always at the first character. The first
character goes into the find field. Also "common annoyances" is not checked.
*** Bug 303344 has been marked as a duplicate of this bug. ***
Is there a way to turn off "'" (apostrophe) and '/' for Find?  If I type ctrl-F
in a textarea, you can be sure I want to find text.  If I ever type those other
characters, either I am in a form input field, or I thought I was.  That would
work around this bug that no one seems to be working on.  I spend a lot of time
typing in textarea fields for work, and encounter this bug daily.  If this bug
is the same one that breaks Home, End, and arrow keys, at worst I am able to use
the mouse as a workaround.  I also find the clipboard breaks.  I will see
whether all those things happen together, consistently.
Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050804
Firefox/1.0+ ID:2005080406 I can reproduce this bug very consistently! It
happens always with a couple profiles...

1. Create a new profile.
2. Toggle on about:config the pref. accessibility.typeaheadfind from false to true.
3. Make http://www.google.de/firefox?client=firefox-a&rls=org your start page.
4. Open Firefox. The focus will be on Google search bar. Try tipping something
on it. It will work...
5. Go to "Start">"All Programms" and open another window from firefox by
clicking on the programm link.
6. A new window will open with focus on Google search.
7. Try tipping something on it. The Find Bar will popup and you will not be able
to write anything on it. After minimize and maximize this window you will be
able to write on Google search bar. 
Just noting that this bug happens to me alot, but only since Gecko/20050729, it
also happens in:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050803
Firefox/1.0+

I'm yet to work out what starts the issue for me, but its not the same as #162.
Also, none of the navigation keys work.
We don't need any further notes from people that they can reproduce this bug.
It's pretty clear this bug can be reproduced. If you want to indicate that you
think this bug is important, please just vote for it instead.

Can someone with sufficient privileges please add this comment to the status
whiteboard as well? Not that it will make any difference.
Whiteboard: Read Comment #145 before commenting any further → Read Comment #145 and #164 before commenting any further
Mats, would you be willing to look at this? It's reproducable -- see comment 162
Some more informations about the testcase on comment 162

I can reproduce it on build 2005-07-31-10 but I can't on 2005-07-30-07
For some reason when you relaunch using a desktop icon, Firefox opens a new
window but doesn't update the focus controller. The focus controller thinks that
focusedElement is null. Thus, the find toolbar doesn't know that you're in an
HTML input or whatever and starts anyway as you type.

I'll have to look into what codepath is followed when a desktop icon is launched
and there is already a running instance of Firefox. If anyone has any insights
to save me time, let me know.
The general cause of the bug is, focus suppression is off by one.
Here is a dump with Hyatt's focus suppression debugging printfs. I put **** next
to the one which isn't being unsupressed (activation suppression)

Anyone who wants to throw in some thoughts please do :)

[03730DC8] SuppressFocus incremented to 1. The reason is Win32-Only Link
Traversal Issue.
++DOMWINDOW == 13
[03730DC8] SuppressFocus decremented to 0. The reason is Win32-Only Link
Traversal Issue.
[03730DC8] SuppressFocus incremented to 1. The reason is Win32-Only Link
Traversal Issue.
[03730DC8] SuppressFocus decremented to 0. The reason is Win32-Only Link
Traversal Issue.

++WEBSHELL == 7
++DOMWINDOW == 14
[03730DC8] SuppressFocus incremented to 1. The reason is Win32-Only Link
Traversal Issue.

++DOMWINDOW == 15
[03730DC8] SuppressFocus decremented to 0. The reason is Win32-Only Link
Traversal Issue.
[03730DC8] SuppressFocus incremented to 1. The reason is
nsPresContext::EnsureVisible Sup
pression.
[03730DC8] SuppressFocus decremented to 0. The reason is PresShell suppression
on Web pag
e loads.
[03730DC8] SuppressFocus incremented to 1. The reason is
nsPresContext::EnsureVisible Sup
pression.

**** [03730DC8] SuppressFocus incremented to 2. The reason is Activation
Suppression.
[03730DC8] SuppressFocus decremented to 1. The reason is PresShell suppression
on Web pag
e loads.
[03730DC8] SuppressFocus incremented to 2. The reason is Win32-Only Link
Traversal Issue.

++DOMWINDOW == 16
[03730DC8] SuppressFocus decremented to 1. The reason is Win32-Only Link
Traversal Issue.
[03730DC8] SuppressFocus incremented to 2. The reason is
nsPresContext::EnsureVisible Suppression.
[03730DC8] SuppressFocus decremented to 1. The reason is PresShell suppression
on Web pag
e loads.
The comments in nsWebShellWindow.cpp for NS_GETFOCUS say:
    // This is essentially the first stage of activation (NS_GOTFOCUS is
    // followed by the DOM window getting activated (which is direct on Win32
    // and done through web shell window via an NS_ACTIVATE message on the
    // other platforms).

This order is important because 
NS_GOTFOCUS increments focus suppression
NS_ACTIVATE clears focus suppression

This occurs in reverse order when you launch a new window via the OS, e.g. by
clicking on an icon, and thus the focus suppression state clearing doesn't
happen after the incrementing.

Not sure why it's happening out of order.

When I upgraded from 1.0 -> trunk I experienced this bug, and when I downgraded
I didn't. Renominating... I think it's worth delaying the release to get this fixed.
Flags: blocking1.8b4- → blocking1.8b4?
Comment on attachment 192168 [details] [diff] [review]
First attempt. I still plan on looking into why we're calling NS_GOTFOCUS an extra time.

ESM doesn't process NS_GOTFOCUS if focus is already there, so why should
nsWebShellWindow?

That seems like a a general fix which might really plug a lot of holes, because
we don't really know that specifically that NS_GOTFOCUS won't occur at a bad
time. In the case i looked at, we were getting an NS_GOTFOCUS via WM_SETFOCUS
because we were destroying a window as we launched for the 2nd time. It does
bother me that we were destroying a window at all in that scenario, but that
seems like a separate thing to look at since  that was apparently only 1 way
this bug is caused. Since the other cases have been too random for people to
write reproducable steps, I suggest we try to use a general fix like this for
this out of whack focus suppression, and what focus issues remain after it goes
in..

One question is, can't we put in more safeguards against out-of-whack focus
suppression? It can assert in debug builds if it runs, but save people in
release builds from seeing these problems?
Attachment #192168 - Flags: superreview?(bryner)
Attachment #192168 - Flags: review?(mats.palmgren)
This bug can also be caused by the the edit attachments dialog in bugzilla which
is a special case.

See bug 303620
(In reply to comment #169)
I'm not sure that it is happening out of order. This is what is likely
happenting: The new window opening causes focus to be given without a
NS_GOTFOCUS being sent. In response to focus being received a NS_ACTIVATE is
sent. The NS_GOTFOCUS mechanism still thinks it has to do something so it gets
sent, but the focus doesn't respond with another NS_ACTIVATE. I'm probably
mixing a few things up, but the basic concept should be clear enough.
Flags: blocking1.8b4?
Flags: blocking1.8b4+
Flags: blocking-aviary2.0?
Flags: blocking-aviary1.5?
I had it wrong the first time. The NS_GOTFOCUS is being sent before and after
the NS_ACTIVATE.

The 2nd NS_GOTFOCUS is occuring because some window is getting destroyed as
"paint suppression" gets turned off for the XUL window. Since the currently
focused window is destroyed, the operating system focuses a new one and sends us
WM_SETFOCUS to match it.
Flags: blocking1.8b4+ → blocking1.8b4?
I've got a testcase that seems to always work for me. It's Linux only because of
how access key and tab switching work.

Tested on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050808
Firefox/1.0+

1. Create a new test profile
2. Go to about:config and set accessibility.typeaheadfind to be true
3. Load http://www.mozilla.org/projects/deerpark/alpha2.html into the first
(only) tab. This should be the default home page (alt-home).
4. Open a new tab (ctrl-t) and load the same page as in step 3.
5. Press alt-1 to switch to tab 1 as well as making tab 2 go to
http://www.mozilla.org
6. Press alt-2 (from tab 1) to switch to tab 2 as well as moving tab 1 down to
the body of the page. (The favicon for tab 1 changes to the default.)
7. Press alt-1 (from tab 2) to switch to tab 1 as well as making **tab 1** go to
http://www.mozilla.org
8. Try typing into the search box from tab 1, and FAYT pops up.

Interesting thing to note is that when doing step 6, the tab switches to tab 2,
but focus stays on tab 1. This can be checked by hitting space only to have tab
2 not scroll down the page, but switching to tab 1 will have the page further down.

Even more proof that the focus is actually in tab 1 is if you press alt-s after
step 6. This causes focus to switch to the search field in tab 1 while the user
sees tab 2. You can then type in something to search for (you won't be able to
see what you're typing), and then press enter to initiate the search.

However, the symptom of spacebar for page scrolling not working, doesn't quite
hold for tab 1. But if you do switch to tab 2, spacebar will fail to scroll down
the page.
Flags: blocking1.8b4? → blocking1.8b4+
Edward, I don't really understand all your steps, can you simplify it down to 5. 
> Press alt-1 to switch to tab 1 as well as making tab 2 go to
> http://www.mozilla.org
What am I missing, that sounds like 2 steps. Or how does alt+1 to go to tab 1
make tab 2 change to http://www.mozilla.org?

> 6. Press alt-2 (from tab 1) to switch to tab 2 as well as moving tab 1 down to
> the body of the page. (The favicon for tab 1 changes to the default.)
What do you mean moving tab 1 down to the body?

I guess what I/we need is people to apply and build the proposed patch and see
if things get better or worse.
(In reply to comment #177)
> > Press alt-1 to switch to tab 1 as well as making tab 2 go to
> > http://www.mozilla.org
> What am I missing, that sounds like 2 steps. Or how does alt+1 to go to tab 1
> make tab 2 change to http://www.mozilla.org?

I mentioned this was a testcase only for Linux because on that platform, alt-#
is to change tabs as well as alt-<accesskey> to activate a link. It just happens
that those mozilla.org pages have access key 1 (go to body) and access key 2 (go
to root).

Here's a testcase with little description..

1. Make a new profile on *deer park alpha 2*
2. Set accessibility.typeaheadfind to be true in about:config
3. Load the home page in the current tab
4. Open a new tab and load the home page
-- let the pages load --
5. Press alt-1
6. Press alt-2
7. Press alt-1
8. Type into the gray search box

Sorry I couldn't get it down to 5. But on a good note, I'm able to get fayt to
trigger with attachment 192321 [details].
(In reply to comment #177)
> I guess what I/we need is people to apply and build the proposed patch and see
> if things get better or worse.

I just built with the patch, it doesn't help with your testcase here. It might
have helped with bug 295931, though.
(In reply to comment #178)
Right, it fixes comment 162

The testcase is yet another way to make the problem happen.
I think the general cause of the bug is that have 2 separate internal places we
store the current focus, which don't always agree:
1) In nsEventStateManager's mCurrentFocus -- this is used for tabbing and
display the focus outline
2) In nsFocusController's mCurrentElement -- this is used by JavaScript as well
as in C++ by code that wants to GetFocusedElement() and make a decision based on
that, such as what to put in a context menu or whether to start find as you type
after a keystroke.

So far I have found 2 reasons they can disagree. There could be more.
1) SetSuppressFocus(PR_TRUE) is called more times than
SetSuppressFocus(PR_FALSE). When focus is suppressed
nsEventStateManager::SetContentState(NS_EVENT_STATE_FOCUS) is allowed to update
its concept of focus, but nsFocusController:SetFocusedElement() isn't. The
latter is called from the former via SendFocusBlur's generation of DOM focus
events. In any case, when the focus suppression count is positive and doesn't
get cleared, they get out of sync. The first patch I posted fixes one time this
happens.
2) When a blur handler changes the focus. In that case, nsFocusController sets
its mCurrentElement to null, but SendFocusBlur() decides not to update
nsEventStateManager::mCurrentFocus because it's trying to respect what the blur
handler did.

Notes:
- I'm not 100% sure what focus suppression is for. It might be to prevent focus
stealing, but I'm not sure how it's supposed to work exactly.
- From a general programming standpoint, I don't like that we have orthogonal
concepts of focus. Why can't the focus manager ask the focused window's esm for
it's focused element?
- We don't even have assertions that tell us when these things get out of sync.
We should add that to prevent future situations.
Attached file Linux only testcase — 
Here's a minimal testcase for linux instead of using the mozilla.org pages.

The page loaded into tab 2 contains an access key of 1 that loads a blank page
when activated. I couldn't get fayt to pop up if the second page did not have
an access key triggered when switching tabs.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+
Edward, can you see if this fixes your Linux testcase? I don't have a Linux box
here.
Attachment #192168 - Attachment is obsolete: true
Attachment #192328 - Flags: superreview?(bryner)
Attachment #192328 - Flags: review?(mats.palmgren)
Actually there's a 3rd place we store focus -- in some of the form frames
(mTextControlFrame, nsListControlFrame and nsComboboxControlFrame). That getting
out of sync is the cause of bug 303620.
The Linux only testcase can be used on Windows if you change 
ui.key.generalAccessKey to 17
Aaron, while you're on the general focus issue, please could you check out
https://bugzilla.mozilla.org/show_bug.cgi?id=295931#c23 and
https://bugzilla.mozilla.org/show_bug.cgi?id=295931#c25 ? They seem to be related. 
It turns out that the "Linux only testcase" is caused by the out-of-whack focus
suppression category of problems, as I defined it in comment 182.
Attachment #192328 - Flags: superreview?(bryner) → superreview+
Attachment #192168 - Flags: superreview?(bryner)
Attachment #192168 - Flags: review?(mats.palmgren)
People please pound on this. And if someone can build Seamonkey and check to
see if bug 38673 in composer that'd be great.
Assignee: nobody → aaronleventhal
Attachment #192328 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #192419 - Flags: superreview?(bryner)
Attachment #192419 - Flags: review?(mats.palmgren)
Attachment #192328 - Flags: review?(mats.palmgren)
This patch appears to fix all the testcases in this bug, the random occurances
(none so far) and bug 295931. I didn't spot any regressions yet, but that
doesn't mean they aren't there... testers wanted.
(In reply to comment #190)
> This patch appears to fix all the testcases in this bug, the random occurances
> (none so far) and bug 295931. I didn't spot any regressions yet, but that
> doesn't mean they aren't there... testers wanted.

I found one. Open google, put your focus on the text field. Alt+tab twice, then
tab. Two focus outlines.
Comment on attachment 192419 [details] [diff] [review]
A little bit better -- fixes Linux testcase. Also removes som old needed code.

Will come up with new patch to address to alt+Tab issue.
Attachment #192419 - Flags: superreview?(bryner)
Attachment #192419 - Flags: review?(mats.palmgren)
Originally I thought it would be a good safeguard to prevent SetContentState
from focusing aContent if focus suppression was on, thus preventing a situation
where mCurrentFocus would be different from nsFocusController's mFocusedElement
since that wouldn't be updated in such a scenario. However, that broke
alt+Tabbing back to the app, and wasn't necessary to fix the problems I've seen
so far. If we continue to have problems I can look at some other way to ensure
that doesn't happen via SetContentState while focus suppression is on.

Please test with the new patch. Don't forget to reverse the old one with patch
-R before downloading and applying this one.
Attachment #192472 - Flags: review?(mats.palmgren)
May I kindly ask anyone to put a Windows build with the path online? I'd like to
test it also but downloading the source, binutils and CygWin is a little bit
more than 4.7 Mb af a binary for a dialup user :-)
(In reply to comment #194)
> May I kindly ask anyone to put a Windows build with the path online? I'd like to
> test it also but downloading the source, binutils and CygWin is a little bit
> more than 4.7 Mb af a binary for a dialup user :-)

I would like to but today's builds have keyboard navigation broken in a
different way. You can't tab out of the location bar. That makes keyboard
testing difficult.
Since this is core code, please be sure to regression-test Seamonkey.  Even
though they don't have a FAYT toolbar, we don't want to break their focus.
Attachment #192472 - Attachment is obsolete: true
Attachment #192472 - Flags: review?(mats.palmgren)
I've been running with this one and haven't had any problems. Tested with
Seamonkey a bit and Chatzilla as well. Made sure it didn't regress bug 38673.
The SetSuppressFocus() in that code caused problems when it turned on by
accident, which it sometimes did when one switched tabs and Close() had been
called on one of the tabs.
Attachment #192572 - Flags: superreview?(bryner)
Attachment #192572 - Flags: review?(mats.palmgren)
Yes, I was just about to suggest we remove those... more in a bit...
One thing I never finished investigating was why, with the "Linux only testcase"
documents actually got ::Close() called on them. (That testcase can be used on
Windows if you use ctrl for your accesskey)

Another thing I never figured out, is why did turning of bfcache solve a lot of
people's problems with focus?

Perhaps the two are related, I'm not sure at the moment.
Actually it was nsDocumentViewerImpl::Close(), so the document wasn't getting
closed as I thought.

However, that was setting the document's window to null.

It happens after you use ctrl+1 to come back to the first tab.

(In reply to comment #182)
I agree with what you say here. Regarding suppression, I did a little
code archeology and found that the key checkin is for bug 54203.
See the comments here:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/docshell/base/nsDocShell.cpp&rev=1.720&root=/cvsroot&mark=5658-5668#5657
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/docshell/base/nsDocShell.cpp&rev=1.720&root=/cvsroot&mark=5789-5797#5768

Regarding the "Window Switch" suppressions (bug 38673):
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/content/events/src&command=DIFF_FRAMESET&file=nsEventStateManager.cpp&rev2=1.178&rev1=1.177

I don't think it's correct to add suppressions like that without a
corresponding unsuppress (and the unsuppress that was commented out
in that patch has since been added in again, it's in NS_DEACTIVATE)

Testing FF/Linux (without patches,just tracing) with the "Linux testcase":
--------------------------------------------------------------------
ESM[0x83b6450] SetFocusedContent (nil) => 0x889db88
FC[0x83ad1d0] SetFocusedElement (nil) => 0x889db88
[0x83ad1d0] SuppressFocus incremented to 1. The reason is Win32-Only Link
Traversal Issue.
++DOMWINDOW == 11
[0x83ad1d0] SuppressFocus decremented to 0. The reason is Win32-Only Link
Traversal Issue.
[0x83ad1d0] SuppressFocus incremented to 1. The reason is
nsPresContext::EnsureVisible Suppression.
[0x83ad1d0] SuppressFocus decremented to 0. The reason is PresShell suppression
on Web page loads.
ESM[0x83b6450] SetFocusedContent 0x889db88 => 0x889db88
FC[0x83ad1d0] SetFocusedElement 0x889db88 => (nil)
ESM[0x83b6450] SetFocusedContent 0x889db88 => (nil)
ESM[0x83b6450] SetFocusedContent (nil) => (nil)
ESM[0x83b6450] SetFocusedContent (nil) => (nil)
[0x83ad1d0] SuppressFocus incremented to 1. The reason is SendFocusBlur Window
Switch #2.
ESM[0x83b6450] SetFocusedContent (nil) => (nil)
ESM[0x87fcc08] SetFocusedContent (nil) => (nil)
ESM[0x83b6450] SetFocusedContent (nil) => 0x889db88


Focus out of whack!!!
--------------------------------------------------------------------

Your original patch -or- just removing the "Window Switch" suppressions
-or- leaving it in and adding a matching unsuppress -or- your latest patch
all fixes the "Linux testcase".
I did some tests and when I run the "Linux only testcase" (on Windows, using
accesskey modifier as ctrl trick), I find that the bug only occurs when fastback
is enabled. if I change browser.sessionhistory.max_viewers to 0 the bug goes away.

Anyone else want to verify that for that particular testcase? I noticed in a lot
of these focus bugs people saying that setting that to 0 would make the problem
go away.

So, I want to make sure we investigate why fastback is causing that. I know that
the real problem was that the document had no dom window, and that's what caused
the SendFocusBlur() code to fire.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050812 Firefox/1.0+
ID:2005081219

Bfcache is off. I cannot reproduce this with the Linux only testcase, but I can
reproduce using the tiny testcase.
I confirm that the "Linux testcase" only occurs with fastback on.
This is the same testcase but with added focus/blur logging.
The difference is the extra 2 blurs near the end for "fastback on".

fastback off:	fastback on:
####start
3 focus 	3 focus     
3 focus 	3 focus     
#### control-click link
4 focus 	5 focus     
#### Alt-2
6 blur		6 blur	    
6 focus 	6 focus     
6 blur		6 blur	    
6 focus 	6 focus     
6 focus 	7 focus     
6 blur		7 blur	    
#### Alt-1
7 focus 	8 focus     
7 focus 	8 focus     
7 focus 	8 focus     
#### Alt-2
8 blur		8 blur	    
8 focus 	8 focus     
8 focus 	8 focus     
#### Alt-1
9 focus 	9 blur	    
		9 blur	    
		9 focus
In the attached traces there are four sections divided by
"****** nsDocShellFocusController Focus To: ..." which
corresponds to the tab-switching we are doing in the testcase.
Only the last section differs. The crucial point is that
when fastback is on we have "mDocument != gLastFocusedDocument" on #4154 here:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/events/src/nsEventStateManager.cpp&rev=1.596&root=/cvsroot&mark=4154,4156,4181,4199,4172#4145

so we fall into the "Window Switch #2" trap that puts our focus out-of-sync
and also we fire blur here which is what the JS log testcase shows also.


Here's a diff between the trace files:

--- /tmp/esm-fb-off.txt 
+++ /tmp/esm-fb-on.txt  
@@ -117,13 +117,16 @@
 FC[0xFC2] SetFocusedElement 0xC4 => (nil)
 ESM[0xESM3] SetFocusedContent 0xC4 => (nil)
 gLastFocusedDocument=0xDOC1 mDocument=0xDOC1 globalObject=0xG1
 ESM[0xESM3] SetFocusedContent (nil) => (nil)
 gLastFocusedDocument=0xDOC1 mDocument=0xDOC1 globalObject=0xG1
 ESM[0xESM3] SetFocusedContent (nil) => (nil)
-gLastFocusedDocument=0xDOC1 mDocument=0xDOC1 globalObject=0xG1
+mDocument=0xDOC2, newWindow=(nil), newFocusController=(nil) #
gLastFocusedDocument=0xDOC1, oldWindow=0xW1 oldFocusController=0xFC2
+[0xFC2] SuppressFocus incremented to 1. The reason is SendFocusBlur Window
Switch #2.
+ESM[0xESM3] SetFocusedContent (nil) => (nil)
+ESM[0xESM4] SetFocusedContent (nil) => (nil)
+gLastFocusedDocument=(nil) mDocument=0xDOC1 globalObject=(nil)
 ESM[0xESM3] SetFocusedContent (nil) => 0xC4
-FC[0xFC2] SetFocusedElement (nil) => 0xC4
-[0xFC2] SuppressFocus incremented to 1. The reason is Deactivate Suppression.
-ESM[0xESM3] SetFocusedContent 0xC4 => 0xC4
-ESM[0xESM3] SetFocusedContent 0xC4 => (nil)
-[0xFC2] SuppressFocus decremented to 0. The reason is Deactivate Suppression.
+
+
+Focus out of whack!!!
+

Wow. This might even fix bug 260996 and bug 261074.
Yes, the tiny testcase and the 2nd launch version of this problem are not
related to fastback.

However, the "linux only testcase" is. And I think it represents a whole class
of focus issues that occur when fastback is on. Probably it's timing related, so
that if there is no window for a tab you've switched to, focus suppression gets
stuck on.

In bug 301804 comment 3, Bryner said
"I suspect the difference is because of the timing of the UnbindFromTree calls
in the DOM tree.  We used to call this when the docviewer was closed, now we
don't do it until the document is destroyed (which isn't until the new content
viewer is shown and destroys its mPreviousViewer). "

I don't know what that means exactly, but Bryner then went on to add a condition
for InZombieDocument to check for a null window, which fixed the problem.

This means that we have a null window for a longer period of time during a page
load, which would cause this find toolbar if you switched to that tab.

My question is, what other places in the code make the assumption that there is
a window for a document? Dbaron reported some crashes. Who knows what else is
built on a different assumptions. So we could:
1) Continue to fix 1 bug at a time
2) Grep through the code for code that gets a window from a document, and look
at what it's doing
3) Change back to the old timing of UnbindFromTree()

The patch here still fixes the problem, but it is not necessarily fixing the
root problem above.
(In reply to comment #209)
> However, the "linux only testcase" is. And I think it represents a whole class
> of focus issues that occur when fastback is on. Probably it's timing related,
> that if there is no window for a tab you've switched to, focus suppression gets 
> stuck on.

By window I mean DOMWindow/ScriptGlobalObject, not a visual window.

*** Bug 278814 has been marked as a duplicate of this bug. ***
Summary: Find Toolbar sometimes pops up when entering arbitrary characters in form input fields, FAYT (find as you type) activated → Find Toolbar sometimes appears (pops up) when typing/entering arbitrary characters in textareas/form input fields, FAYT (find as you type) activated
Version: unspecified → Trunk
Depends on: 285294
*** Bug 301911 has been marked as a duplicate of this bug. ***
Attachment #192572 - Flags: superreview?(bryner) → superreview+
Comment on attachment 192572 [details] [diff] [review]
Actually remove SetSuppressFocus() calls from SendFocusBlur(), which only cause problems and no longer are needed for the fix they were orignally added for

I don't think that the |EnsureFocusSynchronization()| is always the right thing
to do in ESM. If the focus was moved into another ESM with the same
focus controller it could overwrite a valid value (although this is
probably an edge case that never occurs for normal pages.)
Still, I see this part as a temporary solution.

As far as I can see this part of the patch is only necessary to fix the
testcase "Tiny testcase.." (attachment 192321 [details]). The reason is that
when we first blur the SELECT we end up here:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/html/content/src/ns
HTMLSelectElement.cpp&rev=1.232&root=/cvsroot&mark=1759-1772#1731

and on the "forced" frame blur on line 1767 we end up here:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/forms/nsComboboxCont
rolFrame.cpp&rev=1.324&root=/cvsroot&mark=509,519#508

and then the fun begins since we have onchange="something_else.focus()" which
will move the focus and then "on the way back" we end up blurring what was
just focused (in nsHTMLSelectElement::HandleDOMEvent line 1770).

The placement of "FireOnChange()" inside "SetFocus()" is bad for other
reasons as well and I was planning on moving it. Hopefully this solves the
combobox blur problem too. I filed bug 304751 on it.
If you agree, could you add a comment on |EnsureFocusSynchronization()|
referring to that bug?

The rest of the patch looks good, except maybe for the removal of the
null-check of |mDocument| in one place - why do we not need it there?

r=mats with the missing null-check explained or re-instated.
Attachment #192572 - Flags: review?(mats.palmgren) → review+
Comment on attachment 192572 [details] [diff] [review]
Actually remove SetSuppressFocus() calls from SendFocusBlur(), which only cause problems and no longer are needed for the fix they were orignally added for

I will address Mats' comments before checking in.
Attachment #192572 - Flags: approval1.8b4?
Attachment #192572 - Flags: approval1.8b4? → approval1.8b4+
When loading new pages, sometimes if you try to type in a form before the page
is finished loading, it tries to "find" the text via the built in find dialog.
This is very annoying, as you cannot type anything in the form without the find
dialog coming up. Closing the browser and restarting seems to fix it. I see this
bug quite often when using forums (mostly PHPBB).
How does this strategy sound? We check this into the trunk only today, so it can
be tested there for a couple of days by the community. If all goes well we
already have approval to check into the branch.

Mats, I have added the comment to EnsureFocusSynchronization, referring to the
onchange bug. I also added the null check back in, that shouldn't have snuck
into the patch -- thanks for catching it.
Okay, checked into trunk now. Everyone who can, please test the trunk builds
heavily. Focus code is notoriously touchy and I would like to verify this
doesn't break anything before checking it into the branch.
(In reply to comment #218)
> Okay, checked into trunk now. 

Looks like you've checked it in the Branch by accident.
Checked into branch, because the trunk was too hosed to use for testing this.

Please open new bugs for any issues/regressions, and point to the new bug in a
comment in this one. Don't reopen this bug please, it's too big by now.

Also, perhaps someone else can go through and close any other bugs this fixes.

Checking in content/events/src/nsEventStateManager.cpp;
/cvsroot/mozilla/content/events/src/nsEventStateManager.cpp,v  <-- 
nsEventStateManager.cpp
new revision: 1.595.2.3; previous revision: 1.595.2.2
done
Checking in content/events/src/nsEventStateManager.h;
/cvsroot/mozilla/content/events/src/nsEventStateManager.h,v  <-- 
nsEventStateManager.h
new revision: 1.137.4.3; previous revision: 1.137.4.2
done
Checking in xpfe/appshell/src/nsWebShellWindow.cpp;
/cvsroot/mozilla/xpfe/appshell/src/nsWebShellWindow.cpp,v  <--  nsWebShellWindow.cpp
new revision: 1.426.4.3; previous revision: 1.426.4.2
done
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Flags: blocking-aviary1.0-
Target Milestone: --- → Firefox1.5
Keywords: fixed1.8
Confirming it's fixed with my initial scenario also (comment 1).

Thank you very much!
Blocks: 305032
Is bug 305166 a regression from this ? Frequent crashes when using the back button.
Depends on: 305183
No longer depends on: 305183
*** Bug 306346 has been marked as a duplicate of this bug. ***
Depends on: 306235
No longer blocks: 305032
Depends on: 307153
This has had a partial regression. The steps in comment 162 are reproducable
again. Filed bug 307375 for it since this bug is so long now. Splitwindow was
the original cause of that testcase.
This is still an issue for me with apostrophes (') typing an apostrophe in a
text area will activate FAYT, even though I have it disabled. This does not
always occur, so I guess it's not intentional...

This is not the same issue as mentioned in comment 244 so I request this be
reopened :o(
Just seen this bug in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908
Firefox/1.4 - Build ID: 2005090806
It`s broken everything again- copy & paste and moving the cursor with the arrow
keys. 
I can confirm that it is happening again with 2005-09-09 Win32 (1.5b1). My wife
has been complaining, and then I saw it happen as my daughter tried to get into
her Yahoo email account.
i confirm this bug exists, but only in the following site (which is in hebrew):
http://www.tve.co.il
and only when adding and/or replying to a comment made to an article. also in
hebrew.

it doesn't happen all the time, and i last seen it happen with Firefox 1.0.6 on
windows XP.
solution i use was to close firefox and open again, and sometimes delete cache
as well.

We don't need any more confirmations that it's happening again. It's a known
issue and we now have more information about what regressed it (splitwindow).
Please no more spam in this bug. We have repro steps. Any new activity needs to
be related to determining what splitwindow did to create it, and needs to be in
bug 307375.
*** Bug 308229 has been marked as a duplicate of this bug. ***
*** Bug 308303 has been marked as a duplicate of this bug. ***
This bug seems to be back.
I tried to enter coke codes on http://www.cokefridge.de/fridge.html and FAYT is
activated while entering the codes. Sometimes it is activated even while
entering the login, sometimes after a few codes.
I used this site before and then FAYT wasn't activated.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050913
Firefox/1.6a1
Ignore my last comment. Another program stole the focus for a very short time.
The cursor vanishes from input field and then FAYT is activated with the next
keypress.
But this happens only with the input fields of the flash object on the page
mentioned. The focus is not stolen in this "native" text box i am typing in
right now.
*** Bug 308542 has been marked as a duplicate of this bug. ***
*** Bug 308303 has been marked as a duplicate of this bug. ***
*** Bug 308834 has been marked as a duplicate of this bug. ***
Just wanted to mention that this bug is present in firefox 1.0.7, windows. I had
it in 1.0.6 so I just upgraded to see if it went away, but no joy.

I had to turn off FAYT to workaround. Also the trick of opening another tab
worked. The form that got its focus stolen by find (in the exact same way -
closing the find toolbar allows you to enter one more character in the form and
then focus is stolen again) was the google search results page that I got from a
firefox start page home page.
This bug is present in Firefox 1.5 Beta also I had disabled find as you type in
the about:config and it still harasses me.
(In reply to comment #238)
> This bug is present in Firefox 1.5 Beta also I had disabled find as you type in
> the about:config and it still harasses me.


Same thing here: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050904 (No IDN) Firefox/1.4 
(In reply to comment #238)
> This bug is present in Firefox 1.5 Beta also I had disabled find as you type in
> the about:config and it still harasses me.

(In reply to comment #239)
> Same thing here: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
> Gecko/20050904 (No IDN) Firefox/1.4 

Read the bug before commenting. See comment 229
*** Bug 243983 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

I'm still able to reproduce this with Firefox 1.5 final.  It appears to be triggered after closing a tab that has an onUnload() event that uses a confirmation dialog.

After you answer the dialog, and the tab closes, typing into an input field will activate the FAYT toolbar.

To reproduce this you need to have FAYT configured to start finding when you begin typing.
Nevermind... it appears to be a problem caused by Tab Mix Plus (v. 0.2.5.2).

sorry for the bugspam.
(In reply to comment #242)
> I'm still able to reproduce this with Firefox 1.5 final.  It appears to be
> triggered after closing a tab that has an onUnload() event that uses a
> confirmation dialog.
That is basically bug 312251.
Blocks: findgrabs
Verified fixed using Win FF 1.5.
Status: RESOLVED → VERIFIED
Greg in Comment #245 says this is fixed in Win FF 1.5, which matched my experience, however I upgraded to 1.5.0.1 y/day and it appears to be back. 

Should note I'm using Tab Mix Plus, which is mentioned here as a potential problem.  But was using that when I wasn't seeing the problem in 1.5, too.
This bug is not fixed in Firefox 1.5.
This problem occurs for me with ' key.

As it is said in different comments, closing the FAYT is not enough to stop the problem. Reloading the page doesn't stop the wrong behaviour any more. However, if I just open a menu window (Tools\Options) and close it immediately, I can use the ' key in forms of the current page. This is systematic.
(In reply to comment #246)
> Greg in Comment #245 says this is fixed in Win FF 1.5, which matched my
> experience, however I upgraded to 1.5.0.1 y/day and it appears to be back. 
> 
> Should note I'm using Tab Mix Plus, which is mentioned here as a potential
> problem.  But was using that when I wasn't seeing the problem in 1.5, too.
> 

This encountered this bug in FF 1.5 and now in FF 1.5.0.1 and I have no installed extensions.
(In reply to comment #248)
> (In reply to comment #246)
> > Greg in Comment #245 says this is fixed in Win FF 1.5, which matched my
> > experience, however I upgraded to 1.5.0.1 y/day and it appears to be back. 
> > 
> > Should note I'm using Tab Mix Plus, which is mentioned here as a potential
> > problem.  But was using that when I wasn't seeing the problem in 1.5, too.
> > 
> 
> This encountered this bug in FF 1.5 and now in FF 1.5.0.1 and I have no
> installed extensions.
> 

I also have FF 1.5.0.1, but have the following Extensions:
IE View 1.2.7
Talkback 1.5.0.1
Fasterfox 1.0.3
Yahoo! Photos Easy Upload Tool 2005.10.12
Adblock Plus 0.6.1.1

I have found a temporary workaround for this bug (which seems to be NOT fixed).  If you go to about:config and look for the "accessibility.typeaheadfind.flashBar" Preference Name and change its value from 0 or 1 (if it is 0, change it to 1; if it is 1, change it to 0) then the feature seems to "reset" and you will be able to enter in the arbitrary characters in textboxes again.
I noticed too that when the strange behaviour happens, some keys are inefective in the entry area : UP, DOWN, LEFT and RIGHT and also PAGE UP, PAGE DOWN, HOME, END.
Don't know if this is helpful but the bug stops when bringing up options menu trough extra, and then just closing it. Thats how i fix it, dunno if opening a new window would be more quick :) Using ff 1.5.0.1

So why is the status of this bug still labeled fixed?
There are still edge cases that allow for focus to get confused, but tracking all possible causes in a single bug is impractical.

If you have steps to reproduce on a clean profile, please file a new bug and cc me.
*** Bug 356723 has been marked as a duplicate of this bug. ***
No longer blocks: 220900
Product: Firefox → Toolkit
Blocks: 565552
No longer blocks: 565552
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: