Opened 14 years ago
Closed 14 years ago
#8342 closed Bug (fixed)
ReadOnly sample - paste buttons reenabled, when "make read only" pressed
Reported by: | Krzysztof Studnik | Owned by: | Garry Yao |
---|---|---|---|
Priority: | Normal | Milestone: | CKEditor 3.6.2 |
Component: | UI : Toolbar | Version: | 3.6.2 |
Keywords: | WebKit | Cc: |
Description ¶
Safari/Mac
TC ¶
- go to sample ReadOnly
- press "make read only" button : Editing is disabled, Copy/paste buttons are disabled
- click editor body, and press some random keys on keyboard
Result ¶
Paste as text, paste, paste from word buttons on toolbar are reenabled. When paste from word button is pressed, dialog window opens and user is able to paste ms word content. Text, pasted into dialog window, is not pasted to editor body.
Expected ¶
Operations done on editor body, while read only mode is enabled, should not have influence on toolbar. Disabled buttons should stay disabled.

Change History (22)
comment:1 Changed 14 years ago by
Keywords: | WebKit added; Safari removed |
---|---|
Status: | new → confirmed |
comment:4 Changed 14 years ago by
Milestone: | → CKEditor 3.6.2 |
---|
comment:5 Changed 14 years ago by
Keywords: | WebKit added |
---|
Changed 14 years ago by
Attachment: | 8342.patch added |
---|
comment:6 Changed 14 years ago by
Owner: | set to Sa'ar Zac Elias |
---|---|
Status: | confirmed → review |
Since I didn't find anything else that doesn't work.. I think it's safe to just check read only mode to avoid problems.
comment:7 Changed 14 years ago by
Keywords: | NeedsTest added |
---|---|
Status: | review → review_failed |
Not all clipboard commands are to be excluded from readonly, e.g. "copy". Please add a automatic test for it.
Changed 14 years ago by
Attachment: | 8342_2.patch added |
---|
comment:8 Changed 14 years ago by
Owner: | changed from Sa'ar Zac Elias to Garry Yao |
---|---|
Status: | review_failed → review |
comment:9 Changed 14 years ago by
Status: | review → review_failed |
---|
- Tests don't pass with that patch in IE and FF.
- Noneditable selections are not being considered with the patch, e.g.
<p contenteditable="false">aa^aa</p>
Note that the copy command is anyway disabled in WebKit, not due to the patch.
comment:10 Changed 14 years ago by
Status: | review_failed → review_passed |
---|
R+ for first patch, I thought wrongly last review.
comment:11 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | review_passed → closed |
Fixed with [7267], I see that the tt was already updated.
comment:12 Changed 14 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
After some investigation, there's a deeper reason behind this bug instead, which is caused by JS error on "selectionchange" event listeners.
Changed 14 years ago by
Attachment: | 8342_3.patch added |
---|
comment:13 Changed 14 years ago by
Status: | reopened → review |
---|
comment:15 Changed 14 years ago by
Keywords: | NeedsTest removed |
---|---|
Resolution: | → fixed |
Status: | review_passed → closed |
Fixed with [7269].
Changed 14 years ago by
Attachment: | 8342_4.patch added |
---|
comment:16 Changed 14 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
As previous commit doesn't pass the tt in all browsers.
comment:17 Changed 14 years ago by
Status: | reopened → review |
---|
comment:18 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | review → closed |
Yet another the review reveals it a fabricated problem created by the tc instead of a real bug, the patch is obsoleted after tc is updated.

Regression of this version, also in Chrome.