Closed Bug 316191 Opened 19 years ago Closed 17 years ago

Focus stays in tab with focused SVG element after switching tabs

Categories

(Core :: SVG, defect)

Product:
Core
Component:
SVG
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jay, Unassigned)

References

(
URL
)

Details

(Keywords: fixed1.8.1, testcase, verified1.8.0.2, Whiteboard: [sg:low])

Attachments

(1 file)

testcase that demonstrates seeing keystrokes from other tabs
1.55 KB, image/svg+xml
Details 
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.
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).
URL: http://www.hixie.ch/tests/adhoc/svg/l... → https://bugzilla.mozilla.org/attachme...
Summary: focus is held after switching tabbed window → Focus stays in tab with focused SVG element after switching tabs
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Flags: blocking1.8.1?
Keywords: testcase
Whiteboard: [sg:low]
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.
Keywords: fixed1.8.1, verified1.8.0.2
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
Flags: blocking1.8.1? → blocking1.9a2?

*** This bug has been marked as a duplicate of 323805 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
#18

why is this bug being marked as a dupe?

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

cheers
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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.
Flags: blocking1.9?
blocking1.9? is already set.
Flags: blocking1.9a2?
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
Status: REOPENED → RESOLVED
Closed: 18 years ago → 17 years ago
Resolution: --- → FIXED
Flags: blocking1.9?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: