User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060211 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060211 Firefox/1.5 [This is a regression that happened either with my current release or one of the two updates just before the current one. (I installed two updates, followed shortly thereafter by the current one, so am not sure when the regression happened.)] Click on a tab to gain the focus. Neither the up/down buttons nor the space bar will work until you also click on the page itself. Reproducible: Always Steps to Reproduce: 1. Open a page in a new tab. 2. Click on that new tab. 3. Try the up/down buttons or the space bar; none of those will work until you first click on the page itself. Actual Results: Page is inactive until it is clicked on. Expected Results: Up/down buttons and/or space bar should be active after the tab is selected.

I see the same behaviour in the latest release. Clicking on the tab of a new page enables tab scrolling but disables normal scrolling. So I think this is intended behaviour.

This is the expected behavior. If you have a tab focused you can't expect page-specific keyboard shortcuts to work.

Comment #2 makes no sense, given that the behavior I reported always worked until a day or two ago. Once a page has the focus, the keyboard keys should work, and--again--they did until something changed in Firefox. I'm not talking about page-specific keyboard shortcuts, I'm talking about normal and expected keyboard behavior, behavior which has worked for quite a long time. This has also been reported by a MAC user in a thread in the MozillaZine Firefox Bugs Forum.

Oops: In my Comment #3, I referred to the wrong thread: It is in this Builds Forum thread: http://forums.mozillazine.org/viewtopic.php?t=380307 , where other users have agreed with my original post in that thread that this behavior is a new change and/or regression.

(In reply to comment #0) > > Steps to Reproduce: > 1. Open a page in a new tab. > 2. Click on that new tab. > 3. Try the up/down buttons or the space bar; none of those will work until you > first click on the page itself. > I see this same behavior in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060209 Firefox/1.5.0.1. (Build 1.8.0.1:2006020905) When it occurs the javascript console shows: Error: uncaught exception: [Exception... "Unexpected error" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: chrome://global/content/bindings/tabbrowser.xml :: setFocus :: line 749" data: no]

If the tab has focus, then Up/Down moves the tab in the tab bar. Clicking on a tab a second time after selecting it gives the tab focus. Where is the bug?

(In reply to comment #4) I search through some builds and I saw the behaviour (being able to scroll the page after focussing an active tab) for the last time somewhere between 11-Jul-2004 and 1-Aug-2004. I see exactly the same behaviour in IE btw (stolen from Firefox?).

I was just playing around with this and if you do click the tab a second time to give it the focus then go back to an old tab it will scroll without having to click it a second time.. then go back the the tab that you just had to click a second time to give it focus and it doesn't need the second click again to give it focus. So if it was intended behavior why would it not keep doing it?? Doesn't make sense to work that way one time and not other times, does it?

Clicking on a background tab once selects it without giving it focus. Clicking on a foreground tab once gives the tab itself focus. When the tab itself has focus, arrow keys and spacebar behave differently. This is intended behavior. Where is the bug?

Not to say that Firefox should behave like IE7 or Opera, but this isn't the way Firefox use to work and it's not the way IE7 or Opera works either. If you see the tab you can scroll it with the arrow and page keys. So you think you should have to click on a tab a second time to get it to work?? why on earth??

On my Mac, page up and down do work, but for the previous tab. It appears that focus is not shifting when another tab is selected. This is new behavior on the branch nightlies. (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060212 Firefox/1.5.0.1) In 1.5.0.1rc1 it worked as expected, when I select a (new) tab focus shifts to the selected tab. Under no circumstances should page down scroll a background tab.

This behaviour changed slightly when we made tabs focusable. This was necessary for accessibility, and won't be changed. That said, if the current tab is not focused, clicking another tab will focus content just fine. Comment 11 is a separate issue, but I don't have my powerbook so I can't test, but if other Mac users are seeing that, it should be filed as a separate bug.

(In reply to comment #12) > That said, if the current > tab is not focused, clicking another tab will focus content just fine. Negative. This is the bug. Clicking on background tab will not focus the tab (correct) but will not focus the content either. The exception in comment 5 is thrown instead.

Actually, I just confirmed that focus remains in the old tab content and you can scroll one page, while viewing another page.

(In reply to comment #13) > Negative. This is the bug. Clicking on background tab will not focus the tab > (correct) but will not focus the content either. The exception in comment 5 is > thrown instead. Ah, the "click on that new tab" part of the original steps to reproduce led me to believe that the new tab was already in the foreground, and was being specifically focused. That being said, I can't reproduce the problem you describe (or the exception in comment 5) by middle clicking a link on the page, then selecting that tab and using the arrow keys. It scrolls as expected. Does it only happen some times? Does how you open the new tab matter?

(In reply to comment #15) > That being said, I can't reproduce the problem you > describe (or the exception in comment 5) by middle clicking a link on the page, > then selecting that tab and using the arrow keys. It scrolls as expected. Does > it only happen some times? Does how you open the new tab matter? I just reproduced it with these steps: 1. On this bugzilla page, click on page body to remove focus from any textboxes 2. Press ctrl-t and go to mozillazine.org 3. Click on bugzilla tab and try scrolling. Press pgdown a couple of times. Actual results: the page doesn't scroll. if you switch back to mozillazine, you'll notice this page scrolled down instead However, if you can't see the exception then you might not reproduce this bug - my javascript console is literaly swarmed with these exceptions, there hundrets of them. Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060211 Firefox/1.5

(In reply to comment #16) > I just reproduced it with these steps: > 1. On this bugzilla page, click on page body to remove focus from any textboxes > 2. Press ctrl-t and go to mozillazine.org > 3. Click on bugzilla tab and try scrolling. Press pgdown a couple of times. > > Actual results: the page doesn't scroll. if you switch back to mozillazine, > you'll notice this page scrolled down instead > > However, if you can't see the exception then you might not reproduce this bug - > my javascript console is literaly swarmed with these exceptions, there hundrets > of them. > > Using > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060211 > Firefox/1.5 Using those exact steps, with the 20060211 build, and I don't see the bug. Tried with my regular profile as well as a clean profile. Could this be extension related, perhaps?

(In reply to comment #17) > Using those exact steps, with the 20060211 build, and I don't see the bug. I'm sorry I can't help any further. I created new profile, disabled memleak log and removed all plugins, and I still have it. With some moderate browsing, my console looks like this: http://syskin.is.dreaming.org/console.png - if you don't see anything like it, you probably shouldn't worry about exact steps to reproduce :(

Can confirm with 20060212 on WinXP. Getting the same: Error: uncaught exception: [Exception... "Unexpected error" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: chrome://global/content/bindings/tabbrowser.xml :: setFocus :: line 749" data: no] ...everytime I switch tabs. Pressing up without clicking on the page then gives: Error: onBrowserKeyUp is not defined Source File: chrome://browser/content/browser.xul Line: 1 Status should probably be changed?

(In reply to comment #19) > Error: uncaught exception: [Exception... "Unexpected error" nsresult: > "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: > chrome://global/content/bindings/tabbrowser.xml :: setFocus :: line 749" Can't reproduce. Extension related? > Error: onBrowserKeyUp is not defined > Source File: chrome://browser/content/browser.xul > Line: 1 This error belongs to WebmailCompose.

These are my steps to reproduce (assuming my home page is http://www.google.com.ar/advanced_search?hl=es) 1_ open Firefox on a clean profile (home page is shown). 2_ select somewhere on the page so no control has focus. 3_ open a new tab and load home page on it 4_ select the first input (should be automatic though). 5_ return to first tab and hit down arrow. Results: Scroll doesn't move and first's input options are shown even when this control doesn't have focus. Expected Results: Scroll should move down Version: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060213 Firefox/1.5

(In reply to comment #21) That's because the page has no reason to scroll.

It has no reason to scroll if you use it maximized, take a look at the second screenshot. And even not having a reason to scroll, it shouldn't open the input's options.

Bug 327139 was filed on essentially this issue - duping forward since it's a cleaner bug. It's also branch only. *** This bug has been marked as a duplicate of 327139 ***

(In reply to comment #12) > Comment 11 is a separate issue, but I don't have my powerbook so I can't test, > but if other Mac users are seeing that, it should be filed as a separate bug. > I have filed a bug report https://bugzilla.mozilla.org/show_bug.cgi?id=327211 as you suggested.