Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#12477 closed Bug (invalid)

iOS and Hardware Keyboards

Reported by: Alan Owned by:
Priority: Normal Milestone:
Component: Core : Keystrokes Version:
Keywords: Cc:


On iOS (V7.1.1) I'm experiencing a problem where when CapsLock is on all future keystrokes come through with the ctrlKey keyboard event flag as true. I have tried multiple keyboards and multiple iPads. Consequently, CKEditor doesn't process them correctly (as I'd expect), but I also can't seem to entirely disable keyboard commands which has resolved the problem for our software outside of CKEditor. I have set both the keystrokes and blockedKeystrokes objects to {} but Y, Z, X, C, and V still cannot be typed when Caps-Lock is on (although that fixes such characters as B which did not work before).

In a nutshell this means externally connected keyboards for iOS don't work with CKEditor when CapsLock is on (due to bad JavaScript event data).

Change History (8)

comment:1 Changed 9 years ago by Piotrek Koszuliński

Status: newpending
Version: 4.4.3

I can't test it unfortunately because I don't have a hardware keyboard for iPhone/iPad. But don't you think that this is an iOS's bug? Why does it say that CTRL is pressed when caps lock is on? I think that this should be reported on rather than for us, because we can't do much for it - we would need to disable keystrokes on iOS, which theoretically does not matter, because you can't use them anyway, but still - if this will be fixed in iOS you will be able to use keystrokes when having an external keyboard.

comment:2 Changed 9 years ago by Alan

Absolutely it's an iOS bug and thanks for the link. I'll report it there too.

However, what's the point in having CKEditor let me disable keyboard commands via the aforementioned method when it selectively doesn't let me disable 5 of them? Why are Cut/Copy/Paste/Undo/Redo special? That seems like a CKEditor issue to me.

comment:3 Changed 9 years ago by Piotrek Koszuliński

It's a lack of feature rather than a bug, but people tend calling that a bug :).

The things is that these keystrokes were hardcoded instead of reused based on the editor.keystrokeHandler.keystrokes object. The reason for that was most likely that no one had thought that someone will ever need to disable them, because that would break entire plugins (clipboard/undo), so why not disabling them instead?

So, it's doable and we could change that, but that's really unlikely to be useful in any other case, so it's unlikely that we're going to handle it as a "bug".

BTW. the workaround is to add a high-priority (prior < 10) keydown listener to the editable (see!/api/CKEDITOR.editable-method-attachListener) and call evt.stop(), to block this event's propagation, so other listeners won't call

comment:4 Changed 9 years ago by Alan

Yeah, I know it's not a bug with CKEditor per say, but 'bug' is used pretty generically. And I also know it's not something anyone should have to deal with... however clients don't want a technical explanation of why there's an issue. They just want it to work especially when it used to work with iOS 6 (I am told). I mean... ctrlKey is true when it's not actually pressed??? I'll be interested to see what feedback I can get on the website forums.

Thanks for the workaround suggestion! If I can get that working then problem solved :-)

comment:5 Changed 9 years ago by Alan

Thanks again... your solution worked perfectly!

comment:6 Changed 9 years ago by Piotrek Koszuliński

Resolution: invalid
Status: pendingclosed

Cool. So I'm closing this ticket.

Have you by any chance reported the bug to Webkit team?

comment:7 Changed 9 years ago by Alan

Yes, and was also able to test and verify that this is a problem with iOS 8 as well:

comment:8 Changed 9 years ago by Piotrek Koszuliński


Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy