I can remove the open action from XMLDataObject actions. It'd mean
that tree editor should add it exlicitly (it has under its control
presentation node than can overwrite actions being presented).

Interesting architectural question. I do not know how should I solve
it for the Edit action. Text editor module does not have an access to
presentation nodes.

Another interesting issue is default action. There is a setting for
its value.

If time permits I'll try to solve it till NB35.

Looking at o.n.m.xml.tree.TreeEditModuleInstall, it seems that the
tree edit module has the code to explicitly add the Open action.  It
also looks like this code is never called.

Is there any particular reason we shouldn't remove OpenAction from the
XML and DTD data loaders, and add

public void restored() {
  installActions();
}

to TreeEditModuleInstall?

What an ugly code :-). Except it there is perfomance penalty because
it loads many XML module classes right during startup.

Anyway it's instant solution. Thank you for pointing it out!

Correct solution would be a kind of that XMLCore examines lookup for
active OpenCookie providers. If at least none is active it could
present the OpenAction (extends CookieAction).

Uglyness reason: actions are presentation layer and should be fully
configureable by user. Direct access to loader actions ignores all
user customizations. It in fact "corrupts" these on each tree module
enable/disable operation.

Local action pools seem to address it:
http://openide.netbeans.org/proposals/actions/design.html#pools

=> depends on issue 17597.

*** Issue 34805 has been marked as a duplicate of this issue. ***

CCs from issue 34805 added.

Open action was  removed from xml node.
DTD node still contains disabled Open action.

Fixed for 4.0

Verified in #200603280200.