Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 335050

Summary:

Shared area becomes destroyed after splitting vertically and then splitting the bottom part horizontally

Product:

[Eclipse Project] e4

Reporter:

Remy Suen <remy.suen>

Component:

Assignee:

Project Inbox <e4.ui-inbox>

Status:

VERIFIED FIXED

QA Contact:

Eric Moffatt <emoffatt>

Severity:

critical

Priority:

Version:

1.0

Target Milestone:

4.1 RC2

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
PartRenderingEngineTests tests patch v1	none
Specifically handle unwrapping one sash container containing another	none
Patch to clean up stack splitting	none
Change the code to allow a stack to 'outerDock' using itself	none

Description Remy Suen

2011-01-21 15:09:59 EST

I20110121-1315

1. Open a file.
2. Window > New Editor
3. Split the shared area vertically.
4. Now split the bottom stack horizontally with the editor on the tab.
5. The shared area is now destroyed.

You cannot open new editors. Resetting the perspective does not help (as expected). The editors are still technically there because if they are dirty, you do get prompted when you try to shutdown Eclipse.

Restarting will resolve the problem although the previously opened editors will be a bunch of error parts.

Comment 1 Remy Suen

2011-01-21 15:19:51 EST

Note that this is similar to bug 325146 but not entirely because the area will come back in that scenario whereas it won't in this case.

Comment 2 Remy Suen

2011-01-21 15:24:21 EST

I reproduced it on I20101216-1305 so I guess it's not a new bug.

Comment 3 Remy Suen

2011-01-21 15:50:49 EST

There doesn't seem to be anything fishy about the model itself. The 'toBeRendered' attribute of all the relevant elements appear to be 'true'. 'visible' is also 'true'.

Comment 4 Remy Suen

2011-01-24 09:03:44 EST

It seems the area's child (MPartSashContainer) has no widget.

Comment 5 Remy Suen

2011-01-24 09:34:20 EST

(In reply to comment #4)
> It seems the area's child (MPartSashContainer) has no widget.

This doesn't actually seem to be directly related...

I tried rolling back the changes for bug 333489 but it didn't help.

Comment 6 Remy Suen

2011-01-24 11:07:23 EST

Created attachment 187437 [details]
PartRenderingEngineTests tests patch v1

Not entirely clear if this is the problem but there is an issue where altering the hierarchy of nested MPartSashContainers can cause widgets to be inadvertently disposed. This is akin to the code that the CleanupAddon performs.

Comment 7 Eric Moffatt

2011-01-27 16:14:27 EST

Created attachment 187780 [details]
Specifically handle unwrapping one sash container containing another


This is an interim fix...

The base cause is the 'optimized' sash layout mechanics which cause all children (at whatever level) to have the 'top' sash container's composite as their parent.

Here the scenario resulted in the 'top' sash container being unwrapped by the cleanup addon and it's dispose caused everything else to go away.

Comment 8 Eric Moffatt

2011-01-27 16:15:30 EST

Note that the above patch works but a solution in the rendering setup would be better I think...

Comment 9 Eric Moffatt

2011-01-27 16:23:11 EST

Committed in >20110126. Applied the patch.

This is better but it's specific to the Cleanup Addon and does not address the failing test case. That fix has to go into the SashRenderer since it's its 'optimization' that is causing the issues.

Once we have the test scenario working we should re-visit the change in the cleanup addon.

Comment 10 Eric Moffatt

2011-05-13 14:03:23 EDT

This was broken (again) in I20110511-2200. It was a regression introduced by the SplitDropHandler not removing the element if it was dragging a stack (causing problems when moving a stack to split either itself or another stack in the same PSC as the dragged stack was...

Comment 11 Eric Moffatt

2011-05-13 14:05:07 EDT

Created attachment 195614 [details]
Patch to clean up stack splitting

Comment 12 Eric Moffatt

2011-05-13 14:05:49 EDT

Committed in >20110513. Applied the patch.

Comment 13 Eric Moffatt

2011-05-13 14:22:19 EDT

Created attachment 195619 [details]
Change the code to allow a stack to 'outerDock' using itself


This is the scenario where the user has moved the Outline view into the shared area. We still need to allow the code to recognize that it wants to move it back out of the area (even though the cursor is over the itself).

Comment 14 Eric Moffatt

2011-05-13 14:23:06 EDT

Committed in >20110513. Applied the patch.

Comment 15 Eric Moffatt

2011-05-17 11:27:09 EDT

This appears to have been fixed by the last round of DnD changes...

Comment 16 Eric Moffatt

2011-06-06 10:48:13 EDT

Verified in I20110604-2201