316191 - Focus stays in tab with focused SVG element after switching tabs

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[jonathan chetwynd]

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....

Comment 1

[jonathan chetwynd]

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.

Comment 2

[Adam Guthrie]

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.

Comment 3

[jonathan chetwynd]

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.

Comment 4

[jonathan chetwynd]

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

Comment 5

[Jonathan Watt [:jwatt]]

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.

Comment 6

[Adam Guthrie]

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).

Comment 7

[jonathan chetwynd]

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.

Comment 8

[Jonathan Watt [:jwatt]]

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

Comment 9

[Jesse Ruderman]

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.

Comment 10

[Jesse Ruderman]

Attachment: testcase that demonstrates seeing keystrokes from other tabs

Comment 11

[jonathan chetwynd]

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!

Comment 12

[Jesse Ruderman]

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.

Comment 13

[jonathan chetwynd]

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....

Comment 14

[Jesse Ruderman]

Bug 323805 has a patch.

Comment 15

[Jay Patel [:jay]]

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).

Comment 16

[Jay Patel [:jay]]

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

Comment 17

[jonathan chetwynd]

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

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 19

[jonathan chetwynd]

#18

why is this bug being marked as a dupe?

Boris bug was clearly created almost a year after this one.

cheers

Comment 20

[Jonathan Watt [:jwatt]]

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.

Comment 21

[Simon Paquet [:sipaq]]

blocking1.9? is already set.

Comment 22

[jonathan chetwynd]

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