Last Comment Bug 124750 - Other tab steals focus with javascript textbox.focus()
: Other tab steals focus with javascript textbox.focus()
Status: VERIFIED FIXED
: fixed-aviary1.0, fixed1.7.5, testcase
Product: SeaMonkey
Classification: Client Software
Component: Tabbed Browser (show other bugs)
: Trunk
: All All
: -- major with 87 votes (vote)
: ---
Assigned To: Johnny Stenback (:jst, jst@mozilla.com)
:
Mentors:
http://www.google.com/
: 128243 135951 138195 158270 158786 167110 167677 168761 175596 177758 178400 182307 184183 186958 187340 187391 191744 194104 194919 195988 196646 198541 200231 200338 200575 200942 203426 206784 207993 209960 210367 210401 210431 210837 211255 213169 215631 215966 216020 216811 218023 219034 219927 220337 220344 222483 224564 226448 227569 228641 231601 237529 239468 240751 241813 242016 242894 243363 243446 243685 244726 245056 245269 245502 246893 247162 249895 250851 252504 252995 253158 255787 256177 257665 258852 259168 260302 260580 260719 260774 262230 262695 265556 265587 267012 270072 272388 313060 (view as bug list)
Depends on: 120148 303871
Blocks: 140346 261393 SA12712 265055 265456 299677
  Show dependency treegraph
 
Reported: 2002-02-10 13:01 PST by Robin Green
Modified: 2014-04-26 03:33 PDT (History)
164 users (show)
asa: blocking1.8a3-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
testcase (168 bytes, text/html)
2002-09-11 18:53 PDT, jag (Peter Annema)
no flags Details
Another (more luxurious) testcase (944 bytes, application/vnd.mozilla.xul+xml)
2003-01-12 17:02 PST, Andreas Kunz
no flags Details
real world test case (446 bytes, text/plain)
2003-09-29 18:35 PDT, cato
no flags Details
Possible patch (2.86 KB, patch)
2004-03-31 15:01 PST, neil@parkwaycc.co.uk
bryner: superreview-
Details | Diff | Review
Drop focus events on the floor if they happen in hidden tabs. (3.84 KB, patch)
2004-09-23 15:01 PDT, Johnny Stenback (:jst, jst@mozilla.com)
no flags Details | Diff | Review
Less scary approach, only drop focus changes that come from direct DOM calls. (10.14 KB, patch)
2004-09-23 16:51 PDT, Johnny Stenback (:jst, jst@mozilla.com)
no flags Details | Diff | Review
Even less scary, and more "correct" hack (8.12 KB, patch)
2004-09-27 16:50 PDT, Johnny Stenback (:jst, jst@mozilla.com)
bryner: review+
bryner: superreview+
brendan: approval‑aviary+
brendan: approval1.7.5+
Details | Diff | Review
select() testcase (246 bytes, text/html)
2004-10-02 15:43 PDT, Dean Tessman
no flags Details
patch for current trunk, including select() (9.03 KB, patch)
2004-10-02 19:32 PDT, Vaclav Dvorak
no flags Details | Diff | Review
Fix for the input.select() problem (1.49 KB, patch)
2004-10-05 23:15 PDT, Johnny Stenback (:jst, jst@mozilla.com)
bryner: review+
bryner: superreview+
chofmann: approval‑aviary+
dveditz: approval1.7.5+
Details | Diff | Review

Description Robin Green 2002-02-10 13:01:40 PST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205
BuildID:    2002020511



Reproducible: Always
Steps to Reproduce:
1. Load google in one tab - it may be necessary to delay it loading by making a
page that redirects to google after 5 seconds.
2. Type some text into a textbox in another tab.


Actual Results:  When google.com finishes loading, the Javascript on Google.com
will steal the focus so your text will start appearing in the other tab.

Expected Results:  Non-active tabs should not steal focus from active tabs.
Comment 1 Kai Lahmann (is there, where MNG is) 2002-02-10 13:05:11 PST
same for me.. (including versions)
Comment 2 Jesse Ruderman 2002-02-28 16:00:33 PST
*** Bug 128243 has been marked as a duplicate of this bug. ***
Comment 3 jag (Peter Annema) 2002-03-04 05:39:17 PST
bryner, any idea what we can do about this?
Comment 4 Brian Ryner (not reading) 2002-03-09 19:00:51 PST
This is kind of a hairy issue.  In the case where you're using full windows,
what we do is use the focus controller's active state to determine whether an
element taking focus should actually cause a widget focus.  Unfortunately, focus
controllers are per-toplevel-window, not per-tab.  We should get some other
focus guys together and figure out how this should work.
Comment 5 saari (gone) 2002-03-10 19:50:32 PST
Smells like a tree of focus controllers, with parent controllers always having
precedence over their children when making the checks, but with children
maintaining individual state.

Hmmm, this could help solve some issues for faster back/forward performace via
persistant docshells too (something Hyatt and I were talking about for Chimera).
Comment 6 Jesse Ruderman 2002-04-13 19:53:26 PDT
*** Bug 135951 has been marked as a duplicate of this bug. ***
Comment 7 Julien Wajsberg 2002-04-27 08:29:06 PDT
See also bug 125282 - Google steals focus when it's in the location bar.
Comment 8 Jesse Ruderman 2002-04-28 12:41:33 PDT
*** Bug 138195 has been marked as a duplicate of this bug. ***
Comment 9 Shanan Holm 2002-06-27 19:27:07 PDT
Note that not only does the focus get stolen by a form on another tab, the tab
itself doesn't come into focus. This makes it possible to type personal
information (login names, passwords etc) into a form on a different
(non-visible) tab.
Comment 10 Vidar Haarr (not reading bugmail) 2002-07-19 09:24:58 PDT
*** Bug 158270 has been marked as a duplicate of this bug. ***
Comment 11 Boris Zbarsky [:bz] (Out June 25-July 6) 2002-07-23 00:53:43 PDT
*** Bug 158786 has been marked as a duplicate of this bug. ***
Comment 12 Michael Lefevre 2002-09-10 03:38:16 PDT
*** Bug 167677 has been marked as a duplicate of this bug. ***
Comment 13 jag (Peter Annema) 2002-09-11 18:53:27 PDT
Created attachment 98819 [details]
testcase

This sets the focus to a text input field on a 3 second timeout, which should
give you enough time to (re)load this attachment and open a new tab.
Comment 14 jag (Peter Annema) 2002-09-11 18:53:53 PDT
*** Bug 167110 has been marked as a duplicate of this bug. ***
Comment 15 Robert Wall 2002-09-16 09:33:36 PDT
*** Bug 168761 has been marked as a duplicate of this bug. ***
Comment 16 WD 2002-10-20 13:57:23 PDT
*** Bug 175596 has been marked as a duplicate of this bug. ***
Comment 17 Thibault G. 2002-10-23 09:31:50 PDT
Don't you think this bug deserves a "major" severity ?

I've found several times my password readable in the google bar
(or similar) due to this bug ...
If someone had been behind me, it could have been a real
security issue !
Comment 18 Robin Green 2002-10-24 04:32:31 PDT
upgrading severity to "major" as per prev comment
Comment 19 Sander 2002-10-31 11:25:11 PST
*** Bug 177758 has been marked as a duplicate of this bug. ***
Comment 20 Torben 2002-11-05 04:50:24 PST
*** Bug 178400 has been marked as a duplicate of this bug. ***
Comment 21 Jesse Ruderman 2002-11-06 13:52:24 PST
See also bug 120148, "Tabs don't remember which element was focused when
switching tabs".  It would be nice if Mozilla could keep track of focus changes
in background tabs rather than just ignoring them.
Comment 22 Hasse 2002-12-04 11:01:33 PST
*** Bug 182307 has been marked as a duplicate of this bug. ***
Comment 23 Andrew Schultz 2002-12-08 06:30:06 PST
*** Bug 184183 has been marked as a duplicate of this bug. ***
Comment 24 Ilya Gulko 2002-12-11 21:49:23 PST
Also happens in this build of Phoenix; Not sure how to report this...
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5
Comment 25 Larry Alton Garrett 2003-01-01 09:07:19 PST
*** Bug 187340 has been marked as a duplicate of this bug. ***
Comment 26 Hasse 2003-01-01 22:14:04 PST
*** Bug 187391 has been marked as a duplicate of this bug. ***
Comment 27 Andreas Kunz 2003-01-12 17:02:25 PST
Created attachment 111365 [details]
Another (more luxurious) testcase

I made another testcase that uses a button with delay for setting .focus() to a
textbox for easier testing. Pretty self-explanatory...

I think this bug also causes bug 124638, one of the things I don't like at all
about chatzilla. (But since it might be fixed by working around this bug I
suggest leaving the other bug open, maybe marking it as depending on this bug
here...)
Comment 28 R.K.Aa. 2003-01-25 16:11:44 PST
*** Bug 186958 has been marked as a duplicate of this bug. ***
Comment 29 Sander 2003-02-03 10:48:04 PST
*** Bug 191744 has been marked as a duplicate of this bug. ***
Comment 30 Robert Wall 2003-02-25 11:01:26 PST
*** Bug 194919 has been marked as a duplicate of this bug. ***
Comment 31 Daniel Wang 2003-03-05 10:45:48 PST
*** Bug 195988 has been marked as a duplicate of this bug. ***
Comment 32 Sander 2003-03-21 12:49:01 PST
*** Bug 198541 has been marked as a duplicate of this bug. ***
Comment 33 noririty 2003-04-03 02:47:45 PST
*** Bug 200338 has been marked as a duplicate of this bug. ***
Comment 34 Sander 2003-04-04 14:48:25 PST
*** Bug 200575 has been marked as a duplicate of this bug. ***
Comment 35 Hasse 2003-04-26 00:27:15 PDT
*** Bug 203426 has been marked as a duplicate of this bug. ***
Comment 36 sairuh (rarely reading bugmail) 2003-05-12 15:34:55 PDT
*** Bug 194104 has been marked as a duplicate of this bug. ***
Comment 37 sairuh (rarely reading bugmail) 2003-05-12 15:37:54 PDT
another page to test with, http://bugzilla.mozilla.org/

see also bug 120148, which might block this one, depending on what we want as
expected behavior.
Comment 38 Samir Gehani 2003-05-12 16:43:43 PDT
adt: nsbeta1-
Comment 39 tironsi 2003-06-01 21:12:05 PDT
*** Bug 206784 has been marked as a duplicate of this bug. ***
Comment 40 Kai Lahmann (is there, where MNG is) 2003-06-02 14:38:59 PDT
*** Bug 207993 has been marked as a duplicate of this bug. ***
Comment 41 noririty 2003-06-19 09:43:32 PDT
*** Bug 209960 has been marked as a duplicate of this bug. ***
Comment 42 Hasse 2003-06-27 07:40:04 PDT
*** Bug 210837 has been marked as a duplicate of this bug. ***
Comment 43 Matthias Versen [:Matti] 2003-06-28 02:18:07 PDT
*** Bug 210431 has been marked as a duplicate of this bug. ***
Comment 44 Hasse 2003-07-02 09:06:23 PDT
*** Bug 211255 has been marked as a duplicate of this bug. ***
Comment 45 Matthias Versen [:Matti] 2003-07-19 10:34:41 PDT
*** Bug 213169 has been marked as a duplicate of this bug. ***
Comment 46 Aleksey Lazar 2003-08-09 22:49:47 PDT
I am not sure if textbox.focus is to blame, but the focus stealing between tabs
is  more than just a severe annoyance. Can it be fixed? Or whatever this bug is
dependent on? Trying to log in to my email account with a search phrase is
time-wasting, but trying to search for my online banking password on Google is a
greater concern. Thanks.
Comment 47 Sebastian Biallas 2003-08-10 03:00:11 PDT
*** Bug 215631 has been marked as a duplicate of this bug. ***
Comment 48 Jesse Ruderman 2003-08-12 15:16:07 PDT
*** Bug 215966 has been marked as a duplicate of this bug. ***
Comment 49 Oleg Sidletskiy 2003-08-13 01:55:15 PDT
*** Bug 216020 has been marked as a duplicate of this bug. ***
Comment 50 paul stanton 2003-09-02 00:55:40 PDT
Each tab has it's own DOM right? So why should they share (or rather fight over)
the focus? I think 120148 is caused by the same problem, which is (and I haven't
looked at the code) that the browser, tabs or no tabs, has only one focus token.
Thus, when it changes in one DOM, it is essentially stealing it from the
previous tabs DOM. As has been previously stated, this is a **SECURITY CONCERN**
as well as a major pain in the ass, and I can't see it taking too long to
fix/test, so please, somebody fix it!
Comment 51 David Balažic 2003-09-10 08:30:28 PDT
This is still here in v1.4 ( on winXP ).

Is is very confusing, as I have set the middle button to open in new tab and
selected the "load links in background" option.

So when I middle click on a link, a new tab is created but is not switched to.
The old tab remains visible and has focus. But when this bug occurs, the tab in
the background steals the focus ( but still remains in the background ).

Please fix it ! ;-)
Comment 52 Bob Firth 2003-09-12 07:11:58 PDT
*** Bug 219034 has been marked as a duplicate of this bug. ***
Comment 53 Alexander Opitz 2003-09-17 06:59:52 PDT
Can we make this blocking 1.5?
Comment 54 Alexander Opitz 2003-09-17 07:18:43 PDT
138646 may depend on this bug
Comment 55 tironsi 2003-09-17 19:32:10 PDT
Something just happened to me that might be related to this bug. I had two
different Mozilla windows open, one was blank, the other had Yahoo games open. I
clicked on a bookmark (google from personal toolbar) from the window in the
foreground, and immediately the window that was in the background came to the
foreground and started loading google. Yahoo games uses java and/or javascripts
and does come to the foreground while it's loading. I don't understand why it
would load a page though since it was linked from a different window, and the
window that loaded it didn't even have a personal toolbar showing.
Comment 56 Oleg Sidletskiy 2003-09-26 00:25:53 PDT
*** Bug 220337 has been marked as a duplicate of this bug. ***
Comment 57 Boris Zbarsky [:bz] (Out June 25-July 6) 2003-09-26 02:26:03 PDT
*** Bug 220344 has been marked as a duplicate of this bug. ***
Comment 58 Jack Angel 2003-09-26 03:15:37 PDT
judging from the number of found duplicate bugs, this is a HOT issue.
you folks gotta fix it soon
Comment 59 paul stanton 2003-09-28 02:01:29 PDT
this bug hasn't even been confirmed by the mozilla team. don't expect it to be
fixed in a hurry. sad but true.
Comment 60 Vaclav Dvorak 2003-09-28 15:38:37 PDT
paul: There's even a testcase contributed by jag, most definitely a "member of
the Mozilla team" in my books. And the bug is not in the "unconfirmed" state.

However, this bug depends on bug 120148 being fixed, which has a patch, but for
some reason it's not checked in (or if it is, it's not working). I'd say there
is hope.
Comment 61 cato 2003-09-29 18:35:10 PDT
Created attachment 132382 [details]
real world test case

1) type in www.hotmail.com in location bar.
2) click CTRL-T for a new tab.
3) type in www.slashdot.org
4) halfway through typing new URL, the hotmail username box steals focus, and
the last half of the new URL end up there. (without the old page jumping to the
fore)

solution should be a user preference: option 1 and default: prevent pages from
stealing focus. option 2: allow pages to steal focus and bring them to the
front.
Comment 62 Jesse Ruderman 2003-09-29 21:52:33 PDT
*** Bug 219927 has been marked as a duplicate of this bug. ***
Comment 63 Malcolm Davis 2003-09-30 01:59:31 PDT
I agree with cato in Comment #61.

Such an approach seems a good solution to this annoying problem. How hard would
it be to code this?
Comment 64 Marat Khalili 2003-09-30 04:32:58 PDT
I disagree with Comment #61: this must not be a user preference, at least not in
this form. Browser behavior should be predictable from web-designer's view. Thus
preferences like "Interpret this command this or that way" are not correct. User
should only see preferences like "Allow scripts to do this" and "Disallow
scripts to do that", clearly limiting scripting capabilities.

Moreover, there're two kinds of focus() calls now: window.focus() brings window
to top while input.focus() makes form input active inside the window.
window.focus() currently does not change opened tab; also, it can be completely
switched off in preferences (Scripts&Plugins - Allow scripts to - Raise or lower
windows").

window.focus() must be fixed to open correct tab anyway. input.focus() can be
changed to open page's tab too - this would be easy to implement but IMHO it's
not completely correct.

I believe that only correct fix for input.focus() would be to keep separate
record of active control for each tab. This might be done by mozilla;
alternatively each tab can be made separate window from the Windows/WM view.
Latter is possible but would probably cancel out all advantages of tabbed
browsing from the speed and memory point of view. Former is harder but must have
been done when tabbed browsing was introduced.
Comment 65 Stewart 2003-10-01 08:05:46 PDT
*** Bug 218023 has been marked as a duplicate of this bug. ***
Comment 66 Jon Henry 2003-10-14 10:03:21 PDT
*** Bug 210367 has been marked as a duplicate of this bug. ***
Comment 67 Matthias Versen [:Matti] 2003-10-16 13:02:28 PDT
*** Bug 222483 has been marked as a duplicate of this bug. ***
Comment 68 Taj Morton 2003-11-12 12:52:35 PST
*** Bug 224564 has been marked as a duplicate of this bug. ***
Comment 69 Vaclav Dvorak 2003-11-16 20:27:43 PST
It seems to me that the solution would be to modify nsHTMLInputElement::SetFocus
and nsHTMLInputElement::Select so that after
"focusController->GetActive(&isActive)" (which sets isActive to TRUE if the
element's window has focus), it would do:

if (isActive && this element's tab not active) {
  set this element's tab's focusedElement property (see bug 120148) to self;
  return NS_OK;
}

Sounds simple. Unfortunately, I need help with the pseudocode parts. :-) I.e.:
1) How do I tell whether the nsHTMLInputElement is in a tab that is active?
2) How can I access the tab's properties?
Sorry, I'm a complete Mozilla hacking newbie. But with advice from someone more
knowledgable, perhaps I can fix this. Thanks!
Comment 70 Matthias Versen [:Matti] 2003-11-21 10:43:19 PST
*** Bug 226448 has been marked as a duplicate of this bug. ***
Comment 71 Matthias Versen [:Matti] 2003-12-05 11:53:18 PST
*** Bug 227569 has been marked as a duplicate of this bug. ***
Comment 72 chris hofmann 2003-12-10 16:50:29 PST
too late to get anything done on this for 1.6, maybe bryner can get some work
done on this for 1.7
Comment 73 Oleg Sidletskiy 2003-12-16 03:26:21 PST
*** Bug 228641 has been marked as a duplicate of this bug. ***
Comment 74 Jesse Ruderman 2004-01-12 19:41:00 PST
*** Bug 230745 has been marked as a duplicate of this bug. ***
Comment 75 Oleg Sidletskiy 2004-01-20 19:46:26 PST
*** Bug 231601 has been marked as a duplicate of this bug. ***
Comment 76 Asa Dotzler [:asa] 2004-03-08 16:26:42 PST
Would be nice to get for 1.7. Setting an optimistic blocking flag.
Comment 77 Asa Dotzler [:asa] 2004-03-09 15:51:38 PST
*** Bug 200231 has been marked as a duplicate of this bug. ***
Comment 78 Asa Dotzler [:asa] 2004-03-09 22:48:32 PST
*** Bug 210401 has been marked as a duplicate of this bug. ***
Comment 79 Asa Dotzler [:asa] 2004-03-09 22:48:54 PST
*** Bug 200942 has been marked as a duplicate of this bug. ***
Comment 80 Asa Dotzler [:asa] 2004-03-09 22:49:09 PST
*** Bug 196646 has been marked as a duplicate of this bug. ***
Comment 81 R.K.Aa. 2004-03-15 06:32:51 PST
*** Bug 237529 has been marked as a duplicate of this bug. ***
Comment 82 chris hofmann 2004-03-15 11:46:15 PST
no patch yet, minus for 1.7b
Comment 83 Joachim Noreiko 2004-03-15 12:09:59 PST
Your help system does not explain what "minus for 1.7b" means.
From the number of duplicates (and the security problem) I would say that this
is a critical issue. Releasing another version of Mozilla with this unfixed will
seriously damage the project's reputation, IMO. Most Mozilla users I know have
been waiting for this to be fixed for a long time.
Comment 84 paul stanton 2004-03-15 12:21:19 PST
very true. just look at the number of duplicates. 52 and counting!!!!!!!
Comment 85 Peter Kroll 2004-03-15 12:24:53 PST
I agree. This is also a gapping security hole. It's easy to type in a password
in  a form in another tab and submit without knowing.
Comment 86 Ilya Gulko 2004-03-15 12:42:59 PST
Disclaimer: I am not a Mozilla developer. I have never even touched the Mozilla
source code. However, I have done some OO development.

This seems like a relatively easy bug, especially if you only want to patch up
the current security issue.

function focus_subroutine() {
	if (this_tab != active_tab) {
		this_tab.control_to_focus = this_control
		return
	}
	// normal focusing code here
}

function this_tab_is_activated() {
	if (this_tab.control_to_focus) {
		this_tab.control_to_focus = null
		set_focus_to this_tab.control_to_focus
	}
}
Comment 87 Vaclav Dvorak 2004-03-15 14:20:37 PST
Without intending to criticize anyone, I can't fail to notice how the "blocking"
flag doesn't really mean what it pretends to. Apparently, when it turns out that
a release would, indeed, have to be blocked before a blocking bug could be
fixed, the drivers conveniently change their minds. :-)

Anyway, if anyone with knowledge of the relevant parts of Mozilla code could
spare a few moments to look into this and give some advice, I'd love to take
another peek at the problem. Please see my comment 69 for how I thought the
problem might be fixed and the questions I had. Thanks!
Comment 88 Christopher Aillon (sabbatical, not receiving bugmail) 2004-03-15 14:41:42 PST
Comment 4 and comment 5 describe the problem from a code perspective.  Comment
69 is somewhat misguided because nsHTMLEditor has no way of knowing what a tab is.
Comment 89 Christopher Aillon (sabbatical, not receiving bugmail) 2004-03-15 14:49:09 PST
Er, I meant nsHTMLInputElement.
Comment 90 Brendan Eich [:brendan] 2004-03-15 15:11:40 PST
Comment 87's first paragraph is way out of line in any bug, and wrong too, in
general.  Every single past milestone release has been blocked by must-fix bugs
that were marked blocking (or noted as such before the request flag system was
added to bugzilla), and shipped only when some kind of fix or workaround was
developed.

It's easy to verify this with bugzilla.  It's also easy to find bugs that were
marked blocking, then changed when reconsidered.  Not having a fix does not mean
a bug should not block a milestone, but it's hard to justify holding a release
if no fix is in sight.

Why this bug was marked blocking1.7b+ and then blocking1.7b- is suggested by
chofmann's terse comment 82 ("no patch yet, ...").  This bug may still block 1.7
final, but we need to get 1.7b out and collect talkback, user feedback, and user
 bug reports, and without a patch here, the value of timely feedback for the
product as a whole outweighs the value of making everyone wait for 1.7b till
this bug has a patch.

However, since 1.7b is not done yet, there's still a chance to pick up a fix for
this bug, even though we won't hold 1.7b for this bug.

Anyway, bryner is on the case.  Please settle down, and try to tell the truth
about bugs and how they have and have not blocked, and should and should not
block, milestone releases.  If you disagree with any of drivers' decisions, mail
drivers@mozilla.org, post to the newsgroups.

/be
Comment 91 Brian Ryner (not reading) 2004-03-15 15:30:45 PST
There are three ways this could be addressed that I see:

1. Fix the focus controller object ownership so that it is per-tab.  Currently
it is per toplevel window, so when we try to see whether we're "active", when
.focus() is called, we believe we are because the toplevel window is indeed
active.  This could be done either by making focus controllers be per-docshell,
or by making each tab be a new Gecko instance.  Neither of these are a light
undertaking... moving the focus controller onto the docshell means that you have
to worry about a chain of focus controllers; making each tab be a separate Gecko
instance would require some thought to get events to bubble up into the chrome
since the documents would no longer be connected.

2. Have tabbrowser install a capturing focus listener on the DOM window of each
tab.  If the tab is ianctive, call stopPropagation() on the event to prevent any
focus change from happening.  It could also update the focus memory on the tab
(using the event target) so that the element is focused when you switch to that
tab.  Easier, but it adds another row to the Jenga game that is focus.
Comment 92 paul stanton 2004-03-15 15:47:27 PST
no 1 sounds more complete and extensible then no 2
"focus controllers be per-docshell" sounds lighter/more efficient than "each 
tab be a new Gecko instance"

i don't think focus controllers are the only things that need to be "per 
docshell". what about the status bar? the address field icon? are there more?
Comment 93 Az 2004-03-15 17:23:29 PST
Nominating for 1.7 final as it is a _security_ issue.
Comment 94 Aleksey Lazar 2004-03-15 20:12:16 PST
Yes, Paul. Same for the "page not found error", which also should be less
intrusive than a pop-up, but that's a different issue.
Comment 95 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-03-23 12:40:24 PST
Approach two sounds best. Any approach is going to add complexity and adding
complexity outside Gecko sounds like a win.
Comment 96 paul stanton 2004-03-23 15:53:09 PST
altho load has to be taken into account. not sure how heavy 30 tabs, each with a
gecko instance would be.
Comment 97 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-03-23 18:03:57 PST
I bet Neil could make a patch for this in a jiffy :-)
Comment 98 neil@parkwaycc.co.uk 2004-03-24 02:27:29 PST
Bryner, can the tabbed browser capture focus events and prevent the focus being
grabbed by a background tab, instead saving the focus for later?
Comment 99 Brian Ryner (not reading) 2004-03-28 00:15:31 PST
(In reply to comment #95)
> Approach two sounds best. Any approach is going to add complexity and adding
> complexity outside Gecko sounds like a win.

I'm not sure about that.  And I don't know that I explained the situation very
well in my previous comment.  Currently a focus controller exists per docshell
tree, which for XUL apps means per toplevel window.  That's why this problem
(likely) doesn't affect embedding apps (i.e. Camino) because in that case the
tabs will be separate docshell trees (that is what I meant by "Gecko
instance"... don't take it to mean duplicate copies of code/data/singletons). 
The background tabs can be deactivated and not steal focus.

I'm not really a big fan of the current focus memory we have in the tabbrowser
code and extending it just seems like it's going to lead to inconsistencies.  We
have several call sites that check whether the focus controller is active, and
that should work exactly the same for a background tab as for a background
window.  We really want these to use the same mechanism, which means attaching
focus controllers to the docshells in each tab.  Chaining them is one way; we
could also think about just forcing the tabs to have new docshell trees.  I
haven't totally thought that one through.  I've pretty much convinced myself
that adding a hack in tabbrowser is going to cause us more pain in the long run.

Perhaps at the same time we could resolve the bad focus API we're providing
embedders -- it's totally unclear when, exactly, they should call
nsIWebBrowserFocus::Activate/Deactivate when focus moves out of the gecko
instance but the toplevel window still has focus.
Comment 100 Brian Ryner (not reading) 2004-03-28 00:43:02 PST
Minor correction to my last comment.  Focus controllers are per DOM window tree,
not per docshell tree.  I don't think we can break that chain, so this would
definitely involve moving the focus controller ownership onto a new object -
preferably the DOM window, docshell, or something with an equivalent lifetime
(not something that's destroyed and recreated when new documents load).
Comment 101 neil@parkwaycc.co.uk 2004-03-28 03:25:35 PST
(In reply to comment #98)
>Bryner, can the tabbed browser capture focus events and prevent the focus
>being grabbed by a background tab, instead saving the focus for later?
Whoops, it would have helped if I'd read comment #91 first :-[
Comment 102 neil@parkwaycc.co.uk 2004-03-31 15:01:44 PST
Created attachment 145211 [details] [diff] [review]
Possible patch

This was the best I could do, I couldn't be sure what was trying to take the
focus or how to stop it...
Comment 103 Mike Calmus 2004-03-31 17:48:24 PST
Mozilla locks up for me using the second test case with the patch applied.
Comment 104 neil@parkwaycc.co.uk 2004-03-31 23:53:35 PST
Comment on attachment 145211 [details] [diff] [review]
Possible patch

[Dons asbestos suit]
Comment 105 Brian Ryner (not reading) 2004-03-31 23:57:16 PST
Comment on attachment 145211 [details] [diff] [review]
Possible patch

As I said in my previous comments, I'm not in favor of putting this logic at
this level.
Comment 106 Alfonso Martinez 2004-04-03 03:59:52 PST
*** Bug 239468 has been marked as a duplicate of this bug. ***
Comment 107 Joachim Noreiko 2004-04-10 02:27:28 PDT
There is another problem, which I think is part of the same bug:

A page can steal focus *form itself*: I begin typing in a form while the page is
still loading, and suddenly I find Mozilla has switched to searching in the text
of the page instead.
Comment 108 Serge Gautherie (:sgautherie) 2004-04-10 02:57:28 PDT
(In reply to comment #107)
> A page can steal focus *form itself*: I begin typing in a form while the page is
> still loading, and suddenly I find Mozilla has switched to searching in the text
> of the page instead.

I confirm this. (Trunk: for many milestones)
Comment 109 Max Romantschuk 2004-04-10 07:21:13 PDT
(In reply to comment #107)
> There is another problem, which I think is part of the same bug:
> 
> A page can steal focus *form itself*: I begin typing in a form while the page is
> still loading, and suddenly I find Mozilla has switched to searching in the text
> of the page instead.

This is not a bug. The case you are describing is when a JavaScript snippet
reassigning focus has been recieved by the browser after you have manually
applied focus yourself. This is confusing, but desired behaviour. Otherwise the
focus change would need to be blocked if the user has manually assigned focus,
which in turn would make the whole focus change useless, and not according to specs.
Comment 110 Johnny Stenback (:jst, jst@mozilla.com) 2004-04-10 10:38:40 PDT
Yeah, that's a bug in the script on the page, not a browser bug.
Comment 111 neil@parkwaycc.co.uk 2004-04-10 11:28:28 PDT
I can't see why typeaheadfind is getting triggered, I'd have to try and
duplicate the issue and look to see who's setting focus where, but I'd have
thought it unusual for the page to set focus to its own canvas.
Comment 112 José Jeria 2004-04-16 17:44:37 PDT
*** Bug 240751 has been marked as a duplicate of this bug. ***
Comment 113 Asa Dotzler [:asa] 2004-04-22 14:30:57 PDT
doesn't look like we've got anything in sight for 1.7 and bryner's busy with
other work. If neil or anyone else on this bug can come up with a patch that
passes reviews, please request approval. 
Comment 114 Charles Fenwick 2004-04-26 17:18:12 PDT
*** Bug 241813 has been marked as a duplicate of this bug. ***
Comment 115 Oleg Sidletskiy 2004-04-28 16:18:22 PDT
*** Bug 242016 has been marked as a duplicate of this bug. ***
Comment 116 José Jeria 2004-05-12 14:06:19 PDT
*** Bug 243446 has been marked as a duplicate of this bug. ***
Comment 117 José Jeria 2004-05-15 04:05:57 PDT
*** Bug 243685 has been marked as a duplicate of this bug. ***
Comment 118 black-hole 2004-05-15 05:10:12 PDT
Thanks for lighting my path, José. And sorry for the duplicate I caused (OMG, I
see more than 10 dupes here...uh-oh). 
Same problem with all my versions of Moz.. (noticed problem since around 1.2
(the one where I started to discover what a fine thin tabbed brwosing is))
A small workaround for non-programming users (users!) would be to switch Java
Script dynamically off with the prefbar-plugin while typing. Of course that's
not a nice solution and you have to switch it back on since a lot of sites
require that *grrrr* JavaScript. And you have to mouseclick 2 times for it. And
that's the thing I wanted to avoid. With enabled JS it also needs mouseclicks,
so it isn't any better at all.

Security issue: yes, also for me, since I also type my passwords then as logins
or search terms (and pressed return after it)... so google or something went
searching the www with my password or logging some other mail in with my pass.

A question: Would anyone think that this focus stealing issue could also be
responsible for odd cursor behavior when (shift)-ctrl-tabbing around and
attempting to scroll the pages up and down with the cursor keys (also often
requires me to re-click a page to activate the cursor in it)? On the other hand
it seems that in these cases there's no JS active that could just steal it.
Comment 119 José Jeria 2004-05-26 06:11:43 PDT
*** Bug 244726 has been marked as a duplicate of this bug. ***
Comment 120 TATMF 2004-06-05 14:10:02 PDT
(In reply to comment #119)
> *** Bug 244726 has been marked as a duplicate of this bug. ***

Sorry for that new duplicate :p
There's something I can't explain: if there is only *one* focus per window, how
is it that INPUTs keep focus when nothing else (JS:focus() or page load) happens?

In most cases, I can type in a form, then do the same in another tab, and back
again. I will still type in the right form, without re-focusing...

BTW, I don't want to create another dup. But there is something "strange" with
javascript (FireBird, but not MoZilla, I think): with document.onmousedown or so
disabled (to prevent unwished actions like selecting text/context menu...), I
can't set focus on form elements with my mouse!
Comment 121 Bill Mason 2004-06-15 11:57:56 PDT
*** Bug 246893 has been marked as a duplicate of this bug. ***
Comment 122 Az 2004-06-20 07:40:34 PDT
Asking for blocking as it is a security issue.  Would be great if this could get
done before Firefox hits 1.0
Comment 123 Zach Spoelstra 2004-06-23 08:01:36 PDT
*** Bug 247162 has been marked as a duplicate of this bug. ***
Comment 124 Robin Monks 2004-06-30 07:52:51 PDT
*** Bug 242894 has been marked as a duplicate of this bug. ***
Comment 125 David A. Cobb 2004-06-30 09:26:21 PDT
Maybe redundant, as you have identified this with JavaScript:

Follow-up to Bug#242894 --
One event I can correlate this to in Thunderbird -- If I have a message
standalone on top of the Z-order and there is incomming mail, the summary view
updating the "nnn unread / mmm total" counters pops the summary view to the top.  

On several occasions it has appeared that using a keystroke input to a window
causes that window to loose the focus.  I flag a message "J"unk and wind up with
"Cottonelle Puppy" on top, so the next keystroke action is missed.
A 'fast' click on the scrollbar seems to do the same.

Since I'm seeing this in T-bird, perhaps the component as shown is too narrow.
Comment 126 R.K.Aa. 2004-07-05 16:21:45 PDT
*** Bug 249895 has been marked as a duplicate of this bug. ***
Comment 127 tironsi 2004-07-09 10:26:14 PDT
What's the point of adding blocking tags to this bug? It's obvious that it
doesn't really block anything. It's been reported over two years ago, it has 61
votes, it's a security risk and very annoying, and yet it's not been fixed. Why
not just mark it as WONTFIX?
Comment 128 Joachim Noreiko 2004-07-09 11:53:38 PDT
(In reply to comment #125)
> Since I'm seeing this in T-bird, perhaps the component as shown is too narrow.

I've just reproduced it in Firefox 0.8.
Comment 129 Alfonso Espitia 2004-07-10 13:47:48 PDT
I have to agree with 127, I don't understand how the shell exploit gets fixed in
13 hours, but this one has been around for years.  It seems that nobody knows
how to fix it, or doesn't understand the problem completely.  And yes, to 128, i
can reproduce in firefox .8, .9, .9.1, Mozilla 1.7 and 1.7.1.
Comment 130 Oleg Sidletskiy 2004-07-11 03:14:16 PDT
*** Bug 250851 has been marked as a duplicate of this bug. ***
Comment 131 Mathieu Pellerin 2004-07-12 04:23:26 PDT
This should block any future release (it should have been fixed months ago
anyway) - I dont know how many times I start to type an url in a new tab to
found half of it is in a login text box that was focused by another time...
highly irritating (enough for me to think of switching to opera for 1 min ...
then came back but that's another story :) ) ...

It also happens evey now and then that I think I'm writing my password in a safe
way (thinking that it is hidden by *** ) to find out I was writting it in
another input box in a new tab ... so either I jump to this tab and erase the
text (but anyone could see my password or at least part of it for 1sec) or I
close the tab and reload it (and decide to lose time andwait until the page is
fully loaded before going back to type my password)

please think of doing a little trick in the code to avoid this bug quickly and
do a full patch later when you have more time (even though I think someone
should be assigned to fix this asap)
Comment 132 Richard Corbin 2004-07-12 12:08:41 PDT
(In reply to comment #131)
> This should block any future release (it should have been fixed months ago
> anyway)

I fully agree with the above comment. I too have had my password appear in
another tab's input box, and didn't realise at the time what had happened. I
then re-typed my password and logged in to check my online email. The other tab
still had my password in the input box. I went for dinner, and later on my mum
asked me what the strange string of characters was. I said it was my password!
Clearly it didn't matter too much cos she's my mum, u know ;-)

But I could have been in an office, or at a school/college/university where the
consequences could have been a lot more serious.

Please fix ASAP.
Comment 133 Max Romantschuk 2004-07-12 22:23:31 PDT
As explained by Brian Ryner earlier, fixing this issue is not trivial.

Taking that into account, how hard would it be to simply block focus changes
from a non-active tab? I suspect focus changes not happening are much better
than focus changes happening behind our backs.

This would effectively solve the security issue, and a proper fix could be
developed later. Thoughts?
Comment 134 David A. Cobb 2004-07-14 21:26:47 PDT
Re: "Taking that into account, how hard would it be to simply block focus changes
from a non-active tab?"

Sounds like a plan.  Now then, WHY IN BLAZES should a non-active element (tab or
whatever ) have a legitimate reason to steal focus???  If it in trouble, it
should pop an alert, otherwise it should just update its internal rendition of
the display and let the content be repainted when the UNCOVERED message comes in
[ I can't think of the name! ]

The whole point, I thought, of all this GUI and message passing and all that
complexity is giving the user the illusion that he is in charge!  If you keep
changing focus without the user asking for it, you destroy the illusion and make
using the product a rather unpleasant experience.  
Comment 135 paul stanton 2004-07-14 21:33:49 PDT
i agree with comment 133. hey, that rhymes! must be the right thing to do then.
Comment 136 Francois Ingelrest 2004-07-21 23:29:52 PDT
*** Bug 252504 has been marked as a duplicate of this bug. ***
Comment 137 R.K.Aa. 2004-07-25 08:15:53 PDT
*** Bug 252995 has been marked as a duplicate of this bug. ***
Comment 138 CrazyDave 2004-07-27 02:57:42 PDT
Easier example

Just ctrl-click or middle-click on the google URL above, google will load (and
steal focus) in a new non-active tab. Type something and press return.

Happens with gmail too.
Comment 139 Ted Mielczarek [:ted.mielczarek] 2004-07-29 10:53:00 PDT
*** Bug 245056 has been marked as a duplicate of this bug. ***
Comment 140 Ted Mielczarek [:ted.mielczarek] 2004-07-29 10:56:48 PDT
*** Bug 245269 has been marked as a duplicate of this bug. ***
Comment 141 Stefan Straßer 2004-08-04 01:33:22 PDT
So, may I ask what is wrong with the "Possible patch" above?
As much as I understand from the source(and I have no clue about mozilla
architecture): it prevents background tabs from stealing the focus, which is not
the ideal solution(that would be a focus for each tab or remembering the focused
element to be able to change it on tab change), but is _much_ better than now.
Comment 142 bugzilla.mozilla.org 2004-08-04 09:32:38 PDT
The only real problem with using a patch that isn't the ideal solution is that
it just gives everyone another reason not to come up with the ideal solution.

On a side note, Bug 245502 (the firefox-only version of this bug) is marked as
blocking aviary1.0. Should this bug be marked blocking as well? After all, it
*is* a security issue.
Comment 143 Mike Calmus 2004-08-04 12:43:20 PDT
(In reply to comment #141)
> So, may I ask what is wrong with the "Possible patch" above?

Take a look at my comment #103. The patch didn't really work, at least not for me.
Comment 144 Alfonso Espitia 2004-08-05 06:02:30 PDT
does this mean we all get the $500 for reporting the bug? :)
it's been "in the works" for well over 2 years now...
Comment 145 Peter Kroll 2004-08-07 19:39:52 PDT
I cannot stress enough that whatever efforts are needed to solve this problem,
whether it's a hack or a proper fix it needs to be taken immediately.

It's plain to see that it's not an easy fix and no one wants to do it, but with
all the criticism that we through at the MS camp for sitting on big security
bugs. We really should focus on this bug. 
Comment 146 Mathieu Pellerin 2004-08-07 19:45:44 PDT
extract of Mozilla Security Bug Bounty FAQ
http://www.mozilla.org/security/bug-bounty-faq.html#critical-bugs

"What types of security bugs do you consider to be "critical"?

    In general we consider critical security bugs to be those that allow
execution of arbitrary code on users' systems or that otherwise allow access to
users' confidential information. In the latter case we consider bugs to be
critical only if they potentially expose high-value personal information (e.g.,
passwords, credit card numbers, and the like); [...]"

So dunno but if I were you, I would move the team this fix this problem asap as
it has been sitting there for the last 2 years. You got good press with other
bugs but I guess you wouldn't want a bad article for this bug ...
Comment 147 dave 2004-08-09 13:41:51 PDT
In the case where a textbox is some kind of input that FireFox has remembered an
input for (eg a login name on gmail, or something similar), starting typing
whilst focussed on another tab, and haphazardly hitting the correct sequence to
cause an auto-complete droptdown causes the dropdown to appear over the
currently selected tab.

I was going to report this, along with the potential security risk of having an
inactive tab's text fields steal keyboard focus, but noticed this bug report
whilst trawling bugzilla, and thought I would add the more obvious nature of the
bug (a drop-down appearing in the middle of your current slashdot page, for
instace, when you meant to search the page for a string).

The bug is reproducable every time I try:

1) open a tab & enter gmail.com into the url bar
2) switch to another tab or open a new tab
3) wait the 3-5 seconds for the redirect, and start typing. If the sequence you
type matches one of the sequences that you would log in with, then the drop-down
list appears over the active tab.
Comment 148 Gérard Talbot 2004-08-10 14:23:33 PDT
*** Bug 216811 has been marked as a duplicate of this bug. ***
Comment 149 Ryan Polk (Quark) 2004-08-16 12:34:58 PDT
*** Bug 255787 has been marked as a duplicate of this bug. ***
Comment 150 Logan Ingalls 2004-08-19 11:26:10 PDT
*** Bug 256177 has been marked as a duplicate of this bug. ***
Comment 151 Bill Mason 2004-09-01 09:15:55 PDT
*** Bug 257665 has been marked as a duplicate of this bug. ***
Comment 152 José Jeria 2004-09-11 04:38:30 PDT
*** Bug 258852 has been marked as a duplicate of this bug. ***
Comment 153 Noam Tamim 2004-09-12 03:31:02 PDT
This bug has tens of dupes. I found up about it only after entering my own 
dupe. And yes, I did search the database before entering my bug. I have no idea 
why it wasn't found (and I don't remember what keywords I used).

Anyway, the fact that it has so many dupes, must mean that it annoyes many 
people. Only a small percentage of people encountering such a bug know that it 
is a bug; of those, only a small percentage take the time to report it - and 
yet there are so many of them.

Has it been resolved for Firefox 1.0? It blocks the release...
Comment 154 itsayellow@gmail.com 2004-09-12 17:31:39 PDT
*** Bug 243363 has been marked as a duplicate of this bug. ***
Comment 155 paul stanton 2004-09-12 17:38:44 PDT
don't worry about it. no one at mozilla is.
Comment 156 Brendan Eich [:brendan] 2004-09-13 11:49:56 PDT
Comment 155 is insulting noise.

This bug won't get fixed without significant Gecko focus rearchitecture, which
has not and will not fit into the aviary branch before 1.0.  We will fix it
after 1.0, as soon as is practical.

/be
Comment 157 Mathieu Pellerin 2004-09-13 17:19:59 PDT
can't you create a workaround patch for this one ... it's one of the very very
old bug that affects everyone in its everyday browsing. I wouldnt say it's
insulting for the users to see this kind of _security_ bug hanging around
without a mass focus from the programmers to fix it but...

what went wrong with this bug? how come you prepare yourself for a 1.0 release
and decide to leave a password-revealing bug still present in a final release
(how come there was mozilla suite 1.1, 1.2 , 1.3, ... 1.7 with this bug ?! :) )
just questionning the whole thing
Comment 158 Brendan Eich [:brendan] 2004-09-13 17:36:10 PDT
There were many worse bugs than this one to fix for aviary1.0, and other bugs
that you could say were less serious, but that had to be fixed anyway, and that
could be fixed by a large pool of hackers.

The people who could fix this correctly, on the other hand, are very few (bryner
and who else?), and way overloaded.

The original hackers who made a mess of focus code are long gone, and it's hard
to get anyone to own the code they wrote, although bryner and others have done a
good job fixing the most severe bugs and maintaining the system.

We failed to give this bug priority in the run-up to mozilla1.0, and now for
aviary1.0.  That's a black mark, no excuse.  Sorry; I'll help make sure this
gets fixed on the trunk after the aviary branch lands.

/be
Comment 159 Mathieu Pellerin 2004-09-13 18:01:22 PDT
thanks for the honest comment. I know I'm posting a useless post but that's one
of the best social answer I've read in bugzilla for a very long time.
Comment 160 black-hole 2004-09-13 23:13:06 PDT
Well, good to hear that Mozilla developer folks will have an eye on it now. 
Comment 161 Kirill Grouchnikov 2004-09-14 05:21:41 PDT
Well, guys,
If you wish to create a *REAL* alternative to the IE, this kind if bug can't
ever be around for 2.5 years. That's about 900 days to fix it, even if it means
serious changes to the underlying mechanism. May be this really is not the place
to discuss it, but the only reason a bug like this isn't exploited is that not a
lot of people use Firefox, so the heavyweight hackers don't bother investing
their efforts in it. This kind of bug needs to get fixed right away and not sit
around and wait forever. I understand that it's an open source project and that
good people are hard to come by, but this kind of attitude could really hurt
Firefox's reputation.
The only thing standing between this bug and "Firefox allows stealing sensitive
information" smeared all over the web is that (as of now) no one really enters
sensitive information to Firefox, they are either using IE because it's there,
or because the web site supports IE only.
Comment 162 Stefan Straßer 2004-09-15 01:08:44 PDT
I still suggest using a workaround(like disabling focus() if tab is in
background) until it's fixed, which should be easy to implement and can't be
distinguished from the real fix by the average user.

The only argument against this I've heard so far is that no one will pay
attention to fixing a bug with a workaround. Not a legitimate argument imo.

-- 
Stefan

(this bug just happened while typing this :D
using a word translation website on another tab)
Comment 163 Peter Kroll 2004-09-15 18:30:42 PDT
I agree wholeheartedly. Changing focus rules won't break any websites as
javascript focus is just a convience tool. Please fix the gaping security whole
even if it's quick and dirty. Don't release FireFox with this bug. Back in the
Pheonix days the browsers release schedule was based on bug fixes not deadlines.
Don't forget where you came from.

Mozilla is getting ridiculous because I've been living with noticiable bugs like
this one for years. My understanding of open source was that you could report
bugs and they would get fixed quickly. This is still better than IE. But serious
effort has to be put to bug cleanup. There will always be bugs, but bugs which
are gaping security whole or large annoyances should not exist. The fact that we
track bugs with large community interest is a bad thing. There should be no bugs
that are that noticiable and disturb that many people.
Comment 164 paul stanton 2004-09-15 19:21:49 PDT
comment 163 is spot on
Comment 165 Robert Parenton 2004-09-15 19:22:36 PDT
Please take this to the forums and stop spamming the bug.  The last 4 comments
have been pointless.
Comment 166 Jose Elias 2004-09-15 19:29:07 PDT
This makes me wonder (no sarcasm) if what we're seeing is the beginning of what
could ultimately become the doom of open source: Developers will only do what's
interesting or easy for them to do, unlike a for-profit corporations where a
manager makes a developer fix things or else fire the developer.

In the open source world we have to count on the good will of people. In the
corporate world companies do what makes them money. So philosophically speaking,
it's really a two-sided issue: Good Will vs Money-Making.

I'm therefore asking myself, will there always be good people willing to give
their time to fix things nobody else wants to fix? Will there always be people
with the skills to fix things that bothers them?

I'm not saying this will be the doom of open source, I'm just saying that a bug
like this that has stayed unfixed for such an extremelly long time, and that has
affected so many people, is something for all of us to worry about.

So, should we modify the open-source model to bring money into the equation?
Maybe a bounty-based system for the biggest bugs? I'd be willing to donate a
couple of dollars to whoever fixes this bug, and that would make me happy, and
the person who made the fix happy too, specially since I'm sure I'm not the only
one willing to pay to have this fixed.
Comment 167 Joachim Noreiko 2004-09-16 02:10:00 PDT
I have a suggestion for a simple workaround: add a user option to disable
focus() entirely.

Comment 168 Mathieu Pellerin 2004-09-16 02:23:48 PDT
cannot be that ... we are talking about a password revealing bug. It has to be
either a complete fix or a workaround enabled by default (totaly disabling focus
in javascripts can't be ON by default).

the best solution would be to ignore the focus functions outside of the current
active tab. I dunno how quick this can be inserted into the actual code though.
Comment 169 Mathias Homann 2004-09-16 02:40:02 PDT
so what does it need to get this fixed?
a CERT advisory? a /. article?
it cannot be that difficult to introduce something like this into the .focus()
handler...

if(thistab.visible()) {
//stuff to handle the .focus() stuff
}

just my .02€
Comment 170 José Jeria 2004-09-19 11:24:21 PDT
*** Bug 259168 has been marked as a duplicate of this bug. ***
Comment 171 Daniel Veditz [:dveditz] 2004-09-20 11:16:41 PDT
*** Bug 260580 has been marked as a duplicate of this bug. ***
Comment 172 José Jeria 2004-09-21 02:55:42 PDT
*** Bug 260719 has been marked as a duplicate of this bug. ***
Comment 173 Frank Wein [:mcsmurf] 2004-09-21 07:56:13 PDT
*** Bug 260774 has been marked as a duplicate of this bug. ***
Comment 174 Jeff Parsons 2004-09-22 20:33:49 PDT
(In reply to comment #169)
> so what does it need to get this fixed?
> a CERT advisory? a /. article?
> it cannot be that difficult to introduce something like this into the .focus()
> handler...
> 
> if(thistab.visible()) {
> //stuff to handle the .focus() stuff
> }
> 
> just my .02�

We still want the text box to gain focus /within/ its own tab, just not move the
imput focus over... however that's managed internally...

*bump* yes, this bug has been annoying me!
Comment 175 Mathias Homann 2004-09-22 22:49:45 PDT
you people can want to "do this right" in some later version, but this is a 
password stealing bug. there should have been a workaround since 2 1/2 years! 
 
especially with the possibility to set a group of pages as your home page. 
 
my suggestion: a quick&dirty workaround like "disable .focus() when the page 
is not in the currently visible tab", and "do it right" in your own time. 
 
Comment 176 paul stanton 2004-09-22 23:08:31 PDT
someone do something.. if its just to stop all the bugspam it's worth a couple
of hours attention. i wish i could be bothered to pull down the source on this
dialup connection ;)
Comment 177 Johnny Stenback (:jst, jst@mozilla.com) 2004-09-23 15:01:54 PDT
Created attachment 159903 [details] [diff] [review]
Drop focus events on the floor if they happen in hidden tabs.

This aint what we really want, but it's better than what we've got, so I'm
proposing we take this change until we get the time to figure out the real fix
for this.
Comment 178 Johnny Stenback (:jst, jst@mozilla.com) 2004-09-23 16:51:46 PDT
Created attachment 159914 [details] [diff] [review]
Less scary approach, only drop focus changes that come from direct DOM calls.
Comment 179 Johnny Stenback (:jst, jst@mozilla.com) 2004-09-27 16:50:29 PDT
Created attachment 160278 [details] [diff] [review]
Even less scary, and more "correct" hack

Thanks to bryner I re-checked my failed attempts at using
nsDocShell::GetVisibility() to determine if a tab is hidden or not, and it
turns out that that does work, even though my initial tests didn't show that
(no idea why). So this is getting pretty close to as good as it'll get for
aviary...
Comment 180 Johnny Stenback (:jst, jst@mozilla.com) 2004-09-27 17:16:37 PDT
Re-setting blocking aviary and 1.7.x, now that we have a feasable workaround.
Comment 181 Brendan Eich [:brendan] 2004-09-27 17:24:26 PDT
Comment on attachment 160278 [details] [diff] [review]
Even less scary, and more "correct" hack

Thanks, jst!  a=me for branches.

/be
Comment 182 Johnny Stenback (:jst, jst@mozilla.com) 2004-09-27 21:08:12 PDT
Workaround landed on the aviary and 1.7 branches.
Comment 183 Dean Tessman 2004-09-27 22:06:32 PDT
*** Bug 245502 has been marked as a duplicate of this bug. ***
Comment 184 paul stanton 2004-09-27 22:42:54 PDT
once for the dummies.. does this mean the next nightly will include this patch?
(talking about firefox)
Comment 185 Johnny Stenback (:jst, jst@mozilla.com) 2004-09-28 17:28:22 PDT
Yes, nightly aviary builds of Firefox from today or later will contain this fix,
as will Firefox 1.0 etc, assuming this didn't cause unforseen problems and is
backed out...
Comment 186 Bill Mason 2004-09-29 23:01:12 PDT
*** Bug 262230 has been marked as a duplicate of this bug. ***
Comment 187 Chris Vance 2004-10-01 23:43:29 PDT
(In reply to comment #185)
> Yes, nightly aviary builds of Firefox from today or later will contain this fix,
> as will Firefox 1.0 etc, assuming this didn't cause unforseen problems and is
> backed out...

Where did this workaround land?

I'm not seeing this fix in the 0.10.1 build pushed to the public for security
reasons (Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001
Firefox/0.10.1).  I still get the bug where hotmail will steal the focus despite
the fact that I am typing in the location bar for another tab.  "real world test
case" is still desplaying buggy behavior for me.

Should http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
contain this patch, or should I be looking for it in
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-10-01-10-0.10.1/
(and similarly named 0.10.1 nightlies)?
Comment 188 Johnny Stenback (:jst, jst@mozilla.com) 2004-10-02 08:41:44 PDT
(In reply to comment #187)
> Where did this workaround land?
> 
> I'm not seeing this fix in the 0.10.1 build pushed to the public for security
> reasons (Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001

That's right, 0.10.1 was just that, a security update, not a full new release.
It contains no other changes since 0.10 than the change needed to fix the
security problem.

Try with a nightly build, like the one at:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/FirefoxSetup.exe
Comment 189 Chris Vance 2004-10-02 13:14:46 PDT
(In reply to comment #188)
> Try with a nightly build, like the one at:
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/FirefoxSetup.exe

Thanks JST.

However, I still see the bug.  Steps:
1. Type hotmail.com in the location bar
2. Hit enter to load the hotmail page
3. Create a new tab (Ctrl+T)
4. Start typing (text will appear in the location bar)

After a few seconds, the cursor will disappear and text will be entered in the
form in the non-visible tab.

This occurs using WinXP SP2 with Firefox:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041002
Firefox/0.10
Comment 190 José Jeria 2004-10-02 13:21:18 PDT
(In reply to comment #189)
> After a few seconds, the cursor will disappear and text will be entered in the
> form in the non-visible tab.

Confirming with same build/system, still seing this.
Comment 191 Dean Tessman 2004-10-02 15:43:15 PDT
Created attachment 160873 [details]
select() testcase

I noticed this, too, but also noticed that other pages like mail.com didn't
steal focus anymore.  After some digging, I found the reason why.  To stop
Hotmail tabs from stealing focus, we'll need to block select() calls as well. 
This testcase I'm attaching doesn't even call focus().

1. Load this testcase.
2. Open a new tab.
3. Load the testcase again.
4. With focus in the input box, right-click the first tab and select reload.

Expected results: Focus remains in the input box on tab 2.

Actual results: Focus is now in the input box on tab 1.
Comment 192 Dean Tessman 2004-10-02 15:54:22 PDT
If we want to fix this in the same way, and I think we should because it's
Hotmail not some obscure page, is just a matter of this?

NS_IMETHODIMP
nsHTMLInputElement::Select()
{
  nsresult rv = NS_OK;
  - if (!mDocument)
  + if (!mDocument || !ShouldFocus(this))
      return NS_OK;
  ...
Comment 193 Mike Calmus 2004-10-02 16:06:38 PDT
For what it's worth, I did a HEAD Mozilla build using the patch from Attachment
#160278 [details] [diff] and it works fine here as well. When can we expect a HEAD merge?
Comment 194 Vaclav Dvorak 2004-10-02 19:32:15 PDT
Created attachment 160886 [details] [diff] [review]
patch for current trunk, including select()

Seems to work perfectly. I can provide a Linux build with the patch if there is
enough interest.
Comment 195 Dean Tessman 2004-10-02 21:18:36 PDT
Mike and Vaclav: See comment 177.  This is only a work-around, and I doubt it
will ever make it to the trunk.  Hopefully what makes it to the trunk will be a
proper fix that maintains the focus when switching tabs.
Comment 196 Ryan Polk (Quark) 2004-10-03 07:40:21 PDT
*** Bug 262695 has been marked as a duplicate of this bug. ***
Comment 197 Johnny Stenback (:jst, jst@mozilla.com) 2004-10-05 23:15:42 PDT
Created attachment 161242 [details] [diff] [review]
Fix for the input.select() problem
Comment 198 Dean Tessman 2004-10-06 06:42:07 PDT
Comment on attachment 161242 [details] [diff] [review]
Fix for the input.select() problem

>     // If the DOM event was not canceled (e.g. by a JS event handler
>     // returning false)
>     if (status == nsEventStatus_eIgnore) {
>-      if (presContext) {
>+      if (presContext && ShouldFocus(this)) {

Does this behave the same way as we handle focus?  I thought that by checking
ShouldFocus() in nsHtmlInputElement::Focus(), the JS event handler is not
called.
Comment 199 Johnny Stenback (:jst, jst@mozilla.com) 2004-10-06 08:13:27 PDT
(In reply to comment #198)
> Does this behave the same way as we handle focus?  I thought that by checking
> ShouldFocus() in nsHtmlInputElement::Focus(), the JS event handler is not
> called.

Does it matter? All we want to prevent here is the actual focusing, if the event
handler fires, that's fine, if it doesn't, then I can't see how that would hurt
more than this hurts in general...
Comment 200 Daniel Veditz [:dveditz] 2004-10-06 12:25:35 PDT
Comment on attachment 161242 [details] [diff] [review]
Fix for the input.select() problem

a=dveditz for 1.7.x

I assume this obsoletes attachment 160886 [details] [diff] [review]?
Comment 201 chris hofmann 2004-10-06 12:25:40 PDT
Comment on attachment 161242 [details] [diff] [review]
Fix for the input.select() problem

a=chofmann for the branches
Comment 202 Johnny Stenback (:jst, jst@mozilla.com) 2004-10-06 12:50:37 PDT
Comment on attachment 161242 [details] [diff] [review]
Fix for the input.select() problem

This is now checked in on the 1.7 and aviary branches.
Comment 203 Dean Tessman 2004-10-07 14:05:22 PDT
(In reply to comment #199)
> (In reply to comment #198)
> > Does this behave the same way as we handle focus?  I thought that by checking
> > ShouldFocus() in nsHtmlInputElement::Focus(), the JS event handler is not
> > called.
> 
> Does it matter? All we want to prevent here is the actual focusing, if the event
> handler fires, that's fine, if it doesn't, then I can't see how that would hurt
> more than this hurts in general...


I was just asking if we were being consistent between how we're eating the two
events.
Comment 204 :Gavin Sharp [email: gavin@gavinsharp.com] 2004-10-18 19:06:38 PDT
*** Bug 253158 has been marked as a duplicate of this bug. ***
Comment 205 WD 2004-10-20 07:01:08 PDT
This has made it to Secunia:
http://secunia.com/advisories/12712/
Comment 206 bugzilla.mozilla.org 2004-10-20 10:46:04 PDT
And subsequently, the more heavily viewed Slashdot:
http://it.slashdot.org/it/04/10/20/1344208.shtml
Comment 207 Neil Parks 2004-10-20 11:43:13 PDT
I am using Oct 13 branch nightly with TBP Lite extension.  Although some of the
extension's functions have been incorporated into the FF core, some have not.

The extension forces all new tabs to open in the background.  As a result, users
of the extension are not vulnerable to the tab focus flaw in the Secunia test. 
When I tried it, the security test string box popped up long before I could
manually switch focus to Citibank's tab.

So it would seem that a simple workaround for the security flaw would be to
force all new tabs to open in the background, even without the extension.
Comment 208 Neil Parks 2004-10-20 11:50:51 PDT
(In reply to comment #207)

On further review:  The test that I am talking about in #207 is the dialog box
spoofing test, which probably isn't the topic of this bug.  Sorry about that.

Comment 209 Mike Pinkerton (not reading bugmail) 2004-10-21 11:23:15 PDT
should this fix it for embedding apps too, like camino?
Comment 210 Johnny Stenback (:jst, jst@mozilla.com) 2004-10-21 11:31:41 PDT
(In reply to comment #209)
> should this fix it for embedding apps too, like camino?

Assuming other embedding app's hide tabs the same way Mozilla does, then yeah,
if not, nsDocShell:GetVisibility() may need to be tweaked a bit to work in those
apps.
Comment 211 Mike Pinkerton (not reading bugmail) 2004-10-21 11:57:52 PDT
i just tested this in camino with a 1.7branch build, it does not fix it. how
does mozilla hide tabs? what should we be doing in camino?
Comment 212 Phil Ringnalda (:philor) 2004-10-21 20:53:18 PDT
*** Bug 265556 has been marked as a duplicate of this bug. ***
Comment 213 Logan Ingalls 2004-10-22 04:58:00 PDT
*** Bug 265587 has been marked as a duplicate of this bug. ***
Comment 214 David A. Cobb 2004-10-28 14:47:52 PDT
I know bugzilla is not the place for conversation, but: is this related to / the
same as the same defect that makes Thunderbird mail agent almost too painful to
use?  I see loss of focus there far more often than in the browser -- although I
usually have both active anyway -- and it is far far more destructive of the
user experience there.  I searched around, but among the 500+ focus bugs I can't
really see one that looks more relevant than this one.  I suspect the same
scripting engine there - yes?  If we(?)-y'all fix this is it fixed there ?
Comment 215 Daniel Veditz [:dveditz] 2004-10-28 17:05:40 PDT
This bug is specific to browser tabs. Thunderbird is entirely different, file
bugs against Thunderbird.
Comment 216 Phil Ringnalda (:philor) 2004-10-29 21:58:36 PDT
*** Bug 260302 has been marked as a duplicate of this bug. ***
Comment 217 Phil Ringnalda (:philor) 2004-10-31 14:17:31 PST
*** Bug 267012 has been marked as a duplicate of this bug. ***
Comment 218 Phil Ringnalda (:philor) 2004-11-16 00:08:13 PST
*** Bug 270072 has been marked as a duplicate of this bug. ***
Comment 219 Frederic Crozat 2004-11-19 08:26:32 PST
Confirmed : embedded apps like galeon or epiphany still show the focus stealing bug.
Comment 220 PikeUK 2004-11-30 03:33:45 PST
*** Bug 272388 has been marked as a duplicate of this bug. ***
Comment 221 itsayellow@gmail.com 2004-11-30 11:12:13 PST
I still see this with Firefox 1.0 and windows (although it did seem like it was
fixed for a while...)
Comment 222 Brendan Eich [:brendan] 2004-11-30 11:28:03 PST
Matt, please file a new bug with exact reproduce-by steps and a valid URL.  This
bug was patched for 1.0, and the known bad cases were fixed by that patch.

/be
Comment 223 Rain maker 2004-12-02 06:16:10 PST
This bug still exists. Well, somewhat... Tabs can still steal focus, by using a
javascript alert dialog.

Try http://www.spiba.nl/ for an example.
Comment 224 Daniel Veditz [:dveditz] 2004-12-02 14:16:20 PST
The bug that was fixed was another tab stealing focus so that typing
(potentially private data like passwords) went into form fields that other page
could access.

Modal dialogs, like alerts, were recently changed to switch tabs so that it was
clear which tab launched the dialog. The tab itself doesn't steal the users
input though, so it's not the same as this bug.
Comment 225 CrazyDave 2004-12-03 01:48:15 PST
Stealiung focus, whilst remaining in the background. It's only patched. A fix
would involve making textbox.focus() local to the tab, rather than the window.
Comment 226 Joachim Noreiko 2005-01-13 03:20:59 PST
This bug has just happened again, with the bugzilla search form on
https://bugzilla.mozilla.org/ stealing focus from a gmail tab where I was typing
an email -- Firefox 1.0
Comment 227 mmortal03 2005-01-22 04:18:31 PST
This was partially band-aided when fixed-aviary1.0.  Requesting
blocking-aviary1.1 for real deal fix?
Comment 228 Mathieu Pellerin 2005-01-23 20:30:35 PST
right now, background tab ignores focused items on load ...

a real fix should remember the item focused in a background and focus that item
when switching to the tab.
Comment 229 Dave 2005-03-05 02:36:54 PST
A very geek-friendly test case:)
1) open a tab to gmail.com, and log in
2) while gmail inbox is loading, open a new tab and start typing slashdot.org in
the location bar. Usually the inbox will load, steal focus, and do stuff to your
messages. I have gmail shortcuts turned on, and 's' stars a message, and 'o'
opens a message. So I usually end up with a URL of 'sla', and the first message
in my inbox starred and opened.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223
Firefox/1.0.1
Comment 230 CrazyDave 2005-04-12 07:50:22 PDT
Gmail seems to be stealing focus again on Firefox 1.0.2. I don't know if this is
related.
Log into Gmail (optionaly close that tab). Open another Gmail page in a new
background tab. Type in the URL bar. When Gmail loads focus is lost.

also 272867 duplicate?
Comment 231 Juan Lanus 2005-05-27 09:01:22 PDT
I'm experimenting this bug in 1.0.4.
I open gmail in a not-very-fast pentium.
While gmail is setting it's page I control-T and start opening another page by
typing the first few letters of the domain name in the URL bar. These letters go
to gmail, I can hear it complain sometimes.
For the test case I think that having a slow PC is useful. Mine is a celeron 600.
Comment 232 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-07-11 04:51:59 PDT
Sorry for the spam, but what is the status of this bug?
This bug is fixed, but it remains open, because a better fix is needed?
Maybe it is better to file a new bug for that, to lessen the confusion?

I've submitted bug 299677, because potentially every element can steal focus.
I'm not sure how serious this bug is considered by the Mozilla foundation.
Comment 233 Asa Dotzler [:asa] 2005-07-11 15:40:08 PDT
Resolving per Martijn's comment.
Comment 234 Mike Kowalski 2005-07-24 01:44:44 PDT
Asa: you forgot to change the bug to FIXED :)
Comment 235 CrazyDave 2005-07-24 02:54:24 PDT
(In reply to comment #234)
> Asa: you forgot to change the bug to FIXED :)

I don't think he did. To look around the #175 comments. This is a workaround. It
still  needs fixing so the each tab can focus on its own elements, if it's in
the background. Reopen?
Comment 236 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-08-08 03:09:40 PDT
I filed bug 303871 as a follow-up to this bug.
I think reopening this bug would only cause more confusion.
Comment 237 Hermann Schaefer 2005-10-20 15:51:51 PDT
*** Bug 313060 has been marked as a duplicate of this bug. ***
Comment 238 :Hb 2009-10-15 07:45:58 PDT
(In reply to comment #191)
SM 2.0 survives this testcase.


(In reply to comment #229)
SM 2.0 fails this testcase. GMail disturbs typing in next tabs Location Bar.

REOPENED
Comment 239 Serge Gautherie (:sgautherie) 2009-10-15 07:59:03 PDT
(In reply to comment #236)
> I think reopening this bug would only cause more confusion.

(In reply to comment #238)
> REOPENED

Please, don't reopen 4 year old bugs: file new (blocking) ones with relevent data.
Comment 240 :Hb 2009-10-15 15:28:12 PDT
I'm fine with your decision. But this bug needs to get off the "Most Frequently Reported Bugs for SeaMonkey" list. So a merely technical VERIFIED is done.
Comment 241 risek2010 2009-11-01 12:28:16 PST
When I open Facebook in multiple tabs while using Facebook chat, I am unable to type in a currently focused text box (no matter what tab or text box) after receiving a message. 

To explain it more clearly:
I open Facebook on Firefox on 2 or more tabs.
I send a message to someone.
I start typing into another textbox (on Facebook or any other page I have open on a Firefox tab)
Before I finish typing, my friend replies
I can no longer type in that text box unless I change focus of it and then return focus to that text box.

This ONLY happens when I use Facebook in multiple tabs. Firefox works normally when I have Facebook open in one tab. I am not certain if textbox.focus is the cause, but the complaints seems to be similar to this problem. I am using FireFox version 3.5.30729.
Comment 242 :Hb 2009-12-06 04:22:33 PST
The first two testcases are fixed and VERIFIED.
The issue with Gmail remains and needs an own report.

Risek: This one is about Seamonkey. You might want to see Bug 140346 as Meta "focus stealing tracking bug".

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