474573 - Popups for user-initiated keypress events are blocked

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6. Also happens for Shiretoko and Minefield.

If you want to use Google Reader without having set an exception for pop-ups on google.com, posts cannot be opened in a new window/tab. The action is initiated by a user and shouldn't be blocked.

Steps:
1. Open http://www.google.com/reader/ and login
2. Subscribe to at least one feed
3. Open the feed and select a post
4. Press 'v' to open the full story

With step 4 you will notice that the creation of the new window/tab is blocked. An alert is displayed and the pop-up blocker notification bar appears. Here the alert message from Google Reader itself:

"Grrr! A popup blocker may be preventing Google Reader from opening the page. If you have a popup blocker, try disabling it to open the window."

As Marco pointed out, he was probably also able to see that a while ago while using gmail chat.

Comment 1

[Marco Zehe (:MarcoZ)]

(In reply to comment #0)
> As Marco pointed out, he was probably also able to see that a while ago while
> using gmail chat.

Correct. I was in Google Talk, having a chat window open, and selected the "Pop-Out" button to transfer the chat to a different window. I was greeted with the same message as Henrik points out above. Again this action was keyboard-initiated.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

I'm having a hard time understanding what the bug is here ... that keyboard initiated window.open() actions are not being passed through the popup blocker? Or that we're blocking popups from Google itself? If you perform these actions by clicking the mouse, do they also result in blocked popups?

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #2)
> I'm having a hard time understanding what the bug is here ... that keyboard
> initiated window.open() actions are not being passed through the popup blocker?

Yes. If you don't have added an exception for google.com to the popup blocker, opening a post with the 'v' key results in a blocked window. 

> Or that we're blocking popups from Google itself? If you perform these actions
> by clicking the mouse, do they also result in blocked popups?

Oh, it really works when using the mouse. So it depends on how Google has implemented its shortcut handling?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I'll immediately upload a testcase.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: testcase

Pressing any key after the page has been loaded, the popup is blocked even for user-initiated keypress events. You have to whitelist bugzilla.org to get them displayed.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Pretty sure this is by design, as otherwise any keypress on a webpage could result in a popup window. There are two workarounds:

1. whitelist the URL
2. add "keypress" to dom.popup_allowed_events (it's a space separated list)

Comment 7

[Nochum Sossonko [:Natch]]

Well, with that same logic mouse events are in the can as well, I've seen countless sites that just put a listener on the wrapper and result in popups whenever you click _anywhere_.

Comment 8

[Marco Zehe (:MarcoZ)]

(In reply to comment #6)
> Pretty sure this is by design, as otherwise any keypress on a webpage could
> result in a popup window. There are two workarounds:

In consequence, this means that any ajax-enabled web app where the author made sure to put keyboard navigation into will have this problem.

> 1. whitelist the URL

Is it feasible to whitelist several domains by default for this (like gmail)? I'm sure many keyboard users will appreciate this for such common apps.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Personally I think that adding a listener for mouse events will be more helpful for such websites. You should compare how often users will use the keyboard on a site instead of a mouse. The latter one is more common and we allow it.