264562 - Find As You Type / FastFind opens unexpectedly when rapidly opening a new webpage in a new tab

Status: RESOLVED FIXED

(Toolkit :: Find Toolbar, defect)

Description

[Robert Guico]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

When you open a new tab with CTRL+T, there is an instant of time between when
the command is received and when the cursor is moved up to the address bar.
During this time, any keyboard input is treated as input to the homepage (mine
is blank), and as a result the FastFind bar pops up telling me it can't find
anything.

After the cursor moves up to the address bar, the FastFind bar stays up with
half of my web address. :-)

I believe this only happens when FastFind is enabled.

Reproducible: Always
Steps to Reproduce:
1. Open a new tab with CTRL+T
2. Immediately start typing the address to a website


Actual Results:  
FastFind will tell you it can't find anything.

Expected Results:  
Either held what I had typed in a temporary buffer of some sort and filled the
address bar with what was in the buffer, or ignore my input. The first solution
is preferred.

The workaround is to just wait when I create new tabs.

Comment 1

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041015
Firefox/0.10

WFM

I ctrl-T 'ed like a madman, couldn't duplicate it

Comment 2

[Nickolay_Ponomarev]

It is sometimes reproducible and is highly annoying.

Comment 3

[Robert Guico]

Nickolay is correct; it is quite annoying. The trick to reproducing it is to
CTRL+T and then start typing immediately as if the CTRL+T and then the "http://"
(or whatever) following was a continuous stream of letters. 

Comment 4

[Dirkjan Ochtman (:djc)]

I don't see this behavior With Firefox 1.0 on Windows.

Comment 5

[Robert Guico]

Attachment: screenshot of bug

Screenshot shows how the screen looks after FastFind opens while opening a new
tab.

Comment 6

[Nickolay_Ponomarev]

this will be fixed if bug 269712 is fixed, although the root of the problem may
stay there.

Comment 7

[Michael Clackler]

Attachment: Patch to block FAYT with blank URLBar

This patch fixes this bug as well as bug 269712.

The patch blocks keystrokes from registering as FAYT if the URL Bar is blank.

Comment 8

[Michael Clackler]

Attachment: patch to block FAYT with blank URL or about:config

This patch adds a check to ensure the URLBar is present before blocking and
also adds blocking of FAYT in about:config since it was easy to accomplish with
the added code.

This patch fixes the following:
bug 264562 - Find As You Type / FastFind opens unexpectedly when rapid...
bug 267150 - Find As You Type should be disabled in about:config
bug 269712 - typed letters in about:blank default to find as you type ...

Comment 9

[Nickolay_Ponomarev]

comment 8: I don't think that's enough. The point is that the typed text should
go to the Location bar. As this bug is probably happening due to the fact that
the Location bar doesn't get focus fast enough after CTRL+T is pressed, they
keypresses blocked by your code will be ignored, which is not expected. They
should be directed to the Location Bar instead (if the Location bar gets focus
shortly).

Comment 10

[Michael Clackler]

(In reply to comment #9)
> As this bug is probably happening due to the fact that the Location bar
doesn't get focus fast enough after CTRL+T is pressed

This bug shows up in many different states.  I found it most troublesome when
opening a URL in a new tab, there is a moment in time before the URL loads that
the URL bar is empty and anything typed goes to the Find Bar.  In this case, I
don't think the user wanted to change the URL since they had already requested a
URL for the tab.  It is also not good to use FAYT in this case since there is
nothing to search.  The only way I could consistantly get this problem was to
really slow down my network (used emule to use up most of my bandwidth).  In
this case, the URL took quite a while to load so the "problematic" state was
very evident.  This case is probably more evident for users with slow internet
connections.

Personally, I can not duplicate the bug using ctrl-t no matter how fast I type.
 This state might be more evident on slower computers.  I tried it out on a
"slow" 850 MHz P3 Laptop I have (ramped down to 300 MHz), but I still could not
duplicate the problem using ctrl-T.

Blocking FAYT when the URLBar is blank solves the problem of the FastFind bar
opening for both conditions.

Comment 11

[Nickolay_Ponomarev]

Well, I think the right way to fix this is to redirect all keystrokes from
content area to Location bar if on blank/about:blank page (possibly more
conditions are needed).

>I found it most troublesome when opening a URL in a new tab [...]
Not sure what you are talking about. Why would you type characters at that
moment then? what's the expected behaviour?
That's a different bug anyways. This one is about bad focus after using CTRL+T
and expected result is to forward these keystrokes to the Location bar. Do you
agree?

Comment 12

[Michael Clackler]

(In reply to comment #11)
> That's a different bug anyways. This one is about bad focus after using CTRL+T
> and expected result is to forward these keystrokes to the Location bar. Do you
> agree?

I used this bug because the original submitter spoke about the interaction with
ctrl-T and the find bar, as well as asked for an expected result of "Either held
what I had typed in a temporary buffer of some sort and filled the address bar
with what was in the buffer, or ignore my input."  This patch does the second
option (noted as not being the users prefered method).

My main problem is that I can not reproduce the problem using ctrl-T.  Whenever
I use ctrl-T, the URLBar has focus immediately and I can not get the findbar to
open.

When looking at the code, there is the following which is interesting with
reguards to interaction with the URLBar focus and opening a new tab with ctrl-t
in browser.js:

  function BrowserOpenTab()
  {
    gBrowser.selectedTab = gBrowser.addTab('about:blank');
    if (gURLBar)
      setTimeout(function() { gURLBar.focus(); }, 0);
  }

I am not sure why the timeout is set before focusing the URLBar, or why the set
timeout has a length of 0.  Since the timeout is a little strange, it might be
holding the state for another reason.  I could remove this timeout and
automatically set the URLBar focus, but I can not reproduce the issue with
ctrl-T so I have no state to compare the result to:

  function BrowserOpenTab()
  {
    gBrowser.selectedTab = gBrowser.addTab('about:blank');
    if (gURLBar)
      gURLBar.focus();
  }

Comment 13

[Nickolay_Ponomarev]

Personally I have no problem with blocking input like you do. It's much better
than opening the find toolbar. Just don't forget to request a review.

anybody knows, why is setTimeout call needed?

Comment 14

[sairuh (rarely reading bugmail)]

nominating, as this fix here seems to solve various bugs.

Comment 15

[Jose Fandos]

I can confirm in Firefox 1.0 under Windows XP SP2. Ctrl+T and as the new tab
opens I continue typing the URL I want to visit in the new opened tab (the new
opened tab opens a blank page with nothing on it and the focus on the Address
bar, if left to its own). The focus is not yet set in the URL as I continue
typing right after opening the tab with Ctrl+T and the FAYT bar appears with the
characters that were meant for the URL. I then have to stop and move the mouse
to bring the focus to the Address bar.

I can also confirm that it doesn't always happen. Why opening a new tab
sometimes bring the focus instantly to the Address bar and other times, in the
same session, doesn't I don't yet know. I have a Pentium III 650 if that's of
any relevance.

Comment 16

[Asaf Romano (gone)]

Comment on attachment 169726 [details] [diff] [review]
patch to block FAYT with blank URL or about:config

This is not the right fix.

1) "about:blank/config" doesn't have to be the text in the urlbar, I can type
"www.foo.com", then decide to be in "about:config" to change something
before... The url bar text will still be "www.foo.com".

2) and vice versa: I can surf www.foo.com while the url-bar's text is
"about:config".

There are better ways to check the cureent URI, for example: 
getBrowser().selectedBrowser.webNavigation.currentURI

Comment 17

[Michael Clackler]

Attachment: patch using currentURI

Thanks Asaf,  I thought there must a better way of doing this.

This patch uses .currentURI as you suggested

Comment 18

[Asaf Romano (gone)]

Comment on attachment 171368 [details] [diff] [review]
patch using currentURI

please ask for r= from toolkit peer, say mconnor ;)

by the way, it's better to comment what you're doing instead of pointing to
bugs..

Comment 19

[Asaf Romano (gone)]

Comment on attachment 171368 [details] [diff] [review]
patch using currentURI

you should also check if getBrowser doesn't fail/returns null, i'm expecting a
js error in the view-source window...

Comment 20

[David Naylor]

Ben: Great to see this is a blocker for 1.1!

Comment 21

[Marc Randolph]

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

Now that Bug 278544 is fixed, this behavior is harder for me to reproduce, but
it is still there, especially when the CPU is busy, or Firefox is loading
another page, and/or I'm typing especially fast that day.  I installed Mike's
patch, and while it seems to improve things, FF still eats the first one to
three characters sometimes.

Comment 22

[James Norris]

(In reply to comment #21)
> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050328
> Firefox/1.0+
> 
> Now that Bug 278544 is fixed, this behavior is harder for me to reproduce, but
> it is still there, especially when the CPU is busy, or Firefox is loading
> another page, and/or I'm typing especially fast that day.  I installed Mike's
> patch, and while it seems to improve things, FF still eats the first one to
> three characters sometimes.


I've not seen this at all since Bug 278544 was fixed. 

Comment 23

[Mike Connor [:mconnor]]

Comment on attachment 171368 [details] [diff] [review]
patch using currentURI

>+  //fix bugs 264562, 267150, 269712

add a line before this comment explaining what you're doing, just referencing
bug numbers isn't enough

>+  var uri = getBrowser().selectedBrowser.webNavigation.currentURI.spec;

nit: var url here, we try to keep things called uri to actual URI constructs.

Mano mentioned checking for failure here, but since this is called out of a
browser event listener, I'm not worried.  If you're calling this function from
outside of a browser element, you're going to crash and burn anyway in the
current implementation.

>+  if ((uri == "about:blank") || (uri == "about:config"))

The extra brackets are unnecessary here.

if (url == "about:blank" || url == "about:config")

Comment 24

[Asa Dotzler [:asa]]

->mconnor to clean up and land.

Comment 25

[Jaime Mitchell (use [e-mail] for email)]

Attachment: Update Michael Clackler's patch to address Mike Connor's Comments

Update of Michael Clackler's patch (attachment 171368 [details] [diff] [review]) to address comment 23

Comment 26

[Mike Connor [:mconnor]]

Comment on attachment 186964 [details] [diff] [review]
Update Michael Clackler's patch to address Mike Connor's Comments

that'll do, thanks!

Comment 27

[Asaf Romano (gone)]

Checking in findBar.js;
/cvsroot/mozilla/toolkit/components/typeaheadfind/content/findBar.js,v  <-- 
findBar.js
new revision: 1.16; previous revision: 1.15
done

Comment 28

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 186964 [details] [diff] [review]
Update Michael Clackler's patch to address Mike Connor's Comments

+  var url = getBrowser().selectedBrowser.webNavigation.currentURI.spec;

what's wrong with getBrowser().currentURI?

Comment 29

[Mats Palmgren (inactive)]

CTRL+F still opens the Find bar in about:config in the latest Firefox trunk
and 1.8 branch builds.  Should this bug be reopened?

Comment 30

[Mike Connor [:mconnor]]

Ctrl-F is an explicit user action.  This bug was about unexpected issues with FAYT enabled, which interfered with intended user actions.  I don't think its worth preventing Ctrl+F from triggering the findbar.