Opened 14 years ago
Closed 13 years ago
#8203 closed Bug (invalid)
[Chrome] ALT+S for submitting a post in IPB and vBulletin does not work
Reported by: | Rhett | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | Core : Keystrokes | Version: | 3.0 |
Keywords: | Webkit | Cc: |
Description
Both Invisionpower and vBulletin have started using CKE editor in the last few weeks. Both of these applications no longer work with the accesskey ALT+S in Chrome to submit your post or entry.
They both work fine in other browsers, but Chrome does not.
Is this something that can be resolved? It's a very common standard shortcut for submitting forms and post, and all the chrome users are getting upset!
This has been tested and reproduced on several platforms, WinXP, Win7, IE, FF, opera all work, Chrome fails.
Thank you
Attachments (3)
Change History (18)
comment:1 Changed 14 years ago by
Component: | General → Core : Keystrokes |
---|---|
Keywords: | Chrome added |
Summary: | ALT+S Submitting a post is not functioning in Chrome → [Chrome] ALT+S for submitting a post in IPB and vBulletin does not work |
comment:2 Changed 14 years ago by
Status: | new → pending |
---|
CKEditor doesn’t support this shortcut and there is very little chance that it is in some way blocking it.
Many browsers had problems with this shortcut. Just google to see for your self. In my opinion this is either Browser or vBulletin Bug not ours.
Of course I may be wrong thus could you tell me if you are able to provide me with a simple test case (HTML page or a sample application using only CKEditor and no vBulletin) proving that CKEditor is the one to blame?
Waiting for your comments.
comment:3 Changed 14 years ago by
This is a Chrome Specific issue, as mentioned it happned on invisionpower board and vbulletin among others, but those are the two specific cases that I'm concerned with.
After submitting a post, key press alt+s in all other browsers it will submit the post, in chrome and Safari it gives a nice little "Ding" sound.
I have two test threads here
Invisionpower > http://community.invisionpower.com/topic/342032-testing-alts-by-browser/ vBulletin > https://www.vbulletin.com/forum/showthread.php/384398-Testing-ALT-S-by-browser
Both of these are producing the same results, both companies are blaming the editor, I'm hear to find the truth. :)
IE9 - works FF 5 - works Chrome 12 - broken Safari 5.1 - broken
If you show me any more sites/software that are using cke I will test on them as well. The test editor I found on this site does not use the accesskey=s feature to test it. Thank you for any help on tracking this down.
comment:4 Changed 14 years ago by
I just did another test to confirm this is in fact the editor breaking this.
On your test site here http://drupal.ckeditor.com/node/1#comment-7458
I was able to add the accesskey=s on my side (chrome dev tools) and the alt+s works on the plain text editor, when using cke it's not working and producing the same "Ding" as invision power and vbulletin.
comment:6 Changed 14 years ago by
From what you have delivered and written it looks like that CKEditor in someway blocks this shortcut.
To make sure that what you say is correct I have created a simplified test case in which I have used CKEditor and JQuery.
Using JQuery I have attached keypress events to main document and editor’s content area (CKEditor is in iframe, so attaching event on main document won’t have effect on it). Whenever keypress is fired it inserts HTML into CKEditor.
Here are the results of my tests: IE – right ALT + S works. Left ALT + S fires menu. Webkit - right ALT + S works. Left ALT + S gives system sound. FF - left ALT + S works. Right ALT + S inserts ß.
I have also removed CKEditor and received same results for plain textarea.
This TC shows that there is no problem with CKEditor but rather with vBulletin. Are you able to provide me with similar simple TC proving that I'm wrong?
Changed 14 years ago by
comment:7 Changed 14 years ago by
Im am specifically concerned with webkit left alt + s , you are showing the same results as my test, which shows its not submitting the post and producing a system sound. When it should be submitting it as ie does.
Im not sure how there is any confusion as we both produce the same results here?
Spedifically webkit alt + s left key producing a system sound, rather then a function of submitting the post in my test and calling the menu in yiur case. ?
My test above using an editor on this site is more clear and simple that what you have done and it also shows that webkit left alt + s works in plain text mode. Give it a try and you will see as well. This clearly shows that cke is in producing a system sound rather then working.
Im not sure how much clearer this can be?
comment:8 Changed 14 years ago by
First of all you didn’t say anything about left alt. You have said that alt+s doesn’t work so I have the right to be confused.
Second we don’t have the same results: Mine are as followas:
- IE – right ALT + S works. Left ALT + S fires menu.
- Webkit - right ALT + S works. Left ALT + S gives system sound.
- FF - left ALT + S works. Right ALT + S inserts ß.
If you comment out CKEditor code (look below):
var e = CKEDITOR.replace( 'editor1' ,{ bodyId : "myBodyId"}); e.insertHtml('<p>test </p>'); e.insertHtml('<p>test </p>');
And uncomment alerts you will get textarea with jQuery. The results for this textarea will be the same as for CKEditor.
I will repeat it once more - results for text-area and CKEditor in browsers with default settings, OS win7 and keyboard set to English PRODUCE THE SAME RESULTS
Third
My test above using an editor on this site is more clear and simple
How is WEB application with PHP code, DB, CKEditor and lots of other stuff is more simple than HTML sample page using CKEditor and jQuery?
and it also shows that webkit left alt + s works in plain text mode.
Excuse me for being sarcastic but do you think, in all this simplicity of vBulletin example, that it might be possible that PHP code just ads something extra that makes this particular case work?
Mine test shows that there are no problems with CKEditor. Problem should be rather looked in Browser not editor as I have proved that when getting rid of the editor, left alt still produces system sound.
comment:9 Changed 14 years ago by
Hello,
Here is a separate test case demonstrating what R1Lover is reporting. It is based on the test case provided by j.swiderski.
In Firefox 5, by default, ALT + S opens the History menu. To access the access key, you have to hold SHIFT+ALT+S. This produces an alert box. In IE 8, ALT+S produces an alert box. In Google Chrome 12 and Safari 5, it produces a system sound.
When I remove the CKEditor.replace() call, all browsers will submit the post with ALT+S (except Firefox 5, which needs the SHIFT key as well, by default).
This test case shows that with CKEditor, Google Chrome and Safari 5 will not utilize the access key with focus inside the editor, while other browsers will. Without CKEditor, all browsers work as expected.
Hope this helps to clear up the confusion.
comment:10 Changed 14 years ago by
Keywords: | Webkit added; Chrome removed |
---|---|
Status: | pending → confirmed |
Version: | → 3.0 |
Thank you @bfarber. Your TC contrary to mine shows that there is a problem with CKEditor blocking accesskey.
This issue has been reproducible in Webkit browsers from CKE 3.0
comment:12 Changed 13 years ago by
So now that this has been confirmed as a bug, what is the timeline we are looking at for a possibile fix?
comment:13 Changed 13 years ago by
Echo, echo........ So was this all for not? A little commnication goes a long way
comment:14 Changed 13 years ago by
The test case 3 removes the unused jQuery script and instead of using CKEditor, it places directly an editable iframe, so there is no relationship to jQuery or CKEditor and it clearly shows that this is just a webkit problem.
So I would close this ticket as invalid, and suggest you to file a bug in https://bugs.webkit.org/
comment:15 Changed 13 years ago by
Resolution: | → invalid |
---|---|
Status: | confirmed → closed |
Taking into account that editor contents are placed inside iframe (textarea is "replaced") with body's attribute contenteditable set to false, this third TC seems to be most valid and it shows that there is no bug in CKEditor after all. Closing the ticked as invalid.
Is this reproducible in other WebKit browsers like Safari, too?