Issue 113096 - Both Optionpage and Menu of deinstalled extension stays visible
Summary: Both Optionpage and Menu of deinstalled extension stays visible
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOO320m9
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.3
Assignee: h.ilter
QA Contact: issues@framework
Keywords: regression
Depends on:
Blocks: 111112
  Show dependency tree
Reported: 2010-07-12 11:07 UTC by thorsten.martens
Modified: 2017-05-20 10:22 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description thorsten.martens 2010-07-12 11:07:30 UTC
If an extension with an optionpage is deinstalled, the optionpage is still
visible under tools/options until the office is restarted.
Comment 1 cno 2010-07-29 10:57:40 UTC

I change the summary. Was "Optionpage of deinstalled extension stays visible"

Reason is clear:
 - install an extension that has a main menu entry
 - new document
  > menu entry is vissible
 - uninstall the extension
 - close all documents and start new one
 > menu is still there
This is wrong.
Only after restart of the office, the menu is gone.
Comment 2 cno 2010-07-29 10:58:23 UTC
can this pls be considered for 3.3.0 or at least 3.3.1?
Comment 3 cno 2010-07-29 12:44:35 UTC
Comment 4 jsc 2010-07-29 14:25:27 UTC
jsc -> sb: this is indeed a regression and it works in OOo 3.2.1. It probably
depends on the changes in the config manager and we should fix it if possible
for OOo 3.3.
Comment 5 cno 2010-07-29 14:59:16 UTC
thanks jsc!
maybe experience from cd (issue 110127) could be helpful?
Comment 6 Stephan Bergmann 2010-08-09 13:19:44 UTC
Apparently, with old configmgr implementation,
desktop/source/deployment/registry/configuration/dp_configuration.cxx called
m_defaultProvider->refresh() after removing extension .xcu files (effectively
removing the information provided by those files), while with the new configmgr
implementation it does nothing.
Comment 7 Stephan Bergmann 2010-08-12 10:08:52 UTC
Fixed as <>.

Technically, the new implementation no longer uses to update the configmgr database when an
extension xcu file is removed, but instead new  This has some

- A heuristic (which is not perfect) is used to remove exactly the data that was
introduced by the xcu file, without loosing data that was either (a) defined in
lower layers and would now shine through or (b) defined in higher layers to
modify the existing data.  See
for details.

- Extensions that were registered in an OOo installation before that
installation is upgraded to OOo 3.3 can have minor problems when being removed
now.  The first time such an extension is removed, life-removing the
corresponding xcu data does not work (i.e., this issue's bug occurs, and the
extension's option pages and menus stay visible until next OOo start).  After
the next OOo start, removal of any remaining old extensions works correctly.
Comment 8 Stephan Bergmann 2010-08-13 08:03:39 UTC
@tm: please verify
Comment 9 Stephan Bergmann 2010-08-26 16:01:35 UTC
Previous fix turned out to be incomplete, now completed with

- <> "sb130:
#i113096# fixed TODO in configmgr::Broadcaster::send (to ease debugging)"

- <> "fwk154:
i114090: adapt listener code to reflect changes in config mgr, notification of
change events (transplanted from 7c0cad639e0b6d74f4be88f5877270f1a8b9fa53)"

- <> "sb130:
#i113096# previous change contained an error in

- <> "sb130:
#i113096# UniversalContentBroker::changesOccurred is now also called for removed

- <> "sb130:
#i113096# previous configmgr::Components::removeExtensionXcuFile changes were
still not good"
Comment 10 h.ilter 2010-08-27 14:16:42 UTC
Verified with cws sb130 = OK
NOTE: Only a side pane from the extension is left. SB told me that it is not
part of the regression.
Workaround: Close and restart OOo
I'll file a additional issue for that.
Comment 11 h.ilter 2010-08-27 15:21:09 UTC
Follow up issue 114151