Opened 11 years ago

Closed 3 years ago

#1508 closed defect (no action needed)

Editing inside DIV elements now almost impossible in Xinha/IE

Reported by: guest Owned by: gogo
Priority: normal Milestone: 0.97
Component: Xinha Core Version: trunk
Severity: major Keywords: IE, div


I'm not sure if it was the "focus" fix for #1268 which created the problem (I haven't updated my server installation for a while), but now in IE8 when attempting to edit content within absolutely positioned DIV tags, it is impossible to use any of the navigation keys (forward arrow, back arrow, etc.) without IE losing its focus inside the DIV area (the cursor jumps immediately to the end of the DIV, outside it). The problem might be related to the striped box which appears, in IE only, when editing inside absolutely positioned DIV tags. This was obscuring the "new" dialog system. The fix in #1268 was to force IE8 to focus on the first text field in the dialog box. Now, however, even without invoking a dialog, the striped box disappears as soon as one types anything inside the DIV. It is possible to continue typing, but as soon as one uses a navigation key, the cursor jumps outside the DIV, requiring a double-click to get back in. This effectively renders IE useless for editing such documents. NB Firefox does not have this problem, since it handles editing inside DIVs in a much more transparent manner.

-- Geoffrey K

Change History (4)

comment:1 Changed 10 years ago by gogo

  • Milestone changed from 0.96 to 0.97

The problem stems from updateToolbar, getParentElement, and IE's insistance to return a "None" selection.

When updateToolbar runs it tries to find the parentElement of the current selection, to update things like formatblock.

getParentElement() grabs the selection (InternetExplorer?.js)

It then tries to create a range from the selection using createRange() (also InternetExplorer?.js)

createRange() sees the selection it got is "None" and does a focusEditor(), which apparently defocuses the absolutely positioned div (removes the caret from it).

changeset:1259 removes the attempt to focusEditor() on a None selection when creating a range. I have no idea if this will have side-effects, but it appears to help.

focusEditor() however is still used in quite a few places, like when inserting html. I suspect that this means that there is more than just this broken when it comes to absolute positioned editing in IE.

We could use somebody who can put in some debugging time into working out the selection, range and focusEditor() stuff for IE, since it appears to have gotten a bit buggy with IE8 :-(

Leaving open for 0.97, in the vain hopes that somebody might take pity on it and have a closer look.

comment:2 Changed 10 years ago by gogo

See also #1510

comment:3 Changed 10 years ago by gogo

See also #1471

comment:4 Changed 3 years ago by gogo

  • Resolution set to no action needed
  • Status changed from new to closed

Seems to work ok in IE 11, guess M/Soft fixed things.

test case, switch to html, paste below, switch back to wysiwyg, click into area (double click, click to select, click to edit into it) and you can type and move freely

<div style="border: 1px solid black; border-image: none; left: 10px; top: 10px; width: 400px; height: 300px; position: absolute; background-color: red;"> 
    <p>Hello This is a test</p>  </div>
Note: See TracTickets for help on using tickets.