Created attachment 553180 [details] testcase Currently this is "just" an opportunity for sites to hide the source of a popup window, similar in spirit to pop-unders. But if we begin to rely on the pop-up heuristic for security, this becomes a security hole. For example, in bug 545812 we want to "ensure the user is looking at the screen".
Maybe Chris could fix this... One option is to clear the "currently handling a user event" flag all the way up the stack whenever we run a nested event loop.
Although that might be defeatable in a multi-process setup if the Web page just spins regular JS for a while --- with multi-process, the user can still switch to another tab. A more robust solution would be to say that if, say, more than one second has elapsed since the input event, we're no longer "currently handling" that event.
> if, say, more than one second has elapsed since the input event Maybe using the same pref as timeouts? dom.disable_open_click_delay defaults to 1000.
This is a new security hole in Firefox 10 (see comment 0).
tracking-firefox10: --- → ?
From the security severity ratings page, I see that sg:low is a "Minor security vulnerabilities such as leaks or spoofs of non-sensitive information." Is this a regression in FF10? Or is there some other reason we should track this minor vulnerability? Please re-nominate if so.
tracking-firefox10: ? → -
Please see the explanation I linked to when I nominated this bug.
tracking-firefox10: - → ?
I did read https://bugzilla.mozilla.org/show_bug.cgi?id=545812#c89 prior to commenting, and I'm still unsure as to why we'd track for FF10. If this bug is actually a "Minor security vulnerability", we'd still consider uplifting if a low-risk fix was found (given the minor implications in bug 545812), but I don't think we need to track in the meantime.
tracking-firefox10: ? → -
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #2) > A more robust solution would be to say that if, say, more than one second > has elapsed since the input event, we're no longer "currently handling" that > event. How is this different from what we did in bug 684627?
This bug occurs in nightlies as far back as 2011-01-01, so if it's a regression, it's not a recent regression
(In reply to Chris Pearce, Mozilla Corporation (:cpearce) from comment #8) > (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #2) > > A more robust solution would be to say that if, say, more than one second > > has elapsed since the input event, we're no longer "currently handling" that > > event. > > How is this different from what we did in bug 684627? It's not. I wrote that before you filed bug 684627. I think bug 684627 fixed this bug.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
I don't think bug 684627 fixed this; the testcase still opens a pop-under for me in current nightlies. I would have expected bug 684627 to fix it however...
Status: RESOLVED → UNCONFIRMED
Ever confirmed: false
Resolution: FIXED → ---
This still works in the current nightly Firefox 13 build.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This still works in Nightly - Pops open a tab, quickly closes it, and rewrites the contents of the current tab. If you switch tabs, changes focus and takes you back to original tab.
You need to log in before you can comment on or make changes to this bug.