Closed Bug 307375 Opened 19 years ago Closed 19 years ago

[splitwindow] findbar pops up when typing in textfield after launching 2nd firefox

Categories

(Firefox :: Keyboard Navigation, defect)

Product:
Firefox
Component:
Keyboard Navigation
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED DUPLICATE of bug 305032
Milestone:
Firefox1.5

People

(Reporter: aaronlev, Assigned: jst)

References

Details

(Keywords: access, regression) 

Spinoff from bug 258285 comment 162 which is no longer fixed since yesterday.
The root cause of that was always splitwindow but we never knew it.

1. Toggle on about:config the pref. accessibility.typeaheadfind from false to true.
2. Make http://www.google.com your start page.
3. Open Firefox. The focus will be on Google search bar. Try typing something
on it. It will work...
4. Go to "Start">"All Programs" and open another window from firefox by
clicking on the program link, or just launch from a desktop icon or quick launch
bar.
5. A new window will open with focus on Google search.
6. Try typing 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. 

Works in 7/30 builds
Broken in 7/31
Flags: blocking1.8b4?
Blocks: splitwindows
not going to make the b4 train. we should figure these out for b5.
Flags: blocking1.8b5+
Flags: blocking1.8b4?
Flags: blocking1.8b4-
This worksforme with a branch build from MOZ_CO_DATE="Thu Sep 1 03:00:00 CDT
2005" on Linux and with a trunk build from Sep 2.

Do I need to be looking at a more recent build?
It works fine until build 2005-09-06. It's broken on 2005-09-07.
Is that on trunk or branch?  And what are the hours of those builds?
(In reply to comment #5)
> See comment 4

Branch and trunk.

https://bugzilla.mozilla.org/show_bug.cgi?id=307355#c8

The checkin that sent this back to it's post-splitwindow broken state was the
checkin for bug 305032. That one turned out not to fix that bug, but it did fix
all the non-splitwindow focus regressions.
OK, now I'm looking at a Linux build I pulled at MOZ_CO_DATE="Wed Sep 7 21:59:14
CDT 2005".  I still don't see this.  Is this Windows-only, perchance?  The OS
says "All"...
(In reply to comment #7)
> OK, now I'm looking at a Linux build I pulled at MOZ_CO_DATE="Wed Sep 7 21:59:14
> CDT 2005".  I still don't see this.  Is this Windows-only, perchance?  The OS
> says "All"...

It probably is Windows only and may related to which order NS_ACTIVATE and
NS_GOTFOCUS occur.

A workaround in nsWebShellWindow would just check to see if the window is
already activated before suppressing focus, because as the comments say it was
expecting activate to come after, and unsuppress then. That works, but it
doesn't deal with why this regressed from splitwindow.
OS: All → Windows XP
*** Bug 307682 has been marked as a duplicate of this bug. ***
ahh... so opening a second instance is what causes this... confirmed! Bug voted on!
(In reply to comment #0)
> 6. Try typing 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. 
Same here. Also, when typeaheadfind is set to false (default), I'm able to type
anything but ' and / as they trigger the findbar and give it focus (as ctrl+f
does). AFAIK ' and / shouldn't work as shortcuts when something you can input
text on is having focus.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050911(07)
Firefox/1.4
*** Bug 308238 has been marked as a duplicate of this bug. ***
I have been able to duplicate this behavior by:

copying the URL from the address bar by double clicking with the mouse to select
the whole line, then hitting Ctrl-C.

then i try to paste it into the text box of the message board and then that does
not work (either by Ctrl-V or right clicking and trying to click on paste). 

after this i tried to see if hitting the apostrophe would bring up the find box
and it did just that; at least it happened this time...
*** Bug 308415 has been marked as a duplicate of this bug. ***
*** Bug 308584 has been marked as a duplicate of this bug. ***
*** Bug 308748 has been marked as a duplicate of this bug. ***
*** Bug 309070 has been marked as a duplicate of this bug. ***
*** Bug 309181 has been marked as a duplicate of this bug. ***
*** Bug 309216 has been marked as a duplicate of this bug. ***
*** Bug 309326 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20050920 Firefox/1.4
ID:2005092005

I'm having trouble reproducing this - do you really have to start Firefox with a
homepage containing a textarea, or could the bug be reproduced simply by opening
a new tab with a textarea (i.e. Google) in an existing window, then opening a
new window and loading Google into that...?
(In reply to comment #21)
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20050920 Firefox/1.4
> ID:2005092005
> 
> I'm having trouble reproducing this - do you really have to start Firefox with a
> homepage containing a textarea, or could the bug be reproduced simply by opening
> a new tab with a textarea (i.e. Google) in an existing window, then opening a
> new window and loading Google into that...?

Opening a second instance (new window may not be enough, a real new instance of
the program by clicking on the firefox icon may be necessary), and entering
google.com in the address bar, and once loaded typing ' or / does cause this bug
(for me).  Clicking in the taskbar to another program, and then back again to
the second makes it go away.
Also, in a second instance keyboard shortcuts like page up and page down don't
work (bug 307355), and right clicking on text to copy it, the copy option does
not exist.  (All these effects are fixed by clicking in the taskbar to another
program and back.)
> I'm having trouble reproducing this - do you really have to start Firefox with a
> homepage containing a textarea, or could the bug be reproduced simply by opening
> a new tab with a textarea (i.e. Google) in an existing window, then opening a
> new window and loading Google into that...?

Opening a new instance/window of FF when the download manager is openend. No
matter if the page you open is the homepage or not.
The difference between my bug (#309326, marked as duplicate of this) is that the
bug occurs only when the download manager is opened.
Maybe the bug occurs only on the Windows version and not Linux (or others).
*** Bug 309583 has been marked as a duplicate of this bug. ***
A clarification on how to reproduce this bug, and associated behavior therein:

As some posters have commented, you must press either the apostrophe, ', or
forward slash, /, while inside the text area, for this bug to be triggered.  But
here's a more complete explanation (as I have now observed) as to when this bug
is triggered and when it is not.  There may be other methods, which I have not
observed.

OBSERVED BEHAVIOR:
------------------
1. This bug requires that you launch a subsequent Firefox "instance"
independently of any running "instances" (I am using instance in quotes here
because Firefox does not actually permit an independent process within the
active user environment).  That is, if Firefox is already running, and that
particular Firefox "instance" does not exhibit the problem, you MUST launch
Firefox by once again directly invoking the application binary (while Firefox is
already running) for the environment ripe for this bug's behavior to be created.
2. NOTE: After launching the new Firefox "instance," per Observation #1, focus
MUST remain on that new window for the buggy conditions to remain.  If focus
shifts away for even a moment (e.g. you click outside the active window or a
system prompt or other application steals focus), then back again, the buggy
conditions will cease to be present and the bug cannot be reproduced.
3. It is always the last Firefox "instance" launched, in the manner of
Observation #1 (and on which focus remains), with which the bug can be
reproduced.  For instance, if you launch 10 additional Firefox "instances," in
succession, only the last one you launched will exhibit the behavior, since
taking focus off that last "instance" causes the behavior to cease.
4. All tabs open in that last "instance" will inherit the buggy behavior, but
any new window launched via that "instance" will cause the behavior to cease (as
focus is taken away from the window).
5. On Windows, launching a typical web shortcut (if Firefox is the default
browser) will not cause this behavior to occur - regardless of whether the
shortcut launches the web site in a new tab or a new window.
6. Once the bug is present, any website you visit (i.e. not just your homepage)
can be used to trigger the findbar when either ' or / is pressed in a text area.

If you find another way to reproduce this, please post it with details, as
people's computing habits are different and generalities may not help in
reproducing your observations.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20050921
Firefox/1.4 ID:2005092107

I can confirm that the instructions is comment #25 does reproduce the bug.  I
had noticed this bug before but didn't know what caused it.  

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20050922
Firefox/1.4 
*** Bug 309779 has been marked as a duplicate of this bug. ***
*** Bug 309759 has been marked as a duplicate of this bug. ***
*** Bug 309895 has been marked as a duplicate of this bug. ***
Also, I've found that pageup/pagedown home/end fails when FAYT shows up unwantedly.

To test:

Open Ffx
Open it again (Via Desktop/Quicklaunch/Startmenu)
Goto a page with a text field to make sure that the bug is there.
Goto a really long page (
http://www.legislature.state.al.us/CodeOfAlabama/Constitution/1901/Constitution1901_toc.htm
) WITHOUT removing focus from the window.
Try to use Page Down and/or End.

Results: Nothing happens

Expected: The page scrolls or goes to the bottom, as requested.
On Mac OS X v10.4.2 the effects of this bug appear as well now and then: the
Find Bar pops up when you try to type something in a web form. But although I
had the bug about a dozen times already starting a few days & updates after 1.5
beta 1, I haven't been able to find a way to reproduce it yet. Sorry for not
being very constructive and/or helpful, but I wanted to let you know that it
seems to be no specific WinXP problem. I'll continue to try finding a way to
reproduce it though. Thanks.  
This bug can be very easily reproduced using the Software Update dialog when it
has found an update and is downloading it.

Steps to Reproduce:

1. Open Firefox and browse to a page with a textarea.
2. Trigger a Software Update automatic check.
3. If an update is found, offer to install it.
4. Switch back to Firefox and try to type into the textarea.

Actual Results: The Details link in the Software Update download page is
focused, and the Find Toolbar pops up for _every_ _single_ _character_ _typed_
in the textarea.

Expected Results: Normal behaviour.
*** Bug 309985 has been marked as a duplicate of this bug. ***
*** Bug 309213 has been marked as a duplicate of this bug. ***
Seeing this same thing under WinXP (SP2) with FireFox 1.5 beta 1. (I have not
yet tried a newer build.)
Target Milestone: --- → Firefox1.5
*** Bug 310066 has been marked as a duplicate of this bug. ***
Please retest in tomorrow's trunk builds (now that bug 305032 has been fixed)?
Depends on: 305032
Fixed by the check-in for bug 305032.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Duping this to get this off my radar.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

*** This bug has been marked as a duplicate of 305032 ***
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → DUPLICATE
Flags: blocking1.8b5+
*** Bug 310390 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
*** Bug 310585 has been marked as a duplicate of this bug. ***
*** Bug 310648 has been marked as a duplicate of this bug. ***
*** Bug 310665 has been marked as a duplicate of this bug. ***
*** Bug 310719 has been marked as a duplicate of this bug. ***
(In reply to comment #25)
> A clarification on how to reproduce this bug, and associated behavior therein:
> 
> As some posters have commented, you must press either the apostrophe, ', or
> forward slash, /, while inside the text area, for this bug to be triggered.  But
> here's a more complete explanation (as I have now observed) as to when this bug
> is triggered and when it is not.  There may be other methods, which I have not
> observed.
> 
> OBSERVED BEHAVIOR:
> ------------------
> 1. This bug requires that you launch a subsequent Firefox "instance"
> independently of any running "instances" (I am using instance in quotes here
> because Firefox does not actually permit an independent process within the
> active user environment).  That is, if Firefox is already running, and that
> particular Firefox "instance" does not exhibit the problem, you MUST launch
> Firefox by once again directly invoking the application binary (while Firefox is
> already running) for the environment ripe for this bug's behavior to be created.
> 2. NOTE: After launching the new Firefox "instance," per Observation #1, focus
> MUST remain on that new window for the buggy conditions to remain.  If focus
> shifts away for even a moment (e.g. you click outside the active window or a
> system prompt or other application steals focus), then back again, the buggy
> conditions will cease to be present and the bug cannot be reproduced.
> 3. It is always the last Firefox "instance" launched, in the manner of
> Observation #1 (and on which focus remains), with which the bug can be
> reproduced.  For instance, if you launch 10 additional Firefox "instances," in
> succession, only the last one you launched will exhibit the behavior, since
> taking focus off that last "instance" causes the behavior to cease.
> 4. All tabs open in that last "instance" will inherit the buggy behavior, but
> any new window launched via that "instance" will cause the behavior to cease (as
> focus is taken away from the window).
> 5. On Windows, launching a typical web shortcut (if Firefox is the default
> browser) will not cause this behavior to occur - regardless of whether the
> shortcut launches the web site in a new tab or a new window.
> 6. Once the bug is present, any website you visit (i.e. not just your homepage)
> can be used to trigger the findbar when either ' or / is pressed in a text area.
> 
> If you find another way to reproduce this, please post it with details, as
> people's computing habits are different and generalities may not help in
> reproducing your observations.
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20050921
> Firefox/1.4 ID:2005092107
> 
Bypass : When you go to another older instance and comes back to the problem
instance, then the problem disappeared.

(In reply to comment #25)
> A clarification on how to reproduce this bug, and associated behavior therein:
> 
> As some posters have commented, you must press either the apostrophe, ', or
> forward slash, /, while inside the text area, for this bug to be triggered.  But
> here's a more complete explanation (as I have now observed) as to when this bug
> is triggered and when it is not.  There may be other methods, which I have not
> observed.

An observation.
If I launch fixfox with no other instance running and then press the ' or / key
(not in a text area) the find box will appear. This does not generally interfer
with using the browser (since typing in a text box still works), but is not
expected behavior.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
The bug seems to be resolved in 1.5 b2.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006
Firefox/1.4.1
*** Bug 311574 has been marked as a duplicate of this bug. ***
*** Bug 314113 has been marked as a duplicate of this bug. ***
Blocks: findgrabs
*** Bug 310502 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.