Community
Participate
Working Groups
3.3 M6 I am not sure if this is a general text editor problem or JDT. I have very specific instructions below since it forms a reproduceable case: 1) Bring org.eclipse.UI project into workspace 2) In the Package explorer, select the file plugin.xml. Open the file, go the source tab (plugin.xml). 3) Search for the string "active". The scroll position will be about 3/4 down the file (in a <colorDefinition>). Close the search dialog. 4. Give the Package Explorer focus by selecting its tab 5. Give the plugin.xml file focus by selecting its tab The scroll position will jump to near the top, in this case selecting "extension" in the first <extension> markup. I've seen this same behaviour of scroll position change on Steve Northover's machine but we couldn't find a reproduceable case. I've tried this same scenario in 3.2.1 and it works correctly, so this appears to be a regression. That combined with its annoyance level I am marking it critical.
When the PDE editor gets activated PDESourcePage.updateTextSelection() is called which reveals the element that's currently selected in the outline. BAD. Simple steps: 1. open a plugin.xml file and hit 'plugin.xml' tab 2. select a node in the Outline 3. go back to the editor and move the caret (e.g. to start or end) 4. give the focus to another view (e.g. Package Explorer) 5. go back to PDE editor ==> scrolls to element selected in step 2.
Steve, is that the bug you mentioned in the last call?
Mike, please take a look.
Yes!! I suspect this is the one. This bug has been killing me for a while and I could not get a reproducable case. Thanks Kevin. Dani, this is a must fix for me. Please let me know when there is something I can try. Since it didn't happen to me every time, I'll need to work with it for a few days to be confident it is gone.
>Dani, this is a must fix for me. Well the bug is out of my land but I'll track it. Just a side note: the steps I provided in comment 1 make it 100% reproducible BUT: I also noticed what Steve and Kevin reported i.e. that it *sometimes* also happens when the editor just gets opened - but not always. So - besides the bad explicit revealing there's probably another bug that sometimes (randomly?) selects an element in the Outline and then causes this, or there is some hidden state (cached last selected node?) in the PDE editor that restores an element and then reveals the bug.
This bug seems specific to the plug-in manifest editor. If a scrolling bug was encountered using a different editor (e.g. plain text editor), then I suggest opening another bug. The SWT team does not strike me as plug-in manifest editor enthusiasts, so there may be another bug at play here.
The problem outlined in Comment # 1 can be attributed to the synchronization mechanism used to keep the plug-in manifest editor form pages in sync with the source pages on multi-page editor switch. For instance, selection of a given extension on the "Extensions" page selects the corresponding XML mark-up on the "plugin.xml" source page and vice versa. There are a number of situations where this feature overrides the normal Eclipse conventions on setting and preserving selection. In this case, it clearly should not. Initial investigation seems to suggest fixing this problem would involve invoking form / source page sync mechanism only on multi-page editor switches rather than on focus events.
*** Bug 180680 has been marked as a duplicate of this bug. ***
Sigh.
(In reply to comment #7) > Initial investigation seems to suggest fixing this problem would involve > invoking form / source page sync mechanism only on multi-page editor switches > rather than on focus events. This is new behaviour, right? I don't see it in 3.2. I personally am not keen on something that changes my edit location *somewhere I cannot see* based on selection elsewhere. However, changing it to happen only on page change would remove the immediate issue at least. Its one thing to have an outline trigger edit location because its clear there's a relationship between one and the other. Secondly, having edit location trigger back resource selection makes sense, but even in this case most people only turn it on briefly because otherwise it becomes annoying. I gather your thinking was that, "The form based views and the source views are really views onto the same thing, so selection in one place should track selection elsewhere". Its an interesting idea. However, that only works if: 1) Transparency: I can see the relationship (ie. I can see both views at once and see effect of selection in one). This is not true in this case, so the user has no cues to understand why his selection is changing; he can only assume its a bug. 2) Immediacy: (related to 1) I have to see that an action in one place causes the change in the other so that I can update my spacial memory, and I can see the effect. 3) Mental model: It needs to be that ny tasks treat the different views as one comprehensive one, where I frequently switch back and forth. I personally don't work this way; I either work in the form based views because they provide good assistance, or I work in the text based one because I am searching or otherwise making big edits. I don't think I ever switch back and forth, find an element say in the form, then edit in the source, or vice versa. I'd strongly suggest you remove this feature because I can pretty well guarantee that most will report it as a bug, even with the change, or at a minimum be left scratching their heads. Few will "get it". Instead, "Show me in the source" menu in the form end would be quite nice.
RE: Comment # 10. The feature was implemented in the 3.3 M1/M2 timeframe and was a result of the following feature requests: * Bug # 61522 * Bug # 79208 * Bug # 84081 You raise some valid points regarding transparency and immediacy. However, other tools such as Macromedia DreamWeaver have already set the precedent for this behaviour. Regarding the mental model, this feature is geared more towards the power plug-in manifest editor user. One common use case for using this feature is the following: (1) Adding an extension and its elements using the form page; (2) Switching to the source page; (3) Copying, pasting and modifying similar elements under the same extension (easier and more visbibly done in the source view). More commonly, this feature is used as a quick and dirty search mechanism for the source pages containing a lot of XML mark-up - although your "Show me in the source" menu suggestion is a good idea we can add for more visibility.
Although I was one of the original requestors for selection linking between pages, I would also be happy with explicit 'Show in source page' and 'Show in model page' actions. These would even make it easier for the user to switch, since she would not have find the right page for the other editing mode. But I think the linking feature is important, so I'd vote for keeping (and fixing) the current behavior unless you add explicit navigation actions.
+1 for the explicit actions. This would be: 1. all I need 2. obvious to users 3. IMHO easier to implement Mutually synchronize the selection/content from two views is usually not a good idea.
Does all this discussion mean that this bug is not tracking the phantom scrolling that I am seeing?
completely unrelated.
>Does all this discussion mean that this bug is not tracking the phantom >scrolling that I am seeing? In which editor do you see it? If it's in the PDE editor then it *is* related.
JDT text editor.
ok, then this is indeed completely unrelated.
Removing the forms-source synch function because of a focus bug would be a classic "Let's throw out the baby with the bath water" It is an enhancement request that has several dups and it is consistent with other Source/GUI editors like DreamWeaver\MSFrontPage. So we are not setting a precedent here. The Show In > idea, while it is a fine idea (in a safe kind of way), would be setting a precedent and would make the function hidden (but on-demand, which is the appeal here). Only Markus would know about it. Plus, the editor's context menus are already pretty busy. Also, "Show In" cannot be contained in 3.3, even if we were to go ahead with it. Let's get this focus bug fixed for 3.3 and if there are still issues after it is fixed, we can look at separately post-3.3.
OK. There's still Markus' comment #12 though, whereby an explicit "Show In" would, from the source xml side, automatically move you to the correct PDE page. Isn't that better than how it works now?
absolutely. I prefer it actually, and makes Mike's life easier :)
Fixed. Patch released to HEAD. Target: 3.3 M7 Patch: patch_180396_2007-04-16_10-49.txt Source page text selections are now updated on page activation rather than focus events.
*** Bug 182854 has been marked as a duplicate of this bug. ***
*** Bug 185914 has been marked as a duplicate of this bug. ***
