Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 330016 - selectChange method in CompareEditorInputNavigator does not behave properly
Summary: selectChange method in CompareEditorInputNavigator does not behave properly
Status: CLOSED INVALID
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Compare (show other bugs)
Version: 3.5.1   Edit
Hardware: PC Windows Vista
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-Compare-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-11 11:34 EST by Sebastien Dubois CLA
Modified: 2010-11-12 13:30 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastien Dubois CLA 2010-11-11 11:34:31 EST
The selectChange method in CompareEditorInputNavigator does not behave properly when it is called initially with false as input.  What should really happen is that is returns false (since initially the first change selected is always the first one, but should work correctly afterwards.

Right now a DebugException is generated and the selection index goes out of sync.  So later on when slectChange is called with true as input, the next change is not selected properly.

The affec5ed method shows this:

	/* (non-Javadoc)
	 * @see org.eclipse.compare.ICompareNavigator#selectChange(boolean)
	 */
	public boolean selectChange(boolean next) {
		// Fix for http://dev.eclipse.org/bugs/show_bug.cgi?id=20106
		if (next && fNextFirstTime && mustOpen()) {
			fNextFirstTime= false;
			if (openElement())
				return false;
		}
		return super.selectChange(next);
	}

I think the problem happens because the navigator input is not loaded when the input is set to false (the first "if (next...)" ).  I think the element should be opened regardless of the value of the input parameter.
Comment 1 Sebastien Dubois CLA 2010-11-12 13:30:42 EST
THe problem is not with eclipse but with the client that uses the compare editor so I am cancelling this bug