Closed Bug 124750 Opened 23 years ago Closed 15 years ago

Other tab steals focus with javascript textbox.focus()

Categories

(SeaMonkey :: Tabbed Browser, defect)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: greenrd, Assigned: jst)

References

(
URL
)

Details

(Keywords: fixed-aviary1.0, fixed1.7.5, testcase)

Attachments

(7 files, 3 obsolete files)

testcase
168 bytes, text/html
Details
Another (more luxurious) testcase
944 bytes, application/vnd.mozilla.xul+xml
Details
real world test case
446 bytes, text/plain
Details
Possible patch
2.86 KB, patch
bryner
: superreview-
Details | Diff | Splinter Review
Even less scary, and more "correct" hack
8.12 KB, patch
bryner
: review+
bryner
: superreview+
brendan
: approval-aviary+
brendan
: approval1.7.5+
Details | Diff | Splinter Review
select() testcase
246 bytes, text/html
Details
Fix for the input.select() problem
1.49 KB, patch
bryner
: review+
bryner
: superreview+
chofmann
: approval-aviary+
dveditz
: approval1.7.5+
Details | Diff | Splinter Review 
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.
same for me.. (including versions)
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 128243 has been marked as a duplicate of this bug. ***
Summary: Other tab steals focus with javascript → Other tab steals focus with javascript textbox.focus()
bryner, any idea what we can do about this?
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.

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).
OS: Linux → All
Hardware: PC → All
*** Bug 135951 has been marked as a duplicate of this bug. ***
Blocks: 140346
See also bug 125282 - Google steals focus when it's in the location bar.
*** Bug 138195 has been marked as a duplicate of this bug. ***
Blocks: focusnav
No longer blocks: 140346
No longer blocks: focusnav
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.
*** Bug 158270 has been marked as a duplicate of this bug. ***
*** Bug 158786 has been marked as a duplicate of this bug. ***
*** Bug 167677 has been marked as a duplicate of this bug. ***
Attached file 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.
*** Bug 167110 has been marked as a duplicate of this bug. ***
*** Bug 168761 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → pmac
*** Bug 175596 has been marked as a duplicate of this bug. ***
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 !
upgrading severity to "major" as per prev comment
Severity: normal → major
*** Bug 177758 has been marked as a duplicate of this bug. ***
*** Bug 178400 has been marked as a duplicate of this bug. ***
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.
*** Bug 182307 has been marked as a duplicate of this bug. ***
*** Bug 184183 has been marked as a duplicate of this bug. ***
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
*** Bug 187340 has been marked as a duplicate of this bug. ***
*** Bug 187391 has been marked as a duplicate of this bug. ***
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...)
*** Bug 186958 has been marked as a duplicate of this bug. ***
*** Bug 191744 has been marked as a duplicate of this bug. ***
*** Bug 194919 has been marked as a duplicate of this bug. ***
*** Bug 195988 has been marked as a duplicate of this bug. ***
*** Bug 198541 has been marked as a duplicate of this bug. ***
*** Bug 200338 has been marked as a duplicate of this bug. ***
*** Bug 200575 has been marked as a duplicate of this bug. ***
*** Bug 203426 has been marked as a duplicate of this bug. ***
*** Bug 194104 has been marked as a duplicate of this bug. ***
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.
Depends on: 120148
Keywords: helpwanted, nsbeta1
QA Contact: pmac → sairuh
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
*** Bug 206784 has been marked as a duplicate of this bug. ***
*** Bug 207993 has been marked as a duplicate of this bug. ***
*** Bug 209960 has been marked as a duplicate of this bug. ***
*** Bug 210837 has been marked as a duplicate of this bug. ***
*** Bug 210431 has been marked as a duplicate of this bug. ***
*** Bug 211255 has been marked as a duplicate of this bug. ***
*** Bug 213169 has been marked as a duplicate of this bug. ***
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.
*** Bug 215631 has been marked as a duplicate of this bug. ***
*** Bug 215966 has been marked as a duplicate of this bug. ***
*** Bug 216020 has been marked as a duplicate of this bug. ***
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!
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 ! ;-)
*** Bug 219034 has been marked as a duplicate of this bug. ***
Can we make this blocking 1.5?
138646 may depend on this bug
Blocks: 140346
Blocks: majorbugs
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.
*** Bug 220337 has been marked as a duplicate of this bug. ***
*** Bug 220344 has been marked as a duplicate of this bug. ***
judging from the number of found duplicate bugs, this is a HOT issue.
you folks gotta fix it soon
Keywords: testcase
this bug hasn't even been confirmed by the mozilla team. don't expect it to be
fixed in a hurry. sad but true.
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.
Flags: blocking1.6a?
Attached file 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.
*** Bug 219927 has been marked as a duplicate of this bug. ***
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?
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.

*** Bug 218023 has been marked as a duplicate of this bug. ***
*** Bug 210367 has been marked as a duplicate of this bug. ***
*** Bug 222483 has been marked as a duplicate of this bug. ***
*** Bug 224564 has been marked as a duplicate of this bug. ***
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!
*** Bug 226448 has been marked as a duplicate of this bug. ***
Flags: blocking1.6?
*** Bug 227569 has been marked as a duplicate of this bug. ***
too late to get anything done on this for 1.6, maybe bryner can get some work
done on this for 1.7
Assignee: jag → bryner
Flags: blocking1.6? → blocking1.6-
*** Bug 228641 has been marked as a duplicate of this bug. ***
*** Bug 230745 has been marked as a duplicate of this bug. ***
*** Bug 231601 has been marked as a duplicate of this bug. ***
Flags: blocking1.7b?
Would be nice to get for 1.7. Setting an optimistic blocking flag.
Flags: blocking1.7b? → blocking1.7b+
*** Bug 200231 has been marked as a duplicate of this bug. ***
*** Bug 210401 has been marked as a duplicate of this bug. ***
*** Bug 200942 has been marked as a duplicate of this bug. ***
*** Bug 196646 has been marked as a duplicate of this bug. ***
*** Bug 237529 has been marked as a duplicate of this bug. ***
no patch yet, minus for 1.7b
Flags: blocking1.7b+ → blocking1.7b-
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.
very true. just look at the number of duplicates. 52 and counting!!!!!!!
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.
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
	}
}
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 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.
Er, I meant nsHTMLInputElement.
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
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.

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?
Nominating for 1.7 final as it is a _security_ issue.
Flags: blocking1.7?
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.
Approach two sounds best. Any approach is going to add complexity and adding
complexity outside Gecko sounds like a win.
altho load has to be taken into account. not sure how heavy 30 tabs, each with a
gecko instance would be.
I bet Neil could make a patch for this in a jiffy :-)
Bryner, can the tabbed browser capture focus events and prevent the focus being
grabbed by a background tab, instead saving the focus for later?
(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.

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

(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 :-[
Attached patch Possible patch — — Splinter Review 
This was the best I could do, I couldn't be sure what was trying to take the
focus or how to stop it...
Mozilla locks up for me using the second test case with the patch applied.
Comment on attachment 145211 [details] [diff] [review]
Possible patch

[Dons asbestos suit]
Attachment #145211 - Flags: superreview?(bryner)
Attachment #145211 - Flags: review?(roc)
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.
Attachment #145211 - Flags: superreview?(bryner) → superreview-
*** Bug 239468 has been marked as a duplicate of this bug. ***
Flags: blocking1.8a?
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.
(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)
(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.
Yeah, that's a bug in the script on the page, not a browser bug.
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.
*** Bug 240751 has been marked as a duplicate of this bug. ***
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.
Flags: blocking1.7? → blocking1.7-
*** Bug 241813 has been marked as a duplicate of this bug. ***
*** Bug 242016 has been marked as a duplicate of this bug. ***
*** Bug 243446 has been marked as a duplicate of this bug. ***
*** Bug 243685 has been marked as a duplicate of this bug. ***
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.
Flags: blocking1.8a?
Flags: blocking1.8a-
Flags: blocking1.6-
*** Bug 244726 has been marked as a duplicate of this bug. ***
Blocks: 245502
(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!
*** Bug 246893 has been marked as a duplicate of this bug. ***
Asking for blocking as it is a security issue.  Would be great if this could get
done before Firefox hits 1.0
Flags: blocking1.8a2?
*** Bug 247162 has been marked as a duplicate of this bug. ***
Flags: blocking1.7.1?
*** Bug 242894 has been marked as a duplicate of this bug. ***
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.
*** Bug 249895 has been marked as a duplicate of this bug. ***
Flags: blocking1.8a2? → blocking1.8a2-
Flags: blocking-aviary1.0RC1?
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?
(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.
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.
*** Bug 250851 has been marked as a duplicate of this bug. ***
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)
(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.
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?
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.  
i agree with comment 133. hey, that rhymes! must be the right thing to do then.
*** Bug 252504 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0RC1? → blocking-aviary1.0RC1-
Flags: blocking-aviary1.0?
*** Bug 252995 has been marked as a duplicate of this bug. ***
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.
*** Bug 245056 has been marked as a duplicate of this bug. ***
*** Bug 245269 has been marked as a duplicate of this bug. ***
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.
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.
(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.
does this mean we all get the $500 for reporting the bug? :)
it's been "in the works" for well over 2 years now...
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.
Flags: blocking1.8a3?
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 ...
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.

*** Bug 216811 has been marked as a duplicate of this bug. ***
Flags: blocking1.8a3?
Flags: blocking1.8a3-
Flags: blocking1.7b-
Flags: blocking1.7.3?
Flags: blocking1.7.3-
*** Bug 255787 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0? → blocking-aviary1.0-
*** Bug 256177 has been marked as a duplicate of this bug. ***
*** Bug 257665 has been marked as a duplicate of this bug. ***
*** Bug 258852 has been marked as a duplicate of this bug. ***
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...
*** Bug 243363 has been marked as a duplicate of this bug. ***
don't worry about it. no one at mozilla is.
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
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
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
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.
Well, good to hear that Mozilla developer folks will have an eye on it now. 
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.
Flags: blocking1.8a2-
Flags: blocking1.8a1-
Flags: blocking1.7-
Flags: blocking-aviary1.0PR-
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)
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 163 is spot on
Please take this to the forums and stop spamming the bug.  The last 4 comments
have been pointless.
Whiteboard: Read Comment #158 before commenting
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.
I have a suggestion for a simple workaround: add a user option to disable
focus() entirely.


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.
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€
*** Bug 259168 has been marked as a duplicate of this bug. ***
*** Bug 260580 has been marked as a duplicate of this bug. ***
*** Bug 260719 has been marked as a duplicate of this bug. ***
*** Bug 260774 has been marked as a duplicate of this bug. ***
(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!
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. 
 
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 ;)
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.
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...
Attachment #159903 - Attachment is obsolete: true
Attachment #159914 - Attachment is obsolete: true
Attachment #160278 - Flags: superreview?(bryner)
Attachment #160278 - Flags: review?(bryner)
Attachment #160278 - Flags: superreview?(bryner)
Attachment #160278 - Flags: superreview+
Attachment #160278 - Flags: review?(bryner)
Attachment #160278 - Flags: review+
Attachment #160278 - Flags: approval1.7.x?
Attachment #160278 - Flags: approval-aviary?
Re-setting blocking aviary and 1.7.x, now that we have a feasable workaround.
Flags: blocking1.7.x?
Flags: blocking1.7.x-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
Comment on attachment 160278 [details] [diff] [review]
Even less scary, and more "correct" hack

Thanks, jst!  a=me for branches.

/be
Attachment #160278 - Flags: approval1.7.x?
Attachment #160278 - Flags: approval1.7.x+
Attachment #160278 - Flags: approval-aviary?
Attachment #160278 - Flags: approval-aviary+
Workaround landed on the aviary and 1.7 branches.
Keywords: fixed-aviary1.0, fixed1.7.x
No longer blocks: 245502
*** Bug 245502 has been marked as a duplicate of this bug. ***
once for the dummies.. does this mean the next nightly will include this patch?
(talking about firefox)
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...
Flags: blocking1.7.x?
Flags: blocking-aviary1.0?
*** Bug 262230 has been marked as a duplicate of this bug. ***
(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)?
(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
(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
(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.
Attached file 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.
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;
  ...
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?
Seems to work perfectly. I can provide a Linux build with the patch if there is
enough interest.
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.
*** Bug 262695 has been marked as a duplicate of this bug. ***
Blocks: SA12712
Attachment #161242 - Flags: superreview?(bryner)
Attachment #161242 - Flags: review?(bryner)
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.
(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...
Attachment #161242 - Flags: superreview?(bryner)
Attachment #161242 - Flags: superreview+
Attachment #161242 - Flags: review?(bryner)
Attachment #161242 - Flags: review+
Attachment #161242 - Flags: approval1.7.x?
Attachment #161242 - Flags: approval-aviary?
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]?
Attachment #161242 - Flags: approval1.7.x? → approval1.7.x+
Comment on attachment 161242 [details] [diff] [review]
Fix for the input.select() problem

a=chofmann for the branches
Attachment #161242 - Flags: approval-aviary? → approval-aviary+
Attachment #160886 - Attachment is obsolete: true
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.
(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.
*** Bug 253158 has been marked as a duplicate of this bug. ***
This has made it to Secunia:
http://secunia.com/advisories/12712/
And subsequently, the more heavily viewed Slashdot:
http://it.slashdot.org/it/04/10/20/1344208.shtml
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.
(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.
Blocks: 265055
should this fix it for embedding apps too, like camino?
(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.
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?
*** Bug 265556 has been marked as a duplicate of this bug. ***
Blocks: 265456
*** Bug 265587 has been marked as a duplicate of this bug. ***
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 ?
This bug is specific to browser tabs. Thunderbird is entirely different, file
bugs against Thunderbird.
*** Bug 260302 has been marked as a duplicate of this bug. ***
*** Bug 267012 has been marked as a duplicate of this bug. ***
*** Bug 270072 has been marked as a duplicate of this bug. ***
Confirmed : embedded apps like galeon or epiphany still show the focus stealing bug.
*** Bug 272388 has been marked as a duplicate of this bug. ***
I still see this with Firefox 1.0 and windows (although it did seem like it was
fixed for a while...)
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
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.
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.
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.
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
This was partially band-aided when fixed-aviary1.0.  Requesting
blocking-aviary1.1 for real deal fix?
Flags: blocking-aviary1.1?
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.
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

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?
No longer blocks: majorbugs
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.
Blocks: 299677
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.
QA Contact: bugzilla → nobody
Resolving per Martijn's comment.
Flags: blocking-aviary1.1?
Asa: you forgot to change the bug to FIXED :)
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
(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?
Depends on: 303871
I filed bug 303871 as a follow-up to this bug.
I think reopening this bug would only cause more confusion.
*** Bug 313060 has been marked as a duplicate of this bug. ***
Product: Core → SeaMonkey
(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
Status: RESOLVED → REOPENED
Keywords: helpwanted
Resolution: FIXED → ---
(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.
Assignee: bryner → jst
Status: REOPENED → RESOLVED
Closed: 19 years ago → 15 years ago
QA Contact: nobody → tabbed-browser
Resolution: --- → FIXED
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.
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.
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".
Status: RESOLVED → VERIFIED
Whiteboard: Read Comment #158 before commenting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: