Opened 11 years ago

Closed 9 years ago

#6582 closed task (wontfix)

land editor refactor to remove iframes in most situations

Reported by: alex Owned by: alex
Priority: low Milestone: future
Component: Editor Version: 1.1.0
Keywords: refactor Cc: liucougar
Blocked By: Blocking:


like it says on the tin. The editor may be horribly broken after this change.

Change History (17)

comment:1 Changed 11 years ago by alex

(In [13373]) lands the RichText? refactor to remove use of iframes unless explicitly requested or on a degenerate browser (e.g., FF2). Refs #6582. !strict

comment:2 Changed 11 years ago by liucougar

(In [13374]) refs #6582: re-merge [13304], [13328], [13335], [13262] and [13257] which were lost in the refactor

comment:3 Changed 11 years ago by liucougar

(In [13375]) refs #6582: use dijit._editor.getChildrenHtml instead of Editor.getChildrenHtml

comment:4 Changed 11 years ago by liucougar

(In [13382]) refs #6582: detect useIframe correctly when styleSheets or useIframe is explicitly specified refs #6584: fix broken auto-expand when iframe is used refs #6583: enable alwaysshowtoolbar plugin for editor when iframe is used (which is needed to support auto-expand)

comment:5 Changed 11 years ago by Adam Peller

(In [13577]) Fixes #6376 on 1.1 branch only, to defer setValue if editor is still loading. No longer a problem on trunk after Alex's refactor (see #6582)

comment:6 Changed 11 years ago by Adam Peller

Component: GeneralEditor
Priority: normalhigh

comment:7 Changed 11 years ago by bill

Type: enhancementtask

Notes from Alex at dojo meeting a few days ago, about remaining work on this:

Remaing work deals w/focus.

Tabbing from the toolbar to the editor itself is b0rken now that they're in the same document (the selection range gets oblitterated, etc). So calling the commands doesn't "work" the way it used to since the selection may be hosed so the selection range gets collapsed when you focus on something else and the undo stack gets polluted.

Anyway, we've noted this all before. The solution is to excise the command system and make sure that focus events preserve selection at all times.

comment:8 Changed 11 years ago by liucougar

just tried tab/shift-tab in the editor, it does not invalidate the selection in editor

comment:9 Changed 11 years ago by alex

(In [14733]) first in a set of large-ish merges to address issues related to the iframe refactor. This patch shortens the existing code, adds some documentation, and adds the first handling of selection saving when focus is changed. Refs #6582. Refs #5707 !strict

comment:10 Changed 11 years ago by bill

(In [14975]) Copy dijit.Editor to dojox.editor.Editor in preparation to rollback iframe refactor until a future release, when it's finished.

Didn't bother copying over the nls/ files, and still using dijit CSS class names and rules in dijit/themes.

Refs #6582 !strict

(assuming my svn client is working correctly these files should by "svn cp"d from dijit/ to dojox/, with changes for namespaces.)

comment:11 Changed 11 years ago by bill

Milestone: 1.21.3

comment:12 Changed 11 years ago by bill

Iframe refactor rolled back in [14992] (but other changes kept).

comment:13 Changed 11 years ago by bill

Component: EditorDojoX Editor

comment:14 Changed 11 years ago by Adam Peller

Component: DojoX EditorEditor
Keywords: refactor added
Owner: changed from alex to liucougar

comment:15 Changed 10 years ago by bill

Milestone: 1.3future

comment:16 Changed 10 years ago by Douglas Hays

Owner: changed from liucougar to alex
Priority: highlow

comment:17 Changed 9 years ago by Jared Jurkiewicz

Resolution: wontfix
Status: newclosed

The iframe is extremely valuable in many cases as it provides the following cababilities:

1.) Segregation of user page styles from editor content styles. 2.) The ability to dynamically add styles to the editor that do not affect the rest of the page. This is how plugins like: dojox.editor.plugins.ViewBlockNodes?, dojox.editor.plugins.InsertAnchor?, and dojox.plugins.PageBreak? all work. They dynamically inject styles into the editor iframe 3.) The ability to easily print the editor content. In most browsers, you can print an iframe by just doing window.print() on it (or similar). This provided for a very simple implementation of a print capability.

So, at this time I think this ticket should be closed as a 'wontfix'. The iframe provides a lot of benefits, even with the headaches it can also introduce.

Note: See TracTickets for help on using tickets.