Closed Bug 278544 Opened 20 years ago Closed 19 years ago

regression: location bar of newly created tabs is not focussed after using find-as-you-type (not Ctrl-F); workaround: Ctrl-F

Categories

(Toolkit :: Find Toolbar, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla1.8final

People

(Reporter: jiminorris, Assigned: asaf)

References

Details

(Keywords: regression)

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8b) Gecko/20050115 Firefox/1.0+ (bangbang023)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8b) Gecko/20050115 Firefox/1.0+ (bangbang023)

When creating new tabs, the carat is created in the address bar by default.
However, after a while, it stops doing so, and typing brings up the FAYT bar
instead.
I have no idea what triggers this behaviour, however. Not present on 1.0
Milestone, possibly Aviary Landing regression??

Reproducible: Sometimes
Version: unspecified → Trunk
Does it only happen when creating a tab using doubleclick in the tab bar? See
bug 268885.
Version: Trunk → unspecified
(In reply to comment #1)
> Does it only happen when creating a tab using doubleclick in the tab bar? See
> bug 268885.

No, I never open tabs that way, I use CTRL+T to open tabs. Furthermore, I do not
have the problem described in bug 26885. Next time it happens, I will see if
double clicking the tab bar produces the same problem.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050114 Firefox/1.0+

Confirming 

(use of ctrl+T)
Same build as in last comment.
After I closed FF and restarted the problem was gone

->WFM
Noted something else..
If the caret does not appear, something else happens

repro:
1.make sure you are on this page
2.press ctrl+T
3.Go to the new tab
4.Notice it's empty, but has a yellow locationbar and the security lock

(in one instance I noted that all my other tabs in this window suddenly had the
locationbar background colored yellow one and the lock was added.)
(In reply to comment #2)
> ...
> ...Next time it happens, I will see if
> double clicking the tab bar produces the same problem.

Yeah, when it stops working with CTRL+T it also stops working with double-click
in the tab bar, also. However, this is not Bug 268885, as that is double-click only.


(In reply to comment #4)
> Same build as in last comment.
> After I closed FF and restarted the problem was gone
> 
> ->WFM

Yeah, it happens like that, if you close firefox, it will start working
propperly, but eventually, it will stop working again.
It seems that when the carat isn't created in the address bar, FAYT is looking
through the previous tab. However, I still can't figure out what's stopping it
being created in the new tab, rather than staying in the previous one...

When the carat stops appearing in the address bar by default, try opening a new
tab, and typing something, a word you know appears on the previous tab. Go back
to the previous tab, and find FAYT has found that word on the page. 
Somehow this is a strange focus issue.
If I open Gmail login in a new tab, the focus is in the body of the page, not in
the input where it was up till a few days ago.
I don't see the problem mentioned in comment 7 (FAYT looks in previous tab), but
it seems that in my case the address bar no longer receives focus when a new tab
is created after FAYT has be activated the first time.

So if I press either ' or / and type something and it is found (and wait for the
find bar to disappear), then press ctrl+t or double-click the tab bar to make a
new tab, the URL bar won't get focus.  This will continue until the next time I
close/reopen Firefox.

Is this the only cause of this behavior or are there other events that might
trigger it?
Let's set this bug ->NEW
No point leaving it UNCO if the problem can be reproduced, kindof.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've been seeing this, too. I commented on bug 263880 to that effect but this
bug looks like a more accurate (and current) description of what's happening.
The find-as-you-type aspect of things makes this sound like bug 277024, which
also has reproducing instructions. I haven't noticed find-as-you-type opening
when this happens, but then I haven't looked at the previous tab.
When this happens (I open a new tab with ctrl-F and the location bar is not
focused), the following error appears in the JavaScript Console (thanks to Mook
at the MozillaZine forums for noticing this):

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004002 (NS_NOINTERFACE) [nsIInterfaceRequestor.getInterface]"  nsresult:
"0x80004002 (NS_NOINTERFACE)"  location: "JS frame ::
chrome://global/content/findBar.js :: getSelectionControllerForFindToolbar ::
line 209"  data: no]
Attached patch patch re comment 12 (obsolete) — Splinter Review
If comment 12 is the cause, this should fix things.  Not setting review flag as
I can't be sure yet that it's the right fix.  Basically, as far as I can tell,
getInterface() throws instead of returning null/false/non-true.  This may be
wallpapering over some precondition about nsIDocShell -> nsISelectionDisplay.

Could other seeing this apply this to toolkit.jar/content/global/findBar.js and
see if it helps?
To reproduce this when it isn't happening, use the find toolbar once and then
dismiss it with Esc, then try opening a new tab with Ctrl-T.
mook: that's correct, neither QI nor GI will return null on failure, they're
required by api to throw.
(In reply to comment #13)
> Could other seeing this apply this to toolkit.jar/content/global/findBar.js and
> see if it helps?

Mook,

I can confirm that this patch fixes this isue as well as bug 274553.

I can duplicate the lost URL focus with CTRL-T when the findbar has opened,
found, and closed with the current trunk build.  When your patch is added, the
URLbar has the focus like it should.
Summary: Carat stops appearing in address bar of newly created tabs after a seemingly random period of time. → Caret stops appearing in address bar of newly created tabs after a seemingly random period of time.
I think this bug is related to bug 264562. If the home page (poss only in my
case, as mine is about:blank) and the new tab hasn't loaded propperly by the
time you start typing, it will activate FAYT in the previous tab. However, where
this differs from bug 264562 is now FAYT has been activated once, it will stal
the focus from the URL bar for each new tab.
Flags: blocking-aviary1.1?
(In reply to comment #17)
> I think this bug is related to bug 264562. If the home page (poss only in my
> case, as mine is about:blank) and the new tab hasn't loaded propperly by the
> time you start typing, it will activate FAYT in the previous tab. However, where
> this differs from bug 264562 is now FAYT has been activated once, it will stal
> the focus from the URL bar for each new tab.

By that, I mean, bug 264562 is a dupe of this. Since this bug has more
information, I think. 

I have full reproducing steps now. There are, 2 ways this can be produced.

1.Have a Firefox window open and a page loaded
2.Open FAYT by typing something. 
3.Close FAYT with the cross.
4.Open a new tab with CTRL+T
Caret is not in the address bar, and typing will activate FAYT.

Version 2

1.Have a Firefox window open and a page loaded
2.Open a new tab with CTRL+T
3.QUICKY type the URL -  (though speed is objective, it's not quick to me, but
waiting after CTRL+T seems to help me last longer before problem arises)
As with my last comment, if the new tab has not completely loaded, this will
activate FAYT and in all subsequent tabs, caret will not appear in the address
bar, and typing will activate FAYT.
Comment on attachment 171430 [details] [diff] [review]
patch re comment 12

Asking r= from person who last touched the code; please tell me if this is the
wrong person.

Please see comment 13.
Attachment #171430 - Flags: review?(steffen.wilberg)
Thanks for bringing this to my attention, but I'm not a toolkit peer. Pick one
of the people listed at http://www.mozilla.org/owners.html#toolkit. I'd suggest
bryner@brianryner.com since he's done a couple of reviews here before
(http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/toolkit/components/typeaheadfind/content/findBar.js&rev=AVIARY_1_0_20040515_BRANCH).

Tweaking summary; trunk only; OS=All. Aviary-landing keyword since that
introduced the find toolbar on trunk.
Assignee: bugs → mook.moz
Component: Tabbed Browser → Find Toolbar / FastFind
Keywords: aviary-landing
OS: Windows XP → All
Summary: Caret stops appearing in address bar of newly created tabs after a seemingly random period of time. → location bar of newly created tabs is not focussed after using the find toolbar and letting it close itself or clicking its close button (works when clicking Esc)
Version: unspecified → Trunk
Summary: location bar of newly created tabs is not focussed after using the find toolbar and letting it close itself or clicking its close button (works when clicking Esc) → location bar of newly created tabs is not focussed after using find-as-you-type (not Ctrl-F)
Summary: location bar of newly created tabs is not focussed after using find-as-you-type (not Ctrl-F) → location bar of newly created tabs is not focussed after using find-as-you-type (not Ctrl-F); workaround: Ctrl-F
Comment on attachment 171430 [details] [diff] [review]
patch re comment 12

Changing r= per advice of Steffen.
Attachment #171430 - Flags: review?(steffen.wilberg) → review?(bryner)
*** Bug 277024 has been marked as a duplicate of this bug. ***
Steps to reproduce per my summary changes:

1. Have find-when-you-type enabled (Advanced Options: begin finding when you
begin typing).
2. Hit Ctrl+F and then Esc (which is the workaround), or restart Firefox.
3. For best visibility, visit a secure site like this bug.
4. Start typing, so the find bar comes up. Pressing / or ' works as well, but
Ctrl-F does not. It doesn't matter if and how the find bar is closed.
5. Hit Ctrl+T to open a new tab.

Expected result:
A new tab is opened, with the focus in a white location bar.

Actual result:
A new tab is opened, with no focus in a yellow location bar.
Hardware: PC → All
I think I've figured the cause of this, well, not on a code basis...

Whenever this problem exists, if I press CTRL and F to bring up the find
toolbar, there is usually something I've typed in there... Either something I've
meant to type in the location bad, but FAYT has take focus, or something I've
typed, using FAYT. 

I think the reason the location bar doesn't get focus, is because FAYT still has
it as long as there is text in there. Pressing CTRL + F and deleting the text in
there, and closing it with the red cross returns focus to the location bar on
opening the next tab.
This may be a dupe of bug 274553 (has the same fix, anyway)

Steffen: I'm assuming you wanted getSelectionControllerForFindToolbar() to fail
silently?  (Assumption based on the null check)  If yes, could you reply to
Mike's question in the other bug?

(It looks like GetInterface fails because there is no presshell / prescontext)
(In reply to comment #25)
> This may be a dupe of bug 274553 (has the same fix, anyway)

I don't think this is the same, I am not experiencing the problems mentioned in
bug 274553. FAYT works fine for me, except for retaining the focus of the caret.
Blocks: 273200
Keywords: regression
Summary: location bar of newly created tabs is not focussed after using find-as-you-type (not Ctrl-F); workaround: Ctrl-F → regression: location bar of newly created tabs is not focussed after using find-as-you-type (not Ctrl-F); workaround: Ctrl-F
Attached patch so called 'real fix' (obsolete) — Splinter Review
Assignee: mook.moz → bugs.mano
Attachment #171430 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #174287 - Flags: review?(mconnor)
this also fixes bug 273200
Priority: -- → P2
Target Milestone: --- → Firefox1.1
Attachment #174287 - Attachment is obsolete: true
Attachment #174287 - Flags: review?(mconnor)
Attachment #174314 - Flags: review?(mconnor)
mconnor: if you're ok with the _first_ change in the browser patch, i'll add it
as well on checkin. It's not really necessary, but calling |closeFindBar| if it
is already closed seems to be wrong (blake did check for the hidden property in
other calls to |closeFindBar|).

This one should also fix bug 274625.
Blocks: 274625
(In reply to comment #30)
> mconnor: if you're ok with the _first_ change in the browser patch, i'll add it
> as well on checkin. It's not really necessary, but calling |closeFindBar| if it
> is already closed seems to be wrong (blake did check for the hidden property in
> other calls to |closeFindBar|).
> 
> This one should also fix bug 274625.


OK, I'll be honest, I've very little idea what you meant by that, but from my
experience with this bug, the focus *seems* to remain in the find bar because
text is still present in it. I'm pretending I understand more than I do here, so
ignore me if I make no sence, but could you somehow empty the contents of the
bar before calling |closeFindBar|

I hope I've understood correctly, otherwise, I have just looked like an idiot, lol.
no, the focus-on-loaction-bar is *always* done after adding a tab. problem is,
we have a js error before that.
I am experiencing this issue and was wondering if a fix was reached. I couldn't
tell from reading the thread. Thanks,

Rob
Attachment #174314 - Flags: review?(mconnor) → review?(vladimir)
(In reply to comment #5)
> (in one instance I noted that all my other tabs in this window suddenly had the
> locationbar background colored yellow one and the lock was added.)

I just wanted to file a bug for this, since's 100% reproducable for me :
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050222
Firefox/1.0+

1 - go to https-site (like bugzilla)
2 - use FAYT (not with Cmd-F)
3 - close the find-bar (not with ESC, but with the button)
4 - press Cmd-T to open a new tab (not from the menubar)
5 - you'll see that the location bar is colored light-yellow

This doen not happen when you use Cmd-F at point 2, only when you've used Cmd-F.
Note that you can't use ESC at point 3 (also because of point 2), it has to be
the button. 
(In reply to comment #34)
> This doen not happen when you use Cmd-F at point 2, only when you've used Cmd-F.

That has to be "This doen not happen when you use Cmd-F at point 2, only when
you've used FAYT."
mconnor / vladimir: care to look at this patch? This issue has enough
side-effects  which should get fixed by this one (e.g. bug 274625)
I've been just testing 

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050221
Firefox/1.0+

And the same nightly on windows.

Neither does the URL bar stay yellow if opening a new tab from this page, nor
can I reproduce the focus bug anymore after a FAYT.

Could someone else install that nightly build as well and verify that it is gone?
Okay, I could not really test it fully in Windows, because of bug 274625
crashing my computer permanently. But the bug is not really gone, it just
doesn't happen so often anymore somehow.
Attachment #174314 - Flags: review?(vladimir) → review?(mconnor)
Attachment #174314 - Flags: review?(mconnor) → review+
Checking in findBar.js;
/cvsroot/mozilla/toolkit/components/typeaheadfind/content/findBar.js,v  <-- 
findBar.js
new revision: 1.4; previous revision: 1.3
done
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Flags: blocking-aviary1.1?
Keywords: aviary-landing
Resolution: --- → FIXED
Comment on attachment 171430 [details] [diff] [review]
patch re comment 12

clearing obsolete request
Attachment #171430 - Flags: review?(bryner)
vrfy'd fixed with 2005031108-trunk ffox bits on linux fc3. thanks for fixing
this, Mano!
Status: RESOLVED → VERIFIED
*** Bug 263880 has been marked as a duplicate of this bug. ***
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: