Open Bug 1434083 Opened 6 years ago Updated 2 years ago

preventDefault ignored on keyDown when calling window.open

Categories

(Core :: DOM: Events, defect, P3)

57 Branch
defect

Tracking

()

People

(Reporter: ken, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20180103231032

Steps to reproduce:

I am developing a web-based app that allows the user to press Ctrl-S to save the document. We use event.preventDefault() on the key down event which usually prevents the browser's "Save As" dialog from appearing.

Sometimes, though, the user needs to be authenticated and we subsequently use window.open to open the appropriate window for them to renew their security token.


Actual results:

After the second window opens, the "Save As" dialog appears, despite the fact we've already called event.preventDefault(). (I saved it out of curiosity and it was a file called index.html that contained just a content-type meta tag in the head and an empty body.)

I confirmed this behaviour did not happen in Chrome 64.0.3282.119, IE 11.850.15063.0 or Edge 40.15063.674.0.


Expected results:

The "Save As" dialog should not appear, because event.preventDefault() had been called on the keyboard event.
Component: Untriaged → DOM: Events
Product: Firefox → Core
As I think more about this now, I think the problem is not so much with preventDefault. In the other browsers I tested, the "Save As" dialog never appeared, even when I commented out the code that called preventDefault.

I think the broader issue is with events from one window being passed on to the second one when window.open is used. In this scenario at least, I don't think the second window should receive the events.
Thank you for the report Ken. Firstly, you can work around this by handling the 'keypress' event for Ctrl-s. Secondly, it seems that we might be behind spec here. Bouncing that question to Olli: shouldn't preventDefault on the keydown prevent the keypress?
Flags: needinfo?(bugs)
yes. And that happens at least in normal case like
data:text/html,<input onkeydown="console.log(event.type); event.preventDefault();"  onkeyup="console.log(event.type);"  onkeypress="console.log(event.type);">

Is that not happening here?

Or is the issue here that a new window is opened and some event goes there? Focus should move to the new window. But need a testcase here.
Flags: needinfo?(bugs)
You should be able to reproduce the problem using this:

https://codepen.io/theken/pen/RMZwgL
I've discovered that handling 'keypress' isn't a viable workaround for our situation. In order for 'keypress' to be fired, we had to stop calling preventDefault() on the 'keydown' event. This led to problems in Chrome and IE11 which both seem to implement Ctrl-S on the 'keydown' event, not 'keypress'. They both started showing the browser's "Save" dialog every time.

I'm rolling back the workaround in our product and our Firefox users will need to live with the bug for now.
(In reply to Olli Pettay [:smaug] from comment #3)
> Or is the issue here that a new window is opened and some event goes there?
> Focus should move to the new window. But need a testcase here.

It appears that the event that caused the new tab to be opened also gets processed in the context of the tab.

smaug, should this be P2 instead of P3?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(bugs)
Priority: -- → P3
I don't see anything here why this should be P2 (given the current resources).
Flags: needinfo?(bugs)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.