12.0p: Problem with moving modal windows out of the browser visible area

[Blama]

Hi Isomorphic,

please see this unmodified modal window sample (v12.0p_2019-01-25).
As you can see in the video, it is easy to move the Window and it's header out of view, so that you can't move it into view again.
IMHO it should not be possible to move the window header out of view.

• Moving the Window down, the header should stay in the browser area at all times
• Moving the Window up, the complete window should stay in the browser area at all times
• Moving the Window left/right, some pixels (10?) should stay visible, so that one can move the Window into view again

Right now you can move the window out of view and if it does not set dismissOnEscape:true, you can "lock" the whole application until a F5 Browser window reload (possible in the sample as well).
Of course tabbing does still work, but you can expect from non-developer users to find out about this.



Best regards
Blama

[Blama]

Hi Isomorphic,

actually, here something even more unexpected is possible. Hitting the "Tab"-key does move the whole application out of view, as the focus is moved to an element outside normal viewport.




Best regards
Blama

[Blama]

Hi Isomorphic,

thinking about it, in combination with #2, the rule for moving windows should be "the user can't move windows out of the view at all". Otherwise tabbing the invisible window into view will always work.
If the window is so big, that users might want to move it, the developer has to ensure that the window is either minimizable or realizable.

Best regards
Blama

[Isomorphic]

Hi Blama
You can use keepInParentRect in your app code to achieve this.
On reflection we've decided this is a sensible default so we'll be making that change shortly in the 12.1 branch. For older branches you can set the property yourself.

One note: If you're dragging a top level window, and the page content overflows the browser window in either direction, keepInParentRect does not currently prevent the user from dragging the window out of the viewport in that direction. You can see this in the showcase sample you linked to above - setting 'keepInParentRect:true' on the window doesn't currently prevent the user from dragging it off the bottom of the screen [even though scrollbars have been suppressed, some content overflows the browser window vertically on that page].
Anyway this appears to be a bug and we have a developer taking a look. It will likely be changed at the same time as changing the default keepInParentRect flag - either today or early next week

Regards
Isomorphic Software

[Blama]

Hi Isomorphic,

thanks. keepInParentRect does really help and is already fine for me.

I do see the issue you mention in the showcase with the bottom border.
If you are fixing this, perhaps you can also look here (minor for me): It is not possible to move the window to the very right border, were I assume you keep place for a scrollbar - even if I set

        mainLayout.setOverflow(Overflow.HIDDEN);
        mainLayout.setLeaveScrollbarGap(false);

like in the sample below.

BuiltInDS.java (v12.0p_2019-01-17):

package com.smartgwt.sample.client;

import com.google.gwt.core.client.EntryPoint;
import com.smartgwt.client.Version;
import com.smartgwt.client.core.KeyIdentifier;
import com.smartgwt.client.types.Overflow;
import com.smartgwt.client.util.Page;
import com.smartgwt.client.util.PageKeyHandler;
import com.smartgwt.client.util.SC;
import com.smartgwt.client.widgets.IButton;
import com.smartgwt.client.widgets.Window;
import com.smartgwt.client.widgets.events.ClickEvent;
import com.smartgwt.client.widgets.events.ClickHandler;
import com.smartgwt.client.widgets.layout.VLayout;

public class BuiltInDS implements EntryPoint {
    private VLayout mainLayout;
    private IButton recreateBtn;

    public void onModuleLoad() {
        KeyIdentifier debugKey = new KeyIdentifier();
        debugKey.setCtrlKey(true);
        debugKey.setKeyName("D");

        Page.registerKey(debugKey, new PageKeyHandler() {
            public void execute(String keyName) {
                SC.showConsole();
            }
        });

        mainLayout = new VLayout(20);
        mainLayout.setWidth100();
        mainLayout.setHeight100();
        mainLayout.setOverflow(Overflow.HIDDEN);
        mainLayout.setLeaveScrollbarGap(false);

        recreateBtn = new IButton("Recreate");
        recreateBtn.addClickHandler(new ClickHandler() {
            @Override
            public void onClick(ClickEvent event) {
                recreate();
            }
        });
        mainLayout.addMember(recreateBtn);
        recreate();
        mainLayout.draw();
    }

    private void recreate() {
        Window w = new Window();
        w.setWidth("95%");
        w.setHeight("95%");
        w.setKeepInParentRect(true);
        w.setMembersMargin(0);
        w.setModalMaskOpacity(70);
        w.setTitle(" (" + Version.getVersion() + "/" + Version.getSCVersionNumber() + ")");
        w.setTitle("Problem on right border" + w.getTitle());
        w.setShowMinimizeButton(false);
        w.setIsModal(true);
        w.setShowModalMask(true);
        w.centerInPage();
        w.show();
    }
}

Best regards
Blama

[Isomorphic]

A change was made around Jan 26 which should address this very issue. Can you try an updated nightly build?

[Blama]

Hi Isomorphic,

you are right, this is fixed using v12.0p_2019-02-12.

Then only your own showcase lower-border issue is left here in 12.0p

In the 12.1d sample (SNAPSHOT_v12.1d_2019-02-12) I can already see that you changed the default of the Window-class and that the showcase lower-border issue does not happen there.

Best regards
Blama

[Isomorphic]

The "lower-border" issue you're referring to is the issue where if keepInParentRect is true, you can drag the window off the bottom edge of the showcase, correct?
If so, this should already be resolved in 12.0.
If you go here:
https://www-demos.smartclient.com/sm...e/?id=modality
And modify the source to add 'keepInParentRect:true' to the window definition it appears to stay on the page as it should for us.

Are you seeing something different?

Thanks
Isomorphic Software

EDIT: Never mind! We do see that even with keepInParentRect and a recent build, the window can be dragged a little further down than should be possible (so its bottom edge is offscreen). We're taking another look

Second Edit: We do see what's causing this. We'll make a change to the showcase to avoid this effect but it should be safe to ignore outside this usage

[Blama]

Hi Isomorphic,

calling the sample you linked #8 in current v12.0p_2020-03-24 without any modifications, this is still possible:

• Click "Show Window"
• Move Window (partly or full) out of bottom or right border (top not possible, left not showing the issue)
• Hit tab
• Window is completely visible, moving normal showcase partly out of view

IMHO this should not happen. Either keepInParentRect: true should be the default (and perhaps not settable also) or the framework should not move the normal showcase partly out of view.

Actually I do see that this seems to be already this way in the unmodified sample in 12.1d (SNAPSHOT_v12.1d_2020-03-24), the default is changed (12.0p, 12.1d).
Also if I set keepInParentRect: false in 12.1d, I can't "tab the main application away".

Best regards
Blama

[Isomorphic]

We turned keepInParentRect on for the sample. It will not be made the framework default as it is sometimes desirable to move windows partially off screen and you can avoid the possibility of scrolling the entire screen through either focus management or viewport control, it's up to the application developer to choose what they want.

[Blama]

Hi Isomorphic,

no, it's true by default in 12.1d. It's not set in any sample (12.0p / 12.1d).
Also, the tab issue on outside Windows is solved in 12.1d, but not 12.0p.

Best regards
Blama

[Isomorphic]

Sorry, to clarify, it's true for Window by default, but not for Canvas. The latter would create a low of backcompat problems.

[Blama]

Hi Isomorphic,

yes.
To summarize: IMHO it's way better in 12.1d than in 12.0p (changed default, issue caused by "Tab" fixed).
Backporting this is not important for me, as we set setKeepInParentRect(true) in our Window.setDefaultProperties(), so this is more of a FYI here again.

Best regards
Blama