Closed Bug 355482 Opened 14 years ago Closed 14 years ago
.focus (raise/lower windows) on other windows at times when popups are allowed
Sites with multiple windows can't raise background windows, even in response to clicks (see complaints in bug 355428 and bug 351013). IMO, they should be allowed to raise other windows at times when they can create new windows, such as in response to clicks. Note that I'm suggesting that this be restricted to focusing *other* windows. Allowing a script to focus its own window (the one in which the click happened) would do little other than make onclick popunders possible, and popunders have little use other than hiding the origin of an intrusive advertisement. (Changing my mind slightly from what I said in bug 299424 comment 7.)
I'm the reporter of bug 355428, I just wanted to say that I prefer this solution to my previous suggestion, which had been to use a yellow notification bar indicating that a raise request was blocked. I think this is a pretty serious bug, as from the user's perspective it breaks a lot of sites that use popup windows. It's really frustrating as a user to click on a link and have nothing at all happen.
Reproducible: Always Steps to Reproduce: 1. Make sure "Allow scripts to raise/lower popup windows" is off (the FF2 default) 2. Go http://www.quirksmode.org/js/popup.html 3. Click on the "open popup" link about 20% down the page 4. After the popup raises, click back to the main window and click "open popup" again Actual Results: Nothing happens (the popup is updated in the background, but not foregrounded). Expected Results: The window should foreground.
*** Bug 358385 has been marked as a duplicate of this bug. ***
The new default setting in Firefox 2 has led to a moderate number of bug reports. I think most of those bug reports are essentially due to this bug, with a few that are attempts to do wacky things that we want to continue to disallow (e.g. pop-under ads, fake modal dialogs).
The workaround above is helpful in some cases, but closing and reopening the popup just to refocus it isn't always viable... If the user was in the middle of filling out a form in the popup, reopening it would cause them to lose their form state. They would also lose their scroll position, which might be a problem in popups with a lot of content.
The fact that such a workaround exists is a pretty good argument the fix I suggested in comment 0 is the right one (in that it doesn't allow new annoying behavior, but does allow things that should work to work well).
Who can I bribe to help get this fixed in time for Firefox 2.0.1?? :-)
*** Bug 360198 has been marked as a duplicate of this bug. ***
This change should be what we need, but unfortunately I can't seem to test this as raising windows on my linux system doesn't seem to work no matter what prefs I set. Any testing anyone else can do would be greatly appreciated.
The patch seems to fix the bug on Mac. Thanks, jst! It might be better if it were restricted to focusing *other* windows as I suggested in comment 0, so that on-click pop-unders continue to be disallowed. But on the other hand, maybe there are legitimate reasons to re-focus the main window immediately after opening new windows.
*** Bug 361237 has been marked as a duplicate of this bug. ***
Needs to land on the trunk if this is the right fix.
Assignee: general → jst
Flags: blocking22.214.171.124? → blocking126.96.36.199+
Comment on attachment 245296 [details] [diff] [review] This should fix this. I'm not super exited, but I doubt it'll be abused. If it is we can always revisit and possibly come up with a better api.
Fix checked in.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment on attachment 245296 [details] [diff] [review] This should fix this. Since this bug got nominated and approved for 188.8.131.52 I'm requesting approval for this patch, but I must say I question the need for this on the branch.
Attachment #245296 - Flags: approval184.108.40.206?
Is this bug Mac only? If so, why?
OS: Mac OS X 10.4 → All
Hardware: Macintosh → All
Jesse or anyone: Based on jst's comment #17, is it critical to fix this on the 1.8.1 branch? Johnny/Jonas: How risky is this patch for the branch?
(In reply to comment #20) > Johnny/Jonas: How risky is this patch for the branch? I would rate the risk with taking this on the branch extremely low.
Comment on attachment 245296 [details] [diff] [review] This should fix this. Thanks for the info Johnny. Approved for 1.8.1 branch, a=jay for drivers. Please land asap. Thanks.
Attachment #245296 - Flags: approval220.127.116.11? → approval18.104.22.168+
Fixed on the 1.8 branch.
Doesn't happen to me.
What doesn't happen to you? And on what branch/platform etc?
*** Bug 362105 has been marked as a duplicate of this bug. ***
WFM: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:22.214.171.124pre) Gecko/20061130 BonEcho/126.96.36.199pre
Status: RESOLVED → VERIFIED
Whiteboard: [checkin needed (1.8 branch)]
You need to log in before you can comment on or make changes to this bug.