Opened 11 years ago

Closed 10 years ago

#1259 closed defect (fixed)

Editor still active when dialog is open (new-dialogs branch)

Reported by: guest Owned by: nicholasbs
Priority: normal Milestone: 0.96
Component: User Interface Version:
Severity: normal Keywords: new-dialogs
Cc:

Description

To reproduce:

1) Click insert image (or any other plugin that has been converted to the new dialog system)
2) Tab through the form elements. If you tab enough times you'll end up back in the editor field and can type whatever you like as well as use editor controls (e.g., the font popup menu).

This is almost certainly not the desired behavior, as it seems odd that users should be able to tab out of the dialog.

This happens in both Firefox 3.0.1 and Safari 3.1.2 on Mac OS X 10.5.4.

Change History (6)

comment:1 Changed 11 years ago by guest

I've looked into this a bit more, and there is indeed code already in place that calls deactivateEditor() when a modal dialog is opened (and activateEditor() when the dialog is hidden), however, tabbing changes focus to the editor, which in turn calls activateEditor().

comment:2 Changed 11 years ago by nicholasbs

  • Owner set to nicholasbs
  • Status changed from new to assigned

Changeset r1018 contains a fix for this bug.

The fix works by:

1) Adding a currentModal attribute to the editor object, which gets updated any time a modal dialog is shown/hidden. If there's a modal dialog on the screen, currentModal should contain a reference to it. Otherwise, currentModal will be null.

2) XinhaCore?'s _editorEvent() handler checks to see if currentModal is set. If it is, the event is not propagated. Note that this happens *after* calling firePluginEvent(), so this should not interfere with plugins being notified of events.

Does this seem like a reasonable fix? Anyone see any issues with it or ways it could be done better?

comment:3 Changed 10 years ago by nicholasbs

r1089 is an improved fix for this bug. Once I confirm that it works in IE and Chrome, I'll close this ticket.

comment:4 Changed 10 years ago by nicholasbs

  • Resolution set to fixed
  • Status changed from assigned to closed

I have tested this now in IE (6 and 7), Chrome, and Firefox under Windows, and the fix works to the extent that it keeps the user from editing the document when a modal dialog is open (also, the toolbar is never accidentally enabled).

There's still some weirdness in the way IE and Chrome handle tabbing, but that's a separate (and less significant) issue.

comment:5 Changed 10 years ago by nicholasbs

  • Resolution fixed deleted
  • Status changed from closed to reopened

Turns out this breaks selection restoration, reopening ticket.

comment:6 Changed 10 years ago by nicholasbs

  • Resolution set to fixed
  • Status changed from reopened to closed

Changeset r1093 fixes the selection restoration issue.

Note: See TracTickets for help on using tickets.