Open GoogleCodeExporter opened 8 years ago
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
Original comment by pall...@google.com
on 2 Jun 2010 at 1:35
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
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:
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:
Original issue reported on code.google.com by
canud...@gmail.com
on 2 Jun 2010 at 1:23