Originally by twolf2919

Attachment added: Vaadinwindowproblem2UI.java (1.8 KiB)
Program which shows the problem

Originally by proaccountapp

Updated prioritization date.

Originally by @jouni

I suspect this is because the top window's shadow element is covering the bottom windows header partially. So it's not related to maximize or restore, just the fact that the a window's shadow can overlap other elements and mouse events are not propagated through the shadow.

You did not specify what theme you are using. All current built-in themes have image-based shadows, so they all exhibit this behavior. The upcoming Valo theme won't have this issue, since it uses CSS box-shadow (except in IE8).

Possible workarounds:

• Use the pointer-events property. Works in all supported browsers except IE8, IE9, IE10 and Opera 12:

.v-shadow-window {
  pointer-events: none;
}

• Define a custom shadow using box-shadow. Works in all supported browsers except IE8:

.v-shadow-window {
  display: none;
}

.v-window {
  box-shadow: <shadow definition>;
}

Originally by twolf2919

Replying to Koivuviita:

I suspect this is because the top window's shadow element is covering the bottom windows header partially. So it's not related to maximize or restore, just the fact that the a window's shadow can overlap other elements and mouse events are not propagated through the shadow.

You did not specify what theme you are using. All current built-in themes have image-based shadows, so they all exhibit this behavior. The upcoming Valo theme won't have this issue, since it uses CSS box-shadow (except in IE8).

Hi Jouni,
If it were the top window's shadow element covering the bottom window's header partially, wouldn't the problem exist BOTH before and after the maximize - not just after the maximize? If you want, I can attach screen shots of the two windows before and after maximize - as you would see, the spacing didn't change at all, yet clicking on the bottom header before the resize worked, but after the resize it doesn't.

Your possible workaround works on the sample app. I will try it in the application and let you know. Thanks. But I'd still like an explanation for why things work before the maximize and not after.

Thanks for all info.

P.s. the test app used whatever theme the Vaadin Eclipse plugin creates an app with - reindeer. Our real app uses the same, with some tweaks I found in the Vaadin forums for making the header title area narrower (I don't know why, by default, you guys made that window title area so bizarrely tall - that's another subject :-)

Originally by @jouni

Replying to twolf2919:

If it were the top window's shadow element covering the bottom window's header partially, wouldn't the problem exist BOTH before and after the maximize - not just after the maximize? If you want, I can attach screen shots of the two windows before and after maximize - as you would see, the spacing didn't change at all, yet clicking on the bottom header before the resize worked, but after the resize it doesn't.

Probably works because the bottom window is the top-most (z-index wise) initially, but when you maximize/restore (basically just focus/click) the top window it becomes the top-most, and the top windows shadow is also raised above the bottom window.

The z-index ordering works so that the lastly opened window is always top-most, unless you call Window.bringToFront() or Window.focus() from the server (or unless the user clicks some other window to make it the top-most).

Originally by @jouni

Related: #3140 and #9303

Originally by @jouni

One possible fix is to catch events on the shadow element and then retrigger the same event for the underlying element (using elementFromPoint). I don't know in how many browsers that's supported, but it's worth investigating.

Are there any other events other than click that should be considered, or is that the most crucial one?

Another solutions is to re-implement the shadows using CSS box-shadow for all core themes. That would leave IE8 without a shadow, and would alter the visual end result of pretty much all Vaadin applications, which is not really nice (considering that many have screenshot based TestBench tests also)..

Originally by @Artur-

The approach of capturing events, trying to find the underlying event and retrigger the same event sounds like it could cause lots and lots of headache in the future. If you have an input field below the shadow, what events should you trigger? Click, click+focus, something else?

It would make much more sense to convert the old themes to use box-shadow where possible, the same way it has been done in Valo already (i.e. implement #9303).

Originally by Dmitrii Rogozin

Attachment added: old_version_with_divs.png (7.8 KiB)

https://trac-attachments.vaadin.com/trac/13885/old_version_with_divs.png

Originally by Dmitrii Rogozin

Attachment added: new_version_with_box_shadow.png (7.8 KiB)

https://trac-attachments.vaadin.com/trac/13885/new_version_with_box_shadow.png

Originally by Dmitrii Rogozin

Added screenshots of former and newer version of the shadows for comparison.