RESOLVED FIXED 7747
REGRESSION: Background tab/window auto-refresh in GMail will take focus.
https://bugs.webkit.org/show_bug.cgi?id=7747
Summary REGRESSION: Background tab/window auto-refresh in GMail will take focus.
Adele Peterson
Reported 2006-03-12 18:43:46 PST
This is not the same bug as http://bugzilla.opendarwin.org/enter_bug.cgi?product=WebKit "gmail website steals tab focus". This behavior has changed recently. It used to be that if you started to load GMail, and then went to another tab, that when it finished loading, GMail would take the focus (by calling window.focus). This is definitely different from Firefox but not nearly as annoying as the new behavior. Now, when GMail does refresh loads in a background tab or window, it also steals focus. So you can leave the tab/window after its fully loaded, go to another tab and do something else for a minute, and as the refresh in the GMail tab/window occurs, the focus will change out from under you. This does not occur in Safari 2.0.3.
Attachments
Reduction (250 bytes, text/html)
2006-03-22 12:24 PST, mitz
no flags
Reduction (248 bytes, text/html)
2006-03-22 12:26 PST, mitz
no flags
Patch (5.09 KB, patch)
2006-03-22 13:52 PST, mitz
adele: review+
David Kilzer (:ddkilzer)
Comment 1 2006-03-12 20:02:17 PST
(In reply to comment #0) > This is not the same bug as > http://bugzilla.opendarwin.org/enter_bug.cgi?product=WebKit > "gmail website steals tab focus". That would be Bug 3779. :)
Adele Peterson
Comment 2 2006-03-13 11:41:06 PST
This regression occurred between r13256 and r13261
Darin Adler
Comment 3 2006-03-14 04:30:22 PST
All the changes between those versions were things I did. Two bugs I fixed were bug 3308 and bug 7422 Here's a guess: It's possible this regression occurred because I fixed window.open() to properly find existing frames by name. Perhaps GMail calls focus() on a frame, but before it was having difficulty finding the frame. Thus I could have made the symptom of bug 3779 worse by fixing a bug in window.open(). If so, then it means the behavior before might have been better when pop-up blocking was enabled. Some ways to test this theory would be: 1) to change KJS::WindowFunc::callAsFunction to call tree()->child() instead of tree()->find() in the one place at the start related to pop-up blocking or 2) to test older versions of Safari with pop-up blocking turned off.
Jon
Comment 4 2006-03-16 07:44:09 PST
I'm seeing this bug in a broader context. For example, at the Ars forums, clicking a link for a forum or topic will result in focus being shifting to the last tab or window in the order stack. So, open the Ars forums in a tab and then open another tab or window, which can have anything in it. Then go back to the Ars tab and click a forum or topic link. The view should switch to the new tab or window. Also, I've narrowed this down to the 13258 change as being the first version that will display this bug. 13257 doesn't build and 256 doesn't have this bug. I also think the severity of this bug should be increased since it affects multiple sites whenever you have multiple tabs or windows open.
Geoffrey Garen
Comment 5 2006-03-16 11:07:51 PST
Bumping to major.
Alice Liu
Comment 6 2006-03-16 17:55:48 PST
mitz
Comment 7 2006-03-22 11:54:19 PST
*** Bug 7915 has been marked as a duplicate of this bug. ***
mitz
Comment 8 2006-03-22 12:24:27 PST
Created attachment 7236 [details] Reduction The problem seems to be very simple: FrameTree::find() does not match the null name with a frame that has a name. I think it should do just that.
mitz
Comment 9 2006-03-22 12:26:33 PST
Created attachment 7237 [details] Reduction Corrected link text.
mitz
Comment 10 2006-03-22 13:52:48 PST
Adele Peterson
Comment 11 2006-03-22 13:59:26 PST
Comment on attachment 7238 [details] Patch nice work, mitz! r=me.
mitz
Comment 12 2006-03-22 16:03:17 PST
*** Bug 7920 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.