Bug 43628 - tinyMCE is lacking a unload handler (as already described in the tinymce todo list)
Summary: tinyMCE is lacking a unload handler (as already described in the tinymce todo...
Status: NEW
Alias: None
Product: Lenya
Classification: Unclassified
Component: TinyMCE Integration (show other bugs)
Version: 2.0
Hardware: Macintosh All
: P3 normal
Target Milestone: 2.0.1
Assignee: Lenya Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-15 14:25 UTC by Juergen Ragaller
Modified: 2007-10-25 07:22 UTC (History)
0 users



Attachments
the attached patch show a possible approach (12.00 KB, patch)
2007-10-15 14:35 UTC, Juergen Ragaller
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Juergen Ragaller 2007-10-15 14:25:43 UTC
Currently tinyMCE can be exited by clicking any link outside the editable area. This can
lead to data loss and always leads to a locked page (force checkin has to be used).
Comment 1 Juergen Ragaller 2007-10-15 14:35:03 UTC
Created attachment 20986 [details]
the attached patch show a possible approach

It is still in a raw form and is meant as an illustration of concept - please
do not apply as is.
Comment 2 J 2007-10-25 06:41:04 UTC
i've read the patch, and it looks very good and in keeping with tinymce coding
style. however, i'm wondering:
tinymce has this issue because it tries to provide true wysiwyg in-place editing.
this capability might be highly desirable for other editors, too.

maybe we could implement a generic onunload() handler that will run an
editor-specific callback if provided (similar to the way richard implemented the
backspace catcher in an editor-agnostic way).

what does an onunload() handler need to do? 
* catch the onunload event and prevent leaving the current page.
* provide a message that informs the user of unsaved data and allows to "leave",
"save and leave", "return to editor".

"leave" must remove the lock on the document and then execute the previously
caught navigation event.
"save and leave" will have to signal the editor (invoke its save callback) and
then navigate away.
"return" just eats the unload event and return to the editor.

wdyt?
Comment 3 Juergen Ragaller 2007-10-25 07:22:59 UTC
(In reply to comment #2)
> this capability might be highly desirable for other editors, too.

A big +

> 
> maybe we could implement a generic onunload() handler that will run an
> editor-specific callback if provided (similar to the way richard implemented the
> backspace catcher in an editor-agnostic way).

another big +

> 
> what does an onunload() handler need to do? 
> * catch the onunload event and prevent leaving the current page.
> * provide a message that informs the user of unsaved data and allows to "leave",
> "save and leave", "return to editor".
> 
> "leave" must remove the lock on the document and then execute the previously
> caught navigation event.
> "save and leave" will have to signal the editor (invoke its save callback) and
> then navigate away.
> "return" just eats the unload event and return to the editor.

Another big + for the idea. The problem with document.onbeforeunload is, that it
triggers a predefined screen that can only partially be modified. It would be
very nice to have the three options you described - but I did not find a way to
display and process a custom screen on an onbeforeunload event. Maybe there is a
better way to do the event handling than using window.onbeforeunload.