This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 220331 - PLugin effects insufficiently isolated for effective rollback
Summary: PLugin effects insufficiently isolated for effective rollback
Status: NEW
Alias: None
Product: third-party
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 7.2
Hardware: PC Windows 7
: P1 normal (vote)
Assignee: issues@third-party
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-17 22:55 UTC by java_dev
Modified: 2012-10-17 22:55 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description java_dev 2012-10-17 22:55:39 UTC
OK I installed a plugin- the clipboard history plugin from here:

http://plugins.netbeans.org/plugin/31336/history-clipboard

Apparently it was no longer compatible with 7.2.  NB refused to launch after   I installed it and agreed to restart NB. OK Fair enough. 

The problem was it somehow hosed NB so that the issues never went away. Every time I tried to run  NB it (NB) would cite a list of incompatiblities (involving the versions of editor libraries and "38 other problems") and  ask me if I wanted to ignore them or exit. I chose ignore. NB  stalled initing at "loading modules" thereafter. Everytime. So now it's p1 Netbeans is unusable. 

Here's the really bad  part - I  had to nuke my user prefs and all that jazz because uninstalling without choosing to nuke all that didn't result in NB being able to function again. 

So I had to do a FULL uninstall. Of course, I hate full uninstalls of anything because I just said buh-bye  to all my macros, editor  configurations  all that busy set up crap that ends up taking  hours to redo. 

Now it's p(-100) .. NB's is causing me genuine pain and wasting my time. 

I have to think that plugins are somehow allowed to mutate files and the pre-mutation version of those files is NOT saved by NB. The end user cannot return to the pre-plugin install state if anything goes terribly wrong- for instance NB never loads again. 

It's too much to expect the end user to be able to troubleshoot this kind of thing. I know I could have probably saved my prefs somehow some way by copying files and then replacing them again, but how many  files and where are they located and what are their names? I'm not sleuthing all that down and hoping I get it right.... I'll take the sure thing and nuke everything and just start over. That's the course of action most people will choose. 

NB ought to save off whatever state it needs to save off before a plugin is taken up and be able to totally revert to the  pre-plugin state. 

So when NB restarts with new plugins, a dialog would pop up saying "do you want to install these plugins?  If NB has never successfully loaded and run  with those plugins.  Answering "no" would result in a behind-the-scenes reversion of plugin-altered files to their pre-plugin state. That way after the first time a plugin prevents NB from loading  properly, the user can escape. 

If the plugin screws NB up after it loads for the first time or sometime  thereafter, there ought to  be a way to blame the plugin, tell the user the plugin screwed up and is being  disabled,  and then revert to pre-plugin state.

Plugins are a huge vulnerability to the  perceived  goodness of the IDE (or rich client) b/c they're where just *anyone* can do just *anything*. 

In this sense it represents a total break down of QA. You can't stop plugins from hosing things, but you should  have a fail safe fall back procedure that firewalls the damage they can do to NB's reputation .

HTH