Community
Participate
Working Groups
Build Identifier: I20101028-1441 When editing the extensions, I often end up with a corrupted plugin.xml, e.g. with the following last few lines: ... </menuContribution> icon="icons/export_wiz.gif" style="push"> </command> </menuContribution> </eicons/export_wiz.gifxtension> </plugin> Reproducible: Sometimes Steps to Reproduce: Not sure yet how to reproduce this issue; might be happening after copy pasting extension elements in the form editor, or perhaps after first doing some manual editing and then some more editing in the form editor.
This has been seen before when using cut/paste and undo/redo. I don't believe we were ever able to track down a cause. I couldn't find a direct dupe, though bug 324986 and 282716 may be related.
I get this all the time as well -- thought it was just me. I'm on Cocoa. It seems so random that I've also avoided reporting it, but it happens often enough that I've given up on using the PDE editor for anything but adding new elements. But it doesn't seem to be repeatable -- sometimes an edit work, other times the same kind of edit doesn't. I think I've noticed it happening more often with longer / more complex plugin.xml. Sometimes text is removed, other times text lines are duplicated, and this often but not always seem to happen along element boundaries. The really worrying/annoying thing is that sometimes the corruption can happen invisibly and it isn't discovered until later on when something in the UI doesn't work correctly. I'd vote for high priority - certainly for Indigo, as though this has been around for a while, my guess is that it is one of those things that a lot of people have experienced but learned to live with.
same happens from time to time while editing ComponentDefinitions. so before saving I always take a look at the source tab to see if something was scrambled. happens never while creating a new one but sometime editing properties or editing classnames etc ekke (In reply to comment #2) > I get this all the time as well -- thought it was just me. I'm on Cocoa. It > seems so random that I've also avoided reporting it, but it happens often > enough that I've given up on using the PDE editor for anything but adding new > elements. But it doesn't seem to be repeatable -- sometimes an edit work, other > times the same kind of edit doesn't. I think I've noticed it happening more > often with longer / more complex plugin.xml. Sometimes text is removed, other > times text lines are duplicated, and this often but not always seem to happen > along element boundaries. The really worrying/annoying thing is that sometimes > the corruption can happen invisibly and it isn't discovered until later on when > something in the UI doesn't work correctly. > > I'd vote for high priority - certainly for Indigo, as though this has been > around for a while, my guess is that it is one of those things that a lot of > people have experienced but learned to live with.
Bumping to major. This has been an issue in PDE for ages, but in the last release or two, people are encountering it more. We made one fix in 3.6 that helped a lot of people (Bug 293474), but obviously we haven't fixed everything. Unfortunately, no one has found a cause for this issue.
I just did this by taking some extension items and moving them up or down rapidly. Naturally, I did it again and everything worked perfectly. :( I would suspect some kind of threading issue -- my very speculative observation is that it seems to happen when one gets "ahead" of the UI thread.
*** Bug 338950 has been marked as a duplicate of this bug. ***
*** Bug 77284 has been marked as a duplicate of this bug. ***
*** Bug 232692 has been marked as a duplicate of this bug. ***
*** Bug 342855 has been marked as a duplicate of this bug. ***
There is an SWTBot test available on Bug 342855 to reproduce.
Possibly related to this issue: Bug 342868 ?
Created attachment 194231 [details] Video that shows how to reproduce the bug org.eclipse.pde.internal.ui.editor.context.XMLInputContext creates text edit operations when nodes are edited, inserted, removed, moved, .... in the Extensions tab. For this it uses offset/length of the XML document nodes, for example in #insertAfterSibling, line 140. It piles up these edit operations until the document is saved or the plugin.xml is opened. But the offset/length of the nodes used to create the edit operations is ONLY updated when the document is reconciled (on save/plugin.xml open). So when multiple edit operations pile up without saving, esp. when editing content out of order, things start to break. It can be reproduced easily once you know that this is happening. See the attached video for an example. I cannot believe that this was happening all the years. From looking at the code, esp. PluginInputContext#reorderInsertEdits, the authors of that code seemed to be very confident that the order of multiple edit operations does not matter. Why? Also, does it make sense to reinvent syncing text and XML model in PDE?
I'll see whether we can find a safe fix that's appropriate for RC1.
Steps to reproduce in I20110505-0800: 1. create a plug-in project 2. add the following plugin.xml: ---%<--- <?xml version="1.0" encoding="UTF-8"?> <?eclipse version="3.4"?> <plugin> <extension point="org.eclipse.ui.contexts"> <context id="Bug.context2" name="A"> </context> <context id="Bug.context1" name="B"> </context> </extension> </plugin> ---%<--- 3. save 4. go to the 'Extensions' page 5. expand the extension node 6. click on node A 7. append '1' in the name field 8. click on node B 9. append '2' in the name field 10. click on node A1 11. append '3' in the name field 12. switch to 'plugin.xml' tab ==> name is corrupted: name="A13> Initial debugging shows that the model generates wrong ReplaceEdit/s.
Test Case 2: 1. create a plug-in project 2. add the following plugin.xml: ---%<--- <?xml version="1.0" encoding="UTF-8"?> <?eclipse version="3.4"?> <plugin> <extension point="org.eclipse.ui.contexts"> <context id="Bug.context2" name="A"> </context> <context id="Bug.context1" name="B"> </context> </extension> </plugin> ---%<--- 3. save 4. go to the 'Extensions' page 5. expand the extension node 6. click on node A 7. delete the value (make name field empty) 8. click on node B 9. click on first node 11. enter '1' in the name field 12. switch to 'plugin.xml' tab ==> name is wrong: name="1A">
Test Case 3: 1. create a plug-in project 2. add the following plugin.xml: ---%<--- <?xml version="1.0" encoding="UTF-8"?> <?eclipse version="3.4"?> <plugin> <extension point="org.eclipse.ui.contexts"> <context id="Bug.context2" name="A"> </context> <context id="Bug.context1" name="B"> </context> </extension> </plugin> ---%<--- 3. save 4. go to the 'Extensions' page 5. expand the extension node 6. click on node A 7. append 'foo' in the name field 8. click on node B 9. click on node Afoo 10. Undo (Ctrl+Z) 12. switch to 'plugin.xml' tab ==> name is corrupted
*** Bug 324986 has been marked as a duplicate of this bug. ***
*** Bug 340379 has been marked as a duplicate of this bug. ***
Created attachment 194917 [details] Fix This patch correctly merges the text edits.
+1 Patch works great for me. Undo/redo, stacking multiple edits, and the provided test cases all are working. Dani, I owe you a frosty beverage for fixing this in 3.7 (and I'm probably not the only one). Miles, Eric, et al can you please give this patch a try to verify as soon as possible?
Dani, please also update the copyright on the file before committing.
Yep, I cannot 'scramble' the xml manually anymore after applying the patch. Thanks, this is great! Unfortunately, it does not fix the scrambling shown by my SWTBot test in bug 342855 (which just adds new extensions and saves at random in a loop). I experimented a bit more and this 2nd issue seems to be related to editing right after saving, I can make the test work by adding a sleep(2000) after saving. I cannot reproduce that manually though, but the SWTBot case breaks all the time after doing 10-20 operations. Now, when I save the document, I see the extension tree updated immediately, but the whole content seems to be updated asynchronously after some time again (one can tell because the cursor/selection changes in an active attribute field). Could this be related? Also, looking at the patch I learned that I was wrong about the cause for the issue, so answering my own question, 'Why?' does the order of the operations/using not-up-to-date document offset/length does not matter: all edit operations are merged together in InputContext#flushModel into one edit operation.
Committed fix to HEAD with updated copyright date. > Unfortunately, it does not fix the scrambling shown by my SWTBot test in bug > 342855 Reopened bug 342855 as the fix here does not solve this issue.
(In reply to comment #20) ... >Dani, I owe you a frosty beverage for fixing this > in 3.7 (and I'm probably not the only one). > +1 beer from me > Miles, Eric, et al can you please give this patch a try to verify as soon as > possible? works great :)
(In reply to comment #24) > (In reply to comment #20) > ... > >Dani, I owe you a frosty beverage for fixing this > > in 3.7 (and I'm probably not the only one). > > > +1 beer from me > > > Miles, Eric, et al can you please give this patch a try to verify as soon as > > possible? > > works great :) I'll give it a shot in next few days.
Verified in I20110514-0800 Please keep your eyes out for any other odd behaviour in the editors.
I have encountered another issue that corrupts the plugin.xml. It appears that the escaping of certain special characters does not work properly. I don't have a test case, but you can try it out by creating an extension point that has a string field. Try creating and extension and entering some text in the field that contains special characters such as ", ', ;, etc. The initial conversion seems to work ok, but if you subsequently edit the string (remove a special character, add new ones, etc.) the field is eventually corrupted. Just play around a bit and you should see it.
It seems particularly vulnerable when adding/inserting a semicolon in the string if it already contains escaped characters. So if a string contains 'foo' (including the single quotes), then adding a semicolon to the end seems to corrupt it.
Greg, can you please open a new bug with the issue you see? We can't use this bug to handle ever newly detected case.
Opened bug 346665
Created attachment 267145 [details] Scrambled plugin.xml 2017.03.07 I have this issue as well now. I was also copy pasting extension elements and used undo-redo. The resulting plugin.xml became scrambled and the editor wasn't able to parse it anymore, resulting in DOM exception. Eclipse version 4.6.2 neon.2 Build ID: M20161124-1400
Should we reopen the issue here according to Bence comment, or create a new one?
(In reply to Mickael Istria from comment #32) > Should we reopen the issue here according to Bence comment, or create a new > one? As usual: open a new bug report with steps to reproduce.
(In reply to Dani Megert from comment #33) > (In reply to Mickael Istria from comment #32) > > Should we reopen the issue here according to Bence comment, or create a new > > one? > > As usual: open a new bug report with steps to reproduce. Ok. @Bence: can you please do that?
