Opened 9 years ago
Closed 9 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.
Attachments (4)
Change History (22)
comment:1 Changed 9 years ago by
Keywords: | WebKit added; Safari removed |
---|---|
Status: | new → confirmed |
comment:4 Changed 9 years ago by
Milestone: | → CKEditor 3.6.2 |
---|
comment:5 Changed 9 years ago by
Keywords: | WebKit added |
---|
Changed 9 years ago by
Attachment: | 8342.patch added |
---|
comment:6 Changed 9 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 9 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 9 years ago by
Attachment: | 8342_2.patch added |
---|
comment:8 Changed 9 years ago by
Owner: | changed from Sa'ar Zac Elias to Garry Yao |
---|---|
Status: | review_failed → review |
comment:9 Changed 9 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 9 years ago by
Status: | review_failed → review_passed |
---|
R+ for first patch, I thought wrongly last review.
comment:11 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | review_passed → closed |
Fixed with [7267], I see that the tt was already updated.
comment:12 Changed 9 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 9 years ago by
Attachment: | 8342_3.patch added |
---|
comment:13 Changed 9 years ago by
Status: | reopened → review |
---|
comment:15 Changed 9 years ago by
Keywords: | NeedsTest removed |
---|---|
Resolution: | → fixed |
Status: | review_passed → closed |
Fixed with [7269].
Changed 9 years ago by
Attachment: | 8342_4.patch added |
---|
comment:16 Changed 9 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
As previous commit doesn't pass the tt in all browsers.
comment:17 Changed 9 years ago by
Status: | reopened → review |
---|
comment:18 Changed 9 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.