CKEditor component released version 0.1

Vaadin 6 / 7 / 8 Framework UI
21

Just released the 0.8 version of the CKEditor component. I always forget to update the Directory’s “release notes” before selecting the file to upload (maybe the upload button needs to be lower in the UI?), but here they are:

0.8 (4 November 2010)

  • Using CKEditor 3.4.2.
  • Recompiled with Vaadin 6.4.7.
  • Added setting the root DIV element to be visible so that Firefox will show it on popup windows – previously, it would only show the editor area
    once in Firefox, and then it would disappear every time after in popup windows, yet would still work in panels off the main window.
  • Added ability to set the body class CKEditor will use so it renders like how you may show the HTML on another page: config.setBodyClass(String bs)
    This is particularly useful if you are using config.setContentsCss() to specify a CSS file that should be used in the editor and when rendered.
  • Added ability to set the baseFloatZIndex: config.setBaseFloatZIndex(int zindex)
    This can be useful if your editors are opened in popup windows. Found that the default (10000) wasn’t enough and we’re using 32000 for Open eSignForms.
  • Added ability to set another option: config.setPasteFromWordNumberedHeadingToList(boolean) – testing it out ourselves.
  • Added ability to set the startupMode to “source”: config.setStartupModeSource()
22

Does anybody at Vaadin or in the forums have any thoughts on this?

Is it a bug for a modal windows to hold an input component that then attempts to open more windows since the idea of the first modal window is that it gets the focus and nobody else does?

Or should it be possible for a modal window to include such a widget? We have another user complaining about this, but I have no idea if there’s a solution or not.

Thanks!

23

Opening a modal Vaadin window from a modal Vaadin window should work in theory, although there are some related issues (e.g.
#6159
,
#5435
).

Your issue might be related either to focus being in the wrong place (it should probably be on the top-most modal dialog) or perhaps to modality curtains blocking user actions (#6159).

24

Is there a way I can determine this? Like where does the click/typing go?

I know that the modal windows in CKEditor work fine when the editor itself is in a regular Vaadin window, but fails in a modal window.

25

Maybe if I understood how “modal” is implemented in Vaadin windows it would be something we could figure out. Here’s what little I have learned:

  1. A Vaadin popup windows uses a z-index of 10000. It also creates a “v-window-modalitycurtain” div with the z-index at 10000.
  2. The default z-index of ckeditor dialogs is 10000.
  3. If I change ckeditor to use a z-index of 1000, it’s dialogs will appear behind the vaadin window. The vaadin window remains usable and can accept additional clicks, but of course the ckeditor popup itself cannot be accessed.
  4. If I leave it at the default of 10000, or up it 20000, it makes no difference. The ckeditor dialog appears on top either way, as expected, but that dialog won’t accept clicks or data entry, yet it’s clearly “alive” in that you can see mouseovers and cursor changes as you move around the dialog.
  5. In FF, I see no NET activity when I try to click or deal with the ckeditor popup dialog, so nothing is going back to the server – it’s all in the browser.

I did note that CKEditor creates a “dialog background cover” div using the z-index value specified, and the dialog div itself is 10 more. So the dialog background cover that grays out the entire browser area is 10000, while the dialog div+table is set at 10010.

Is there CSS or something else that is used to control “focus” for the keyboard/mouse events? If the vaadin popup window’s modal is turned off, it all works as expected. Is there a way to determine what is getting the key/mouse events?

26

Here’s a
video that shows the bug
 if that helps…

http://youtu.be/H4IlLpFI2ac

27

Okay, noted a few new things that may help someone understand what is going wrong:

On IE9, I can still right click in a field and PASTE data into the fields, just can’t type or click. FF5 doesn’t seem to allow this.

Using CSS, I was able to convert the A and INPUT tags to have a z-index of 40000, but that made no difference.

Lastly, in FF5 with Firebug, I noted that even Firebug cannot select a field by clicking on it. It’s as if the entire browser refuses to allow the click in that area, but I Firebug can still select other elements in the window below. To navigate to the input fields in Firebug, I have to basically open the DOM tree to zero down to the actual INPUT element rather than just click on it using the element inspector.

28

Here’s the solution:

Problem: when a window is displayed in modal mode, it capture all events and only allow those belongs to the active window.

Fix:

  1. Override the VWindow as below:
/**
 * <p>
 * A placement of VWindow implementation to fix issue with CKEditor component in a modal window.
 * </p>
 * 
 * @see http://code.google.com/p/vaadin-ckeditor/issues/detail?id=10
 * @see https://vaadin.com/forum/-/message_boards/view_message/238571
 * 
 * @since 1.2
 * @author ttran
 **/
public class GWindow extends VWindow
{
    private boolean modal;

    /**
     * {@inheritDoc}
     * 
     * @see VWindow#updateFromUIDL(UIDL, ApplicationConnection)
     */
    @Override
    public void updateFromUIDL(final UIDL uidl, final ApplicationConnection client)
    {
        if (uidl.hasAttribute("modal")) //$NON-NLS-1$
            modal = uidl.getBooleanAttribute("modal"); //$NON-NLS-1$
        super.updateFromUIDL(uidl, client);
    }

    /**
     * {@inheritDoc}
     * 
     * @see VWindow#onEventPreview(Event)
     */
    @Override
    public boolean onEventPreview(final Event event)
    {
        if (modal)
            return true; // why would they block click to other elements?
        return super.onEventPreview(event);
    }
}
  1. Setup your own widgetset and have this somewhere in the module.xml:
	<replace-with class="com.genix.platform3.commons.widgets.gwt.client.ui.GWindow">
		<when-type-is class="com.vaadin.terminal.gwt.client.ui.VWindow"/>
	</replace-with>

Voila, it works.

So if anyone can explain the rationale behind the blocking events outside modal windows, I would like to hear.

Cheers,
Tien

29

Thanks. We’ll give this a try. Great job digging into it…

Does your solution imply that VWindow has a bug in not handling this correctly and that we should report this to Vaadin for a fix?

30

Released 1.6.4 with this patch as it does seem to do the trick. Thanks Tien!

31

I wouldn’t call it a bug but rather an annoying intended design. Hope that this was not aware at the time and they will incorporate the improvement :bashful:

The ticket
9001
 has been created by the way.

TT

32

Tien,

Have you played with Vaadin 7 yet? We are doing a quick & dirty port of CKEditor for Vaadin now (based on the 1.8.2 version) to support Vaadin 7 and we have it seemingly working except for that modal issue. I’m not sure how to get your modal fix to VWindow to work in this new scheme since there’s no updateFromUIDL method in the new VWindow (which has also moved packages).

If you have any ideas, I’d like to incorporate this fix again. Otherwise I’ll release a version for Vaadin 7 that just suffers the modal bug again so at least some people can begin playing with it (we don’t use editors in modal windows anyway, so it’s not a problem for us personally).

I updated ticket 9001 with these details:
In porting the CKEditor for Vaadin component, in which a fix was supplied by Tien, to Vaadin 7, we essentially removed the modal window fix and noted that the issue arises again. So it appears that this modal issue remains in Vaadin 7.0.5.

With Vaadin 6, this code fixed the modal bug issue:


public class ModalFixVWindow extends VWindow {

	private boolean modal;
	
    @Override
    public void updateFromUIDL(final UIDL uidl, final ApplicationConnection client)
    {
        if (uidl.hasAttribute("modal")) //$NON-NLS-1$
            modal = uidl.getBooleanAttribute("modal"); //$NON-NLS-1$
        super.updateFromUIDL(uidl, client);
    }

    @Override
    public boolean onEventPreview(final Event event)
    {
        if (modal)
            return true; // why would they block click to other elements?
        return super.onEventPreview(event);
    }
}

Then in the gwt.xml file added:


    <replace-with class="org.vaadin.openesignforms.ckeditor.widgetset.client.ui.ModalFixVWindow">
        <when-type-is class="com.vaadin.terminal.gwt.client.ui.VWindow"/>
    </replace-with>

But we are not sure how to make this work with Vaadin 7 because VWindow has moved packaqe names and no longer has the updateFromUIDL (presumably moved to a Connector?). We tried just this hoping that the VWindow.isModal() would suffice, but it does not seem to work:


public class ModalFixVWindow extends VWindow {

    @Override
    public boolean onEventPreview(final Event event)
    {
        if (isModal())
            return true; // why would they block click to other elements?
        return super.onEventPreview(event);
    }
}

and using this update gwt.xml:


    <replace-with class="org.vaadin.openesignforms.ckeditor.widgetset.client.ui.ModalFixVWindow">
        <when-type-is class="com.vaadin.client.ui.VWindow"/>
    </replace-with>