Last Comment Bug 316191 - Focus stays in tab with focused SVG element after switching tabs
: Focus stays in tab with focused SVG element after switching tabs
Status: RESOLVED FIXED
[sg:low]
: fixed1.8.1, testcase, verified1.8.0.2
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: General SVG Bugs
: Hixie (not reading bugmail)
:
Mentors:
https://bugzilla.mozilla.org/attachme...
Depends on: 323805
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-12 08:58 PST by jonathan chetwynd
Modified: 2008-02-12 16:20 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase that demonstrates seeing keystrokes from other tabs (1.55 KB, image/svg+xml)
2005-11-14 20:25 PST, Jesse Ruderman
no flags Details

Description jonathan chetwynd 2005-11-12 08:58:23 PST
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 2005-11-12 09:14:58 PST
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 2005-11-12 13:16:37 PST
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 2005-11-13 01:27:51 PST
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 2005-11-13 01:35:15 PST
https://bugzilla.mozilla.org/show_bug.cgi?id=310825
maybe related.
Comment 5 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2005-11-13 12:42:00 PST
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 2005-11-13 23:11:26 PST
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 2005-11-14 00:51:30 PST
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] (back in October - email directly if necessary) 2005-11-14 03:20:14 PST
Okay, yes I see the bug with that testcase. Confirming.
Comment 9 Jesse Ruderman 2005-11-14 20:25:02 PST
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 2005-11-14 20:25:58 PST
Created attachment 203090 [details]
testcase that demonstrates seeing keystrokes from other tabs
Comment 11 jonathan chetwynd 2005-11-14 22:13:45 PST
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 2005-11-14 22:52:15 PST
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 2005-11-16 06:06:45 PST
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 2006-01-20 19:29:26 PST
Bug 323805 has a patch.
Comment 15 Jay Patel [:jay] 2006-03-06 18:39:47 PST
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] 2006-03-06 18:43:19 PST
Adding verified1.8.0.2 and fixed1.8.1 keywords since this is fixed on those branches.
Comment 17 jonathan chetwynd 2006-03-07 00:21:32 PST
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-7 2006-09-14 16:04:50 PDT

*** This bug has been marked as a duplicate of 323805 ***
Comment 19 jonathan chetwynd 2006-09-14 23:19:48 PDT
#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] (back in October - email directly if necessary) 2007-01-06 17:30:00 PST
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] 2007-04-15 09:20:15 PDT
blocking1.9? is already set.
Comment 22 jonathan chetwynd 2007-07-14 06:09:48 PDT
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

Note You need to log in before you can comment on or make changes to this bug.