177166 - Hard to get focus back to location bar after control+enter to load URL in new tab

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Jeremy M. Dolan]

Typeaheadfind is occasionally conflicting with access keys. Often after doing a
TAF search, switching to another app, then coming back to mozilla, ^L and ^T do
not work. I'll type

  ^Lwww...

and it tries to search for www in the page instead of writing that in the
location bar.

It's happened 5 or so times to me ever since TAF was included, but I do not know
exactly how to reproduce it. Happened again today with Linux 2002102308.

Comment 1

[Boris Zbarsky [:bzbarsky]]

To the right component..

Comment 2

[Aaron Leventhal]

Need test case.

Is this happening while your document is still loading, or does that not matter?

I think the real bug might be that the URL bar isn't taking focus immediately
when you hit Accel+L.

Comment 3

[Jeremy M. Dolan]

No, page is definately finished loading when this has happened.

It seems like it's a focus issue. I've seen moz in another confused-focus state,
where the URL bar contents were selected (highlighted), I switch back to moz,
try to type in the address bar, doesn't work. Have to switch away and back again.

Seperate question. Trying to reproduce here, I notice ctrl-L won't fire when a
form element is selected, like all the <select>s on this page. Is that by
design? It makes it very had to use the keybord to get back to the URL bar,
especially on a page like this one where there are 30 or so form elements in a
row. So if that's not by design, I'll file a seperate bug.

Comment 4

[Jeremy M. Dolan]

Another issue with typeaheadfind/focus I've seen twice today:

I'll load a new URL. Window title bar updates. Favicon updates. Page won't
change though. It's still the last one I was at. Mozilla isn't still rendering
though. It's done with whatever it's going to do. Status bar shows:

 "Type ahead find stopped."

I usually have to close that tab to have order restored. Sometimes clicking the
file menu (with the mouse, keyboard won't work) with cause the new page to show
(instantly. No rendering time. As if it switches to the new page buffer which
was already there waiting.)

If it's any help, I noticed this time, when it was in this state, I couldn't
middle-click paste a new URL into that tab either. Mozilla did not react at all
when middle clicking in the document body. When I manually insert it in the URL
bar is when the favicon/title changed.

I love TAF, but it has some serious focus issues that conflict with other parts
of mozilla.

Comment 5

[Jeremy M. Dolan]

Now clicking on links in the page will update the title/favicon, but they are
not loaded. Status bar still just says "Type ahead find stoped." I've seen this
bahavior before (but somewhat recent) as well.

Comment 6

[Aaron Leventhal]

The issues with accelerators not working when you're focused on a <select> is
bug 119696. That fix will probably go into 1.3 alpha, unless it gets approved
for 1.2.

Jeremy, are you sure it's typeaheadfind that's causing your page loading
problem? Please try other ways of going to a new page.

Comment 7

[Aaron Leventhal]

Changing summary to say "accelerators"

The term accesskeys is specific to keys specified by an underlined character in
a prompt. For example, Alt+F for File.

Comment 8

[Mike Cannon]

Attachment: tabbox.xml -- Another instance of (probable) typeahead find conflict

In Phoenix 0.4/Windows XP, I can add bindings to "NextTab"/"PrevTab"
ie, "tabbox._tabs.advanceSelectedTab(+1/-1)",
by adding a case to the "switch (event.keyCode)" statement in
"content/global/widgets/tabbox.xml" and rebuilding .../chrome/toolkit.jar.

For example, the following works fine:
 case event.DOM_VK_F9:
    if (!event.ctrlKey && !event.shiftKey && (event.altKey || event.metaKey))
      if (this.tabbox._tabs && this.tabbox.handleCtrlPageUpDown) {
	 this.tabbox._tabs.advanceSelectedTab(1);
	 event.stopPropagation();
	 event.preventDefault();
       }
     break;

But with a similar "case on DOM_VK_N", typing meta-N, simply yields that beep
that is new w/ typeahead find.	In fact, meta-[A-Z] (except DWZ) ALL give
that beep, suggesting they get gobbled up before hitting this tabbox code.

I have made similar tabbox customizations up through Mozilla 1.1 (and 
perhaps 1.2a) that is, prior to tabbox.xml r1.21 and typeahead find, 
but this is new behavior to me.

Comment 9

[Aaron Leventhal]

I don't think typeaheadfind is doing anything different. We listen to keys that
are occuring in the content window, not in the URL bar.

When you type ^Lwww... and it tries to search, see what down arrow does. If down
arrow is scrolling the page, then it's definitely a general focus problem --
nothing to do with typeaheadfind.

For example, I notice that sometimes the URL bar looks like it's focused,
because it looks selected -- but it's really not.

Comment 10

[Jeremy M. Dolan]

Yes, it's likely the general focus issue. They seem to be more frequent since
TAF was checked in, but that's likely just because I'm using the keyboard more
often. Is there another bug for this?

Comment 11

[Aaron Leventhal]

I'm not sure which of the myriad focus issues we have, that this one is: I would
look at meta bugs 83552, and 64451.

Did you do the arrow key test I mentioned? That will tell us if it's a general
focus issue.

Comment 12

[Emile Snyder]

More details using mozilla 1.2b (build id 2002091016)  (This test scenario may
look strange, but it reflects my usage habits ;)

1. Start mozilla
2. Go somewhere (ie. www.google.com)
3. Open new tab window (ie. ^Lwww.slashdot.org, Ctrl-Enter)
4. a) immediately do ^Lwww
   b) click in body of page, then do ^Lwww
   c) click in location field, then body of page, then do ^Lwww
   d) click in location field, then do ^Lwww

4a-d all cause the text in the location bar to become selected when ^L is hit.

4a incorrectly does typeahead find (this is my common usage scenario)
4b also does typeahead find
4c works (www replaces location bar field text)
4d works

For the tests that are doing the typeahead find, hitting down arrow does scroll
the page.

Comment 13

[Aaron Leventhal]

I think Mozilla focuses the content when the page is first displayed. It doesn't
care whether you're in the middle of typing in the URL bar, but it should.

Comment 14

[Aaron Leventhal]

I'm finding 3 bugs here using the test case propose in comment #12:
1. The keyboard is often completely unresponsive during the first part of a page
load
2. Once the focus finally does appear to go to the URL bar, it's not actually
there - it's really in the page
3. The focus is being bounced to the page as I type in the URL bar

Comment 15

[Diego Biurrun]

This hampers accessibility, as keyboard navigation stops working correctly.

Comment 16

[Jeremy M. Dolan]

In reply to comment #9. It happened again, here's the details:

After a type ahead find, I hit ^L to load a new URL. URL bar highlighted, as if
focus was there, but typing did a new TAF search. Hit ^L a bunch more times,
never had any more affect. The URL bar stayed hilighted, arrow keys and
pgup/down scroll the page normall. Then I tried another hotkey, ^W was the first
one that came to mind. That one worked, so, needless to say, that's the end of
the testing.

Comment 17

[Patrick Xia]

*** Bug 194225 has been marked as a duplicate of this bug. ***

Comment 18

[Diego Biurrun]

Being _extremely_ annoyed by this bug and unable to fix it myself I have decided
to put a reward out on this bug's head.  I am willing to pay the person who
removes this pest from Mozilla

100 US$

Maybe it should be a 50/50 split between a working patch and integrating this
into the official sources, I'm not yet sure about the details.  Some mozilla.org
staff member might act as a trustee and get the money from me beforehand and
give it out upon reaching these targets or I might do this myself.  The details
can be worked out, contact me directly or through this bug

So please spread the word about this and help rid my browser of this abomination.

CCing some mozilla.org staff members to get this on their radar, there is no
established donation procedure I know of for mozilla.org.

Comment 19

[Aaron Leventhal]

I really think this is fixed now.

When through this bug carefully looking at all test testcases and found no
problems (at least on Windows) Mozilla 1.8a2
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040603

Looks like we won't know who to give the $100 to.

Diego or anyone still seeing this? Marking WORKSFORME so someone else can verify.

Comment 20

[Diego Biurrun]

VERIFIED WORKSFORME on Linux 2004052006

Comment 21

[Aaron Leventhal]

(In reply to comment #20)
> VERIFIED WORKSFORME on Linux 2004052006

I think the $100 offer should now go to another important bug that needs fixing :)