678994 - onclick popups can be delayed by event-loop-spinning tricks

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[Jesse Ruderman]

Attachment: 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".

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 3

[Jesse Ruderman]

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

Comment 4

[Jesse Ruderman]

This is a new security hole in Firefox 10 (see comment 0).

Comment 5

[Alex Keybl [:akeybl]]

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.

Comment 6

[Jesse Ruderman]

Please see the explanation I linked to when I nominated this bug.

Comment 7

[Alex Keybl [:akeybl]]

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.

Comment 8

[Chris Pearce [:cpearce (Not reading bugmail)]]

(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?

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

This bug occurs in nightlies as far back as 2011-01-01, so if it's a regression, it's not a recent regression

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 11

[Chris Pearce [:cpearce (Not reading bugmail)]]

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

Comment 12

[Al Billings [:abillings - ex-MoCo]]

This still works in the current nightly Firefox 13 build.

Comment 13

[Tanvi Vyas[:tanvi]]

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.