Opened 10 years ago
Closed 10 years ago
#13187 closed Bug (fixed)
Paste check doesn't work.
Reported by: | Artur Delura | Owned by: | Piotr Jasiun |
---|---|---|---|
Priority: | Normal | Milestone: | CKEditor 4.5.0 |
Component: | General | Version: | 4.5.0 Beta |
Keywords: | Cc: | IRINAURU@…, giorgio, satya_minnekanti@…, chrisgui@… |
Description
- Open new sample in presets.
- Select some text external/internal.
- Paste into editor.
I doesn't paste content.
It's a regression, it worked in 4.4.7.
Change History (12)
comment:1 Changed 10 years ago by
Milestone: | → CKEditor 4.5.0 |
---|
comment:2 Changed 10 years ago by
Status: | new → confirmed |
---|
comment:3 Changed 10 years ago by
Owner: | set to Piotr Jasiun |
---|---|
Status: | confirmed → assigned |
comment:4 Changed 10 years ago by
Status: | assigned → review |
---|
comment:5 Changed 10 years ago by
Status: | review → review_failed |
---|
On Chrome running in desktop mode this check does not work, because it is recognised as a desktop browser, but has the same, limited API.
comment:6 Changed 10 years ago by
So... Unfortunately on the android in the desktop mode userAgent
looks like desktop, what we could expected (Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Safari/537.36
), but the API is still mobile, so Clipboard API still does not work, what we could expected too.
The situation is even worst because I can not detect feature by setting and getting custom data, because it is not possible to setData on paste on Chrome in general.
The solution would be to change the way we check if we should use paste bin or clipboardData
. We could use clipboardData
if it not empty and the browser support HTML in it.
I pushed such solution to the t/13187b and checked all browsers:
- on IE and Safari we need to use pastebin, because HTML data are not available other way during the external drop (only text data are available via
clipboardData
), - on Firefox the bug mentioned in http://dev.ckeditor.com/ticket/11461#comment:8 seems to be fixed and we should be able to rely on the
clipboardData
; I did not believe, but I tested it on Linux and Windows and the same data are available inclipboardData
and pasteBin in both cases; on Linux it is not possible to get file any way, on Windows it works fine using clipboard data, - Chrome works fine using the new method on Linux, Windows and Android.
comment:7 Changed 10 years ago by
Status: | review_failed → review |
---|
I realized that after that change internal/cross editor drag and drop on Safari starts using pasteBin, and they should not, so I have added one more condition to check the transfer type.
To be honest I do not like this solution because it touch a lot strange cases and we can easily forget about something. On the other hand it for not only Chrome@Android-inDesktopMode case, but also update Firefox behavior after they fix the issue.
At this stage it could be reviewed.
comment:8 Changed 10 years ago by
http://dev.ckeditor.com/ticket/13264#comment:5 this comment clearly proves that the current check doesn't make sense.
comment:9 Changed 10 years ago by
Cc: | IRINAURU@… giorgio satya_minnekanti@… chrisgui@… added |
---|---|
Status: | review → assigned |
Closed #13264 as a DUP of this ticket. See http://dev.ckeditor.com/ticket/13264#comment:6 for what is expected from this ticket.
comment:10 Changed 10 years ago by
Status: | assigned → review |
---|
I created a manual test to check if everything is fine. We need to test how it works on all browsers. Changes in t/13187b .
comment:12 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | review → closed |
Summary: | Paste doesn't work on android chrome → Paste check doesn't work. |
Deeply tested and closed with git:0e2ae53.
Unfortunately clipboard API does not work fine on the Android Chrome and we need to use paste bin there.
Because there are differences between mobile and desktop Chrome I changed
CKEDITOR.env
, so now Android Chrome is marked asmobile
and introducedCKEDITOR.env.android
flag. After these changes this ticket should be closed: #11725.Changes in t/13187.