Ticket #1372 (closed defect: fixed)

Opened 16 months ago

Last modified 13 months ago

Change Detection Broken in TinyMCE 2.1.1.1 cause Confirm dialogue every time page is edited

Reported by: elijahlofgren Owned by: aoneil
Priority: medium Milestone: 2.2.0*
Component: CMS - TinyMCE editor Version:
Severity: medium effort / impact Keywords:
Cc: Hours:

Description

As I posted on Topic: Change Detection Broken in TinyMCE 2.1.1.1 cause Confirm dialogue every time page is edited

As of r39560 in the gsoc branch, any change to a HtmlEditor? field will cause a confirm dialogue to show whenever new selection is made in the left tree even if the "Save" button has been clicked.

This bug was caused by r38620 which merged in TinyMCE 2.1.1.1 because after doing the following, the bug disappears: svn up cms --revision 38619 && svn up jsparty/ --revision 38619 && svn up sapphire/ --revision 38619

I had originally filed this on the gsoc trac because I thought I may have caused it: TinyMCE 2.1.1.1 Breaks Change Detection (hack workaround attached)

Attachments

Hack-To-Fix-TinyMCE-Change-Detection-cms-gsoc-r38861.diff (1.9 kB) - added by elijahlofgren 16 months ago.
Hack that works around this problem (not optimal)

Change History

Changed 16 months ago by elijahlofgren

Hack that works around this problem (not optimal)

Changed 16 months ago by elijahlofgren

Also, I wonder if this could be related to $("Form_EditorToolbarLinkForm").respondToNodeChange is not a function

Changed 16 months ago by elijahlofgren

I wonder if this patch would fix this bug: SourceForge.net: Detail: 1510278 - Transparent onchange-event transportation to the old textare

Here is a pasted copy of the patch:

Summary: Transparent onchange-event transportation to the old textare

A new blur-handler for handleEvent in the core-editor for triggering onchange-event on the original textarea (or whatever it was):

case "blur": var inst = tinyMCE.selectedInstance;

if (inst) inst.execCommand('mceEndTyping');

if (inst && inst.oldTargetElement && inst.oldTargetElement.onchange) { var newvalue = inst.getBody().innerHTML;

if (inst.oldTargetElement.value != newvalue) { inst.oldTargetElement.value = newvalue; inst.oldTargetElement.onchange(); } }

tinyMCE.hideMenus();

return;

Changed 16 months ago by elijahlofgren

Or this could possibly be the problem: [ 1520971 DOCTYPE effects event handler in IE] Description of problem: In IE, selecting the browser scrollbar does not cause the tinyMCE editor to lose focus. However, if a doctype of the following form is used, event handlers will be ignored once the browser scrollbar is selected: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dt d">

Using this doctype the bug does not occur: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

Changed 16 months ago by elijahlofgren

I see this in triggerNodeChange() in tiny_mce_src.js

tinyMCE.dispatchCallback(inst, 'handle_node_change_callback', 'handleNodeChange', editorId, elm, undoIndex, undoLevels, inst.visualAid, anySelection, setup_content);

Maybe if we added some sort of handle_node_change_callback function to reset change detection or something it would help.

Changed 13 months ago by sminnee

  • owner changed from sminnee to aoneil
  • harvest_task set to (Unknown)
  • invoice_sent set to 0
  • milestone set to 2.2.0

As I understand it, Andrew - you have been working on this today?

Changed 13 months ago by aoneil

  • status changed from new to closed
  • resolution set to fixed

This is all fixed now (finally).

Note: See TracTickets for help on using tickets.