BorderContainer: events seep through dijitSplitterCover in IE

[guest]

In IE, events will seep through dijitSplitterCover. Temporary fix:

.dijitSplitterCover{ background: white; filter: alpha(opacity=1) }

This will trick IE into not seeping events through the SplitterCover?.

[bill]

Can you be more specific? Are you talking about mouseOver events, like if you drag the splitter over a button? And is this for BorderContainer??

[guest]

Replying to bill:

Can you be more specific? Are you talking about mouseOver events, like if you drag the splitter over a button? And is this for BorderContainer??

Yes, this bug is for BorderContainer?.

When _startDrag fires for a BorderContainer?, a covering div called dijitSplitterCover is placed over the area of the BorderContainer? so that events (mouseover, etc) from elements below do not interfere with the dragging of the slider.

However, in IE, even though the cover is placed over the elements below, events on those elements fire. This makes splitter dragging very choppy, especially when dragging over an iframe. Sometimes, the slider will get in a strange state where it is stuck on the mouse, and clicking will not release it.

I have attached an example.

[guest]

Oops, forgot to attach. Here is the file.

[bill]

OIC. OK, cool, thanks for the explanation, and the fix!

[guest]

Replying to bill:

OIC. OK, cool, thanks for the explanation, and the fix!

Something to consider: Instead of fixing the bug in CSS using the proprietary "filter: alpha(opacity=0)", you could query dojo.isIE on _startDrag and programmatically apply the filter.

[Adam Peller]

(In [14185]) CSS hack to stop mouse events in IE and boost splitter performance. Fixes #6945.

[bill]

In [30558]:

use opacity:0 rather than filter:... on IE9 and IE10, fixes #16679 and refs #6945 on trunk, !strict

[bill]

In [30559]:

use opacity:0 rather than filter:... on IE9 and IE10, fixes #16679 and refs #6945 on 1.8 branch

[bill]

In [30560]:

use opacity:0 rather than filter:... on IE9 and IE10, fixes #16679 and refs #6945 on 1.7 branch