Keypress not recognised as user event for popup blocker
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
People
(Reporter: gyoung, Unassigned)
References
(Depends on 1 open bug, )
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3 When a popup window is triggered after the user presses a key (say in an input textbox) the popup blocker blocks the popup, even though it was a result of a user action. Reproducible: Always Steps to Reproduce: 1. View page - window.onload popup blocked alert shown 2. Click in the input text box 3. Press any key - input.keypress popup blocked alert shown Actual Results: See above. Expected Results: The popup should be allowed after pressing a key in the input box. In the example, a popup window is shown and an alert indicating the popup was allowed should be displayed. This is a problem for web application developers who wish to display popups based on specific key presses (such as the tab key or some other key combo). IE (sp2) and Safari both accept keypress as a valid user event for their popup blocking implementation.
Comment 1•20 years ago
|
||
jst, wanna just dup that to the bug you were working on earlier today?
Comment 2•20 years ago
|
||
IE on SP2 doesn't permit a popup from a keypress event here (default settings), except for the enter key, just like Mozilla does. Can you please re-test with IE, and make sure you haven't configured it to specifically allow popups from keypress events? Marking WONTFIX, reopen if this really should change.
Reporter | ||
Updated•20 years ago
|
Reporter | ||
Comment 3•20 years ago
|
||
Thanks for your prompt review and feedback - I have just confirmed that you are right - I was testing on a page hosted on localhost, which is allowed by default under IE - thus my comments. I would still like to see this changed, but understand if this is not considered something requiring change.
Comment 4•19 years ago
|
||
*** Bug 304965 has been marked as a duplicate of this bug. ***
Comment 5•18 years ago
|
||
I've just encountered this issue with the Webmail application that I'm developing. See http://decimail.org/webmail/demo/webmail.html for a demo. If you select a message you can click on "reply", "forward" etc. and it correctly pops up a message composition window. But if you press "r" or "f", which are detected using document.onkeypress, it shows the popup blocker message. I'd like to imagine that there is some way that keypresses could be allowed to open windows without letting through nasty popups. If this has been discussed elsewhere, please point me in the right direction - thanks.
Updated•15 years ago
|
Updated•6 years ago
|
I can confirm that this behavior happens in Firefox 81, and not in Chrome 88. This affects my website, since I trigger a popup with the ENTER key, but it gets blocked in Firefox (and works in Chrome).
Same here. I want to open a new tab on special keyboard shortcuts.
Works well in Chrome and Edge. Only Firefox still rejects to open a new tab even on user input.
Seems opening new tabs is only allowed on mouse left. Not on key input and also not on mouse right.
Updated•2 years ago
|
Comment 8•8 months ago
|
||
The test page at the provided URL is no longer available. Could someone create a new test page?
Comment 9•8 months ago
|
||
Here's a basic example: https://codepen.io/devongovett/pen/qBLVoVL. Pressing enter in the text field should open a new tab. This works in Chrome and Safari but is blocked in Firefox.
Comment 10•8 months ago
|
||
Note, if you modify the dom.popup_allowed_events
setting in about:config to include keydown then it works, so maybe the default setting just needs to be updated?
Comment 11•8 months ago
|
||
I agree. The default value of that config already includes 13 events*, so it’s not like Firefox is being very restrictive when it comes to allowing window.open() in response to a user event. This seems like an oversight to include keyboard events in that list.
*change click dblclick auxclick mousedown mouseup pointerdown pointerup notificationclick reset submit touchend contextmenu
Comment 12•8 months ago
|
||
We think bug 1656444 would help this issue. We should verify the issue after that bug.
As comment 10 suggests, modifying dom.popup_allowed_events
is a workaround for now.
Updated•8 months ago
|
Comment 13•8 months ago
|
||
That's only a workaround for users not web developers. It is not really feasible for web sites to ask users to change an advanced Firefox setting to work around an issue. Is there a downside to simply adding keydown keypress keyup
to the default for that setting in the meantime?
Description
•