#10415 closed task (fixed)
Make dijit.Editor use contentEditable in Firefox whenever it supports it
| Reported by: | MarcosPri | Owned by: | bill |
|---|---|---|---|
| Priority: | low | Milestone: | 1.7.6 |
| Component: | Editor | Version: | 1.4.0b |
| Keywords: | Editor, Firefox | Cc: | [email protected]… |
| Blocked By: | Blocking: |
Description
Now the editor is using desingmode in all version of Firefox but it supports contentEditable since version 3.
It seems now that contentEditable is going into HTML 5 specification so sounds like a good idea to use it in Firefox from version 3+ and avoid the annoyances of two different implementations for the editor whenever possible.
Attachments (2)
Change History (21)
comment:1 Changed 11 years ago by
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
comment:2 Changed 11 years ago by
PS: your comment about "avoid the annoyances of two different implementations for the editor" is inaccurate, as editor is currently using an iframe everywhere... there's only one implementation.
Still, a patch to convert the editor to always use a contentEditable <div> would be welcome. Note that dojo no longer supports FF2 or earlier.
We need some kind of solution to support user defined stylesheets (probably automatically rewriting the stylesheet so that each pattern includes the id of the editor's div). Also need to make sure that we don't lose the selected text when using the keyboard to navigate from the content to the toolbar.
comment:3 Changed 11 years ago by
I might be mistaken but I think that even the iframe is used everywhere in ff it's editable using designmode and contentEditable in other browsers.
One of that annoyances is that you can't insert a contentEditable="false" element in the editor to have some not editable parts in it -it will be editable in ff, the whole document is because of designmode- and be cross browser compatible (really a minor annoyance, probably not a very common scenario)
comment:4 Changed 11 years ago by
| Component: | Dijit → Editor |
|---|---|
| Milestone: | tbd → 1.5 |
| Resolution: | duplicate |
| Status: | closed → reopened |
Ah sorry, I misunderstood. Yes, I see the RichText._setDisabledAttr() is branching for FF vs. other browsers.
Worth a try to remove that FF specific branch (as you suggested).
comment:6 Changed 11 years ago by
| Milestone: | 1.5 → future |
|---|
comment:7 Changed 11 years ago by
Interestingly, I tried this and it seemed to edit fine, but it causes some A11Y tab navigation to fail! Very strange. I'm attaching on what I changed as an example, but need to look into why tab nav fails with it.
Changed 11 years ago by
| Attachment: | ContentEditable_TabNavFails.patch added |
|---|
This swaps to ContentEditable?, but then the A11Y tab nav tests fail. Very odd.
comment:8 Changed 11 years ago by
Not sure why using contentEditable changes the tab order. With the patch it takes two tab stops to get from the toolbar into the editor with an insertion caret. When I look at these with inspect32 it shows focus on the same object - the document of the iframe. Not sure why? Need to examine the code more closely.
comment:9 Changed 8 years ago by
| Priority: | high → low |
|---|
comment:10 Changed 8 years ago by
I'd really like to see this getting resolved since designMode implicitly disables UI elements. This is not done with contentEditable, so that e.g. <select> can be used in the editor.
comment:11 Changed 8 years ago by
The good news is that the problem Becky mentioned above seems to have gone away. On the downside, the patch causes new failures in Editor_a11y.html, in the keyboard navigation tests.
Another complication is that there's an existing failure in the Editor_a11y "tabbing" test suite, dealing with detecting when the <iframe> has gotten focus. This patch actually helps to fix that failure; previously we weren't getting any focusin event at all; now we are getting the notification, but it's being ignored due to this code in focus.js, because tag == "body":
// IE reports that nodes like <body> have gotten focus, even though they have tabIndex=-1, // ignore those events var tag = evt.target.tagName.toLowerCase(); if(tag == "#document" || tag == "body"){ return; }
comment:12 Changed 8 years ago by
| Milestone: | future → 1.10 |
|---|---|
| Owner: | set to bill |
| Status: | reopened → assigned |
comment:13 Changed 8 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:16 Changed 7 years ago by
| Type: | enhancement → task |
|---|
Changing to category "task" since presumably this has no impact on users.
comment:17 Changed 7 years ago by
| Milestone: | 1.10 → 1.8.7 |
|---|
comment:19 Changed 7 years ago by
| Milestone: | 1.8.7 → 1.7.6 |
|---|
Dup of #6582.