User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051107 Firefox/1.5 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051107 Firefox/1.5 when SVG is used to keep focus in a window, and another tab window is then selected, the results of using search box appear in the SVG window, rather than the new tab window. Reproducible: Always Steps to Reproduce: 1.Open application and open a spare tab window 2.Open http://www.hixie.ch/tests/adhoc/svg/links/001.xml in one Tab window, 3.tab with keyboard tab until focus is in window. 4.select another Tab window, 5. use search box for say "cock up" in google Actual Results: search box results are actually displayed in first Tab window, replacing http://www.hixie.ch/tests/adhoc/svg/links/001.xml Expected Results: google results displayed in second tabbed window related to https://bugzilla.mozilla.org/show_bug.cgi?id=273197 it may be easier to check focus using https://bugzilla.mozilla.org/attachment.cgi?id=202809 my apologies if this is a problem with search box rather than SVG very hard to tell from this vantage point... however this is highly irritating behaviour....

this effect isn't limited to the search box, it effects the whole toolbar including back & forward buttons etc... no wonder I'm finding it annoying, I'm having to think too hard.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051109 Firefox/1.6a1 Can you reproduce this in a clean profile or in safe mode? This works for me if I'm doing it right.

re #2 Adam same result in safe mode, please make sure focus is in window using: https://bugzilla.mozilla.org/attachment.cgi?id=202809 assuming you are sighted, you should see blue change to red as visual confirmation, when using the keyboard tab to change focus. Then click on another tabbed window and try using the toolbar, thanks again.

https://bugzilla.mozilla.org/show_bug.cgi?id=310825 maybe related.

Check your build ID, the two aren't related. That bug was fixed a month before you reported this one. Besides that there's no focus() call in the SVG you link to. This works for me.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051113 Firefox/1.6a1 Hrm... I'm going to have to take back my WFM comment before. Steps to reproduce: 1. Load up the URL of this bug. 2. Tab until you see the first circle with a red outline. 3. Switch to another tab. 4. Press the Go button and watch the SVG tab "reload". Also, click on a bookmark in the bookmarks toolbar, and/or Bookmarks menu and watch it load in the unfocused tab. When the bookmark is loaded in the other, unfocused tab the location bar of the current tab changes but the page shown in the tab stays the same (obviously).

Re: #5 Jonathan, I checked this again in safe mode, and also on a win98 machine with identical results, this bug makes a real mess of the GUI so please try again: You need two tabbed windows open. in one open the URL: https://bugzilla.mozilla.org/attachment.cgi?id=202809 using the keyboard tab to one of the links, the colour will change from blue to red. Now using the mouse click on the other tabbed window. Now use the search box, or the toolbar (for instance) back button, or bookmarks. Assuming for instance that both windows had previous URLs the window which should have focus, ie the one on top, doesn't change, it's the one underneath that gets changed.

Okay, yes I see the bug with that testcase. Confirming.

The problem is that: (1) The element that has focus (xlink:a? xlink:xlink? svg?) doesn't have a blur() method. (2) updateCurrentBrowser, which runs during a tab switch, has the line "this.mCurrentBrowser.focusedElement.blur();". This throws due to (1), and the rest of the function (actually fixing focus, and fixing things like the address bar and title bar) doesn't run. updateCurrentBrowser lives at: http://lxr.mozilla.org/mozilla/source/toolkit/content/widgets/tabbrowser.xml#614 This isn't as serious a security hole as bug 310825 or bug 299677, since I don't think the attacker can focus the element using a script. The attacker has to convince the user to click in the attacker's page, switch tabs using the mouse, and then type (into another tab) without clicking anything else.

Re: #9(1)The element that has focus (xlink:a? xlink:xlink? svg?) doesn't have a blur() method. I may be wrong, but in the pages I am developing blur() doesn't seem to be called when one clicks on another tab. This relates to a bug I am proposing to the CDFWG http://www.w3.org/2004/CDF/ : (draft) window.status & duel focus one example of a really fundamental philosophical flaw: Should there be only one element allowed to be in focus? For instance if one tabs through a document and at the same time mouseover a document It will be normal that a click will deliver me to one URL, whereas an enter will deliver me to another. Device independence suggests that maybe this isn't such a good idea. consider, what will the window.status show as the destination URL? It can only be 'right' 50% of the time. Unless one implements a 'last use' policy with a single focus. cheers!

Using the testcase in comment 10, I the following in the JavaScript Console when I switch tabs: Error: this.mCurrentBrowser.focusedElement.blur is not a function Source File: chrome://global/content/bindings/tabbrowser.xml Line: 651 You might have to set javascript.options.showInConsole to true using about:config in order to see that error message, since it's an error in code that's part of Firefox. That's probably the cause of the problem you were having too.

Having changed focus using the Tab key, close the tab window. This appears to disable the whole menu toolbar including Go, Bookmarks, back button, address bar etc. so closing the window, and all open tabs is the only option. just wondering if this rates as higher than normal....

Bug 323805 has a patch.

The patch in bug 323805 fixes this as well. I was able to verify with the latest 1.8.0 build, but that patch still needs to make it's way onto the Trunk. v.fixed on 1.8.0 branch with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060306 Firefox/1.5.0.2, focus moves to new tab as expected using steps in comment #0 and https://bugzilla.mozilla.org/attachment.cgi?id=202809 as the original tab content (easier to see focus).

Adding verified1.8.0.2 and fixed1.8.1 keywords since this is fixed on those branches.

sorry I can't seem to find this nightly build for mac, where is it? no here:http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-1.6a1.en-US.mac.dmg

*** This bug has been marked as a duplicate of 323805 ***

#18 why is this bug being marked as a dupe? Boris bug was clearly created almost a year after this one. cheers

Since blur() is a method of nsIDOMNSHTMLElement it seems like this won't work for any non-HTML element. Maybe blur and focus should be moved to another interface shared by all languages - HTML, SVG, generic XML.

blocking1.9? is already set.

I have closed this bug as it was marked as a dupe of Bug 323805 which is fixed. I am moving aspects that remain broken to a new bug: Bug 388146