Hi Marius, Allowing the user to edit the pasted content using a rich text area
before cleaning is not a good idea because the HTML generated by these Office suites can easily mess up the rich text area. The best option I think would be to have a panel (div) that can catch paste events and set the pasted content as its inner HTML.
Yes, this sounds like a good idea. But is it the div+onpaste event that we should use or something like an iframe with designMode enabled ? (I think latter is used in many hand crafted html editors) In any case, GWT doesn't seem to have generic support for either of these, so we might have to worry about cross-browser issues. Also, to let the user paste content into some element (either div or an iframe), we somehow have to enable the designMode (or something similar). So, this means the user will anyway be able to edit the content after pasting it. Btw, by moving the Import dialog box you loose the pasted content
because the in-line frame used by the rich text area is detached during dragging and a new document is created each time the in-line frame is (re)attached. This is a dialog box bug anyway.
I'm wondering if this bug is enough reason for us to give up on the standard GWT rich-text-area (no cross-browser issues). It's a terrible bug ofcourse, but how many users will actually face it in day to day use ? 4. Ask the user. He may know better which Office suite he's using. Of
course, you need to provide also an option like "Don't know" or "Others" in which case you can apply one of the previous 3 solutions. Ideally, if possible, you would use solution 2 to detect the Office suite but still allowing the user to change it.
Cool. This apporach is more extensible I think. First we can start with a generic exhuastive html cleaner and progressively introduce specific cleaners when we feel the need (since we have the office suite information provided by the user). Or use a placeholder for local images with a tooltip explaining that
those images couldn't be uploaded.
+1. Thanks. - Asiri