splitPane's iFrameOverlay should be optional

[GoogleCodeExporter]

It would be convenient to make the iframeOverlay use optional.
In my case, as I don't use iframes, I have no need for it, but it
causes me problems.
I'm trying to put a SplitPane inside a Dialog, which works ok, but, as
the zIndex of the splitter handle is set to 2 to be over the
iframeOverlay, it also shows over other dialogs that I have, which is
very inconvenient.

What steps will reproduce the problem?
1. Put a splitPane inside a dialog
2. Put a splitPane inside another dialog
3. Show both dialogs

What is the expected output? What do you see instead?
When one dialog overlaps the other one, the splitPane handle bar flows over 
both of them.

Original issue reported on code.google.com by canud...@gmail.com on 2 Jun 2010 at 1:23

[GoogleCodeExporter]

That souldn't be a Defect, bun an Enhancement. How can it be changed?

Original comment by canud...@gmail.com on 2 Jun 2010 at 1:24

[GoogleCodeExporter]

Original comment by pall...@google.com on 2 Jun 2010 at 1:35

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Looking better at the sources, I think it could be considered a Defect, and I'm 
thinking of a solution.
The iframeOverlay is created on the first DragStart, which means it is needed 
only 
while dragging the handle, therefore, we can assume that it is the topmost 
dialog. If 
the iframeOverlay is removed on DragEnd, and the zIndex from the handle 
resetted, 
then the problem would dissapear.
I read that now patches are being accepted for the closure library. Could 
someone 
tell me how and where should I submit a patch whith this solution?

Original comment by canud...@gmail.com on 2 Jun 2010 at 1:40

[GoogleCodeExporter]

Even better, as the iframeoverlay is set to zIndex -1 on DragEnd, it would only 
be 
needed to set the handle zIndex to SPLITTER_HANDLE on DragStart, and reset it 
on 
DragEnd. At least in the case described it solves the problem.
I attach here a simple patch. Should it be sent somewhere else?

Original comment by canud...@gmail.com on 2 Jun 2010 at 1:57

Attachments:

• splitpane.js.patch

[GoogleCodeExporter]

Well, of course the patch I sent is incorrect... both because it causes issues 
on Internet Explorer, and because it triggers warnings by the closure 
compiler... it happens when things are submitted without testing.
Here comes a new one.
SplitPane handle is normally at zIndex 0. As iframe is at zIndex -1 when not 
dragging the handle, there's no reason to have it at zIndex 2. When iframe is 
raised, so is the handle, and when the iframe is lowered (to -1), so is the 
handle too (to 0).

Original comment by canud...@gmail.com on 22 Jun 2010 at 8:31

Attachments:

• splitPanePatch.diff