Re: DialogBox behavior

[Joel Webber]

Amit,

With regards to modality, it is true that most elements appear to click (buttons, anchors, etc), but they shouldn't actually perform their default actions or send any events. Unfortunately, IE doesn't give us the opportunity to stop the visual rendering of actions in some cases. If anyone knows of a way to do this, I'm all ears!

On the second point, that sounds reasonable, but we need to test every edge case before being certain that it's ok to auto-hide on mouse down. I think there were some issues with doing that under certain conditions. Could you possibly try this out in a few different scenarios?

- Clicking outside of an auto-hide popup should still cause the thing clicked on (e.g. Button) to activate.
- Clicking on something outside of an auto-hide popup that causes *another* auto-hide popup to be displayed should still work properly.
- A draggable auto-hide popup (i.e. like a DialogBox, but with auto-hide enabled) should still work.

The first two scenarios can be tested easily using the Mail sample's contact list. The third might be a little trickier, but you could simply copy the DialogBox code and change it to enable auto-hiding in its constructor. Either way it would be great if you could create an issue for this so we can track it there.

Thanks!
joel.

On 1/7/07, Amit Kasher <amitk...@gmail.com> wrote:

Hi,
The behavior of DialogBox seems to be different between IE (7) and
firefox.

1.
In IE7, DialogBox is simply not modal... I've tried the KitchenSink
example in IE7 and it seems to not work as well (it's not modal -
clicking is allowed on most elements).

2.
In addition, the auto-hide feature doesn't work well in IE7. It seems
that when clicking and dragging inside any textbox (which is outside
the dialog), the dialog doesn't close and becomes non-modal.

Changing line 126 in PopupPanel.java (GWT 1.2.22) from its original
content:

            if (autoHide && (type == Event.ONCLICK)) {

to:

            if (autoHide && (type == Event.ONCLICK || type ==
Event.ONMOUSEDOWN)) {

seems to solve it.

[Mat Gessel]

On 1/8/07, Joel Webber <j...@google.com> wrote:
> With regards to modality, it is true that most elements appear to click
> (buttons, anchors, etc), but they shouldn't actually perform their default
> actions or send any events. Unfortunately, IE doesn't give us the
> opportunity to stop the visual rendering of actions in some cases. If anyone
> knows of a way to do this, I'm all ears!

If you throw up a blank, full document div behind the dialog you can prevent
* elements that respond, but do not act
* transferring focus background elements in Opera
(mousedown->preventDefault() does the trick for other browsers)
And you get the added bonus of a css-stylable lightbox effect. (Hmm,
maybe you could eliminate EventPreview while you're at it....)

Of course, this behavior will be undesirable for those who want a
non-modal dialog.

--
Mat Gessel
http://www.asquare.net/gwttk/