I have now restored the user profile, and the formula editor is working again.
However, it remains to be seen why the upgrade from 3.4.5. to release 3.5 caused the corruption, and if there is some other less drastic way to awake the formula editor other than completely resetting your profile.

For some users who use LO just as it is by default, this could be a non-issue, but if you (like me) have heavily customized your L.O. install, with modified and optimized toolbars for each app, hotkeys, etc., starting from scratch means replicating a LOT of effort, with the fear of having to do it again soon.

Created attachment 57101 [details]
config file that blocks the math formula editor since upgrading from 3.4.5. to 3.5

After fiddling a bit, I concluded that the single file registrymodifications.xcu keeps track of all customization: if I delete only this file from the user profile, all toolbars revert to the default ones, and Formula editor is working, while all the rest of the profile is unchanged.

So now the problem is: what is the bit of registrymodifications.xcu that blocks the formula editor? I opened the file with the Notepad, but it is actually difficult to see through it if you're not used too. And it is quite big too.
So I am attaching my guilty registrymodifications.xcu in case anyone knows how to check it and give hints on the issue.
Thanks

I was fortunate enough to find a kind folk who submitted the following macro which worked perfeclty, making math formula editor work again without losing all customization of LO.
Of course, I am left wondering what on earth could induce this in the upgrade from 3.4.5.to 3.5.... and whether there are other people out there who experienced the same... of course many people has never touched the formula editor, so they might not even know.

If anyone has the same problem, start your office, execute the following macro to remove the configuration and then restart your office.
This macro removes window position of math equation editor on Writer document to make its position default.

Code: Select all   Expand view
    Sub RemoveMathEquationWindowSettings
      p = CreateUnoStruct("com.sun.star.beans.PropertyValue")
      p.Name = "nodepath"
      p.Value = "/org.openoffice.Office.Views/Windows"
      cp = CreateUnoService("com.sun.star.configuration.ConfigurationProvider")
      ca = cp.createInstanceWithArguments(_
        "com.sun.star.configuration.ConfigurationUpdateAccess", Array(p))
      name = "30378"
      If ca.hasByName(name) Then
        ca.removeByName(name)
        ca.commitChanges()
      End If
    End Sub

LibreOffice Math fails to work in LO 3.5.0 on Linux system too.

OS: OpenSuse 12.1 64 bit.
LO is installed from rpms downloaded from official site.

Confirmed on Windows when upgrading to release 3.5.0.  I never changed the setting for formula editor either...

Temporary fix:
1) run macro posted by posted by Andy
2) Close Libreoffice completely
3) reopen Libreoffice
4) It should work.

(In reply to comment #5)
> Confirmed on Windows when upgrading to release 3.5.0.  I never changed the
> setting for formula editor either...
> 
> Temporary fix:
> 1) run macro posted by posted by Andy
> 2) Close Libreoffice completely
> 3) reopen Libreoffice
> 4) It should work.

Another fix:
1) Uninstall L.O.
2) Manually remove the tracker file (registrymodifications.xcu)
3) Reinstall L.O.

It worked fine for my Windows 7. The new install means a completely new configuration, so your old one will be missing.

Hi Elias, I think your workaround was already implicit in the  post made on 2012-02-15 07:34:58 PST. It's actually even easier: you do not need any additional uninstall and install in my experience, it suffices to delete the registrymodifications.xcu file in your LO profile, and the next time you run the app a wholly new profile is created and the math editor works again.
However as I wrote then, IMHO you're understating the problem: if you're a longtime and heavy user, you have probably customized LO extensively, and throwing away all such customization is a huge waste of time.
Of course if you are using LO just as it comes out of the box, this will not be a problem. Maybe I am too much keen on optimizing, but on average I have modified about 40-50% of all the original toolbars, carefully choosing and placing the best buttons for the most used functions and commands in each specific application. Often LO does not even offer you an icon for some commands, but you need one or the command will eat away your space as it is written explicitly in the toolbar, so I had to search for a suitable one somewhere else. And I have also added a lot of hotkeys.
In any case the fact is simple: for people who want/need to use the math formula editor, but do not want/are not able to fiddle with technical workarounds, macros, deletions of hidden profiles and the like, this is a showstopper: it makes you want to avoid upgrading. For example, I urged all my students not to move to 3.5 for the moment, to avoid the ensuing chaos of counseling each one on the problem and its complex solutions.
Of course I am hardly able to judge what is really important and urgent and maybe this problem is considered very low priority when compared to others because most people do not use the math editor. But for those who do but are not technically proficient, unless a 3.5.0.1 soon kills the problem, these are tough times....

(In reply to comment #3)
> I was fortunate enough to find a kind folk who submitted the following macro
> which worked perfeclty, making math formula editor work again without losing
> all customization of LO.
> Of course, I am left wondering what on earth could induce this in the upgrade
> from 3.4.5.to 3.5.... and whether there are other people out there who
> experienced the same... of course many people has never touched the formula
> editor, so they might not even know.

Thanks, I just noticed I had the same problem, and your macro fixed it for me.

I have the same problem with LibreOffice 3.5 running on Ubuntu 12.04.
Solved deleting ~/.config/libreoffice/3/user/registrymodifications.xcu

(In reply to comment #9)
> I have the same problem with LibreOffice 3.5 running on Ubuntu 12.04.
> Solved deleting ~/.config/libreoffice/3/user/registrymodifications.xcu

I can confirm that deletion of ~/.config/libreoffice/3/user/registrymodifications.xcu solves the problem with LO 3.5 Math running on linux.

OS: OpenSuse 12.1 64 bit.

After some people confirmed the problem I wrote about, I am a bit puzzled since it is not clear to me if this a problem for all or for a restricted number of installs. Nobody with any authority to do so has certified this bug as real or not, actually. But my puzzlement is perhaps due to my being used to Openoffice bug reporting process, and this works differently here. I just do not know.

And it is to me unclear as well whether incoming upgrades (3.5.1) have this same problem solved or not... how can I know if it is sensible to install them?? I have tried to look into the fixed bugs list, and I think I did not find any mention.....
So perhaps this is a problem worrying only the dozen of people reporting it here, and to nobody else in the world??
Anybody knowledgeable enough please help... thank you

I can now confirm that LO3.5.1 RC2 when installed on a WINDOWS machine without any previous LO or OO install on it, does not have the Formula editor freezing problem.
I do not know about upgrade installs, however.

See also bug 46573, bug 46148, bug 47457, bug 46427, bug 46057. This one has the best description of how to fix it though. Bug occurs during upgrade from 3.4 to 3.5.

*** Bug 46573 has been marked as a duplicate of this bug. ***

*** Bug 46148 has been marked as a duplicate of this bug. ***

*** Bug 46057 has been marked as a duplicate of this bug. ***

*** Bug 47147 has been marked as a duplicate of this bug. ***

*** Bug 46202 has been marked as a duplicate of this bug. ***

*** Bug 46911 has been marked as a duplicate of this bug. ***

Just as a hint:
I have installed LibreOffice 3.4.x and 3.5.x in parallel on a single machine running MacOS X 10.6.8, but there are NO such problems with the math formula editor. This does not, of course, mean that I have any doubt about the existence of this bad bug; it just means that the problems with the math formula editor do not occur *always* when upgrading from 3.4.x to 3.5.x, at least not on MacOS X and at least not when installing both applications parallel ...

(In reply to comment #20)
> Just as a hint:
> I have installed LibreOffice 3.4.x and 3.5.x in parallel on a single machine
> running MacOS X 10.6.8, but there are NO such problems with the math formula
> editor. This does not, of course, mean that I have any doubt about the
> existence of this bad bug; it just means that the problems with the math
> formula editor do not occur *always* when upgrading from 3.4.x to 3.5.x, at
> least not on MacOS X and at least not when installing both applications
> parallel ...
Not really sure I understand what you tried: how is that an upgrade if you installed them in parallel? Upgrade is new one over old one, not new and old side by side... (note sure if it does make a difference for this bug, though)

(In reply to comment #21)
> Not really sure I understand what you tried: how is that an upgrade if you
> installed them in parallel? Upgrade is new one over old one, not new and old
> side by side... (note sure if it does make a difference for this bug, though)

Well, it's an issue of naming. I know some people who call installing a newer version of an application, but keeping the old one just for security reasons for a while, an upgrade, and there are other people who don't call this an upgrade. But "what's in a name?"

I just wanted to help, and because I assumed that this bug probably would not only show if you 'upgrade' to 3.5.x in the strict sense of the word but also if you install 3.5.x side-by-side with 3.4.x I just checked if I could reproduce the bug with my double installation. There was a good chance that this worked, because, as http://wiki.documentfoundation.org/Installing_in_parallel points out, if you install a new version of LibreOffice along an existing one on MacOS X, "The new installation will share your existing LibreOffice user configuration and profile" -- similar to an upgrade which should to re-use the user configuration and profile from the old version.

But I could not reproduce the bug, and this gives us three possibilites:

1) the bug is OS-dependend and does not occur in LibreOffice for MacOS X, OR
2) the bug does only appear if you upgrade from 3.4.x to 3.5.x in the strict sense of the word, deleting any older version, OR
3) the bug does not appear in all cases, depending on some circumstances different from OS or the upgrade/parallel installation issue mentioned above.

To reveal which one of these possibilities is true needs further study. But if this all does not make any sense to you, just ignore it ;-) I just wanted to help a little bit, and if it doesn't help, it should (at least) not hurt you.

(In reply to comment #22)
> To reveal which one of these possibilities is true needs further study. But if
> this all does not make any sense to you, just ignore it ;-) I just wanted to
> help a little bit, and if it doesn't help, it should (at least) not hurt you.
Oh, ok, I wasn't aware of the shared configuration mentioned in http://wiki.documentfoundation.org/Installing_in_parallel, it does make sense to me now. Also I suppose you used version 3.4.6 and 3.5.1, maybe this matters too?

(In reply to comment #23)
> Oh, ok, I wasn't aware of the shared configuration mentioned in
> http://wiki.documentfoundation.org/Installing_in_parallel, it does make sense
> to me now. Also I suppose you used version 3.4.6 and 3.5.1, maybe this matters
> too?

I have installed LibreOffce 3.4.6 and 3.5.2rc2 at the moment, always the newest release/prerelease versions.

In my case, it occured during upgrade from 3.4.3 to 3.5.1, and in the OP's post it occured during upgrade from 3.4.5 to 3.5.0.

The problematic data is in registrymodifications.xcu. How this data got created, I do not know. This is the problematic data:

<node oor:name="30378" oor:op="replace">
  <node oor:name="UserData"></node>
  <prop oor:name="Visible" oor:op="fuse">
    <value xsi:nil="true"/>
  </prop>
  <prop oor:name="WindowState" oor:op="fuse">
    <value xsi:nil="true"/>
  </prop>
</node>

Specifically, the part:

  <node oor:name="UserData"></node>

Having this specific node empty (as it is above) will cause the problem to occur.

Inserting a value in this node eg:
  <node oor:name="UserData"><value xsi:nil="true"/></node>
or:
  <node oor:name="UserData"><value></value></node>

will fix the problem.

HTH.

(In reply to comment #25)
> Specifically, the part:
> 
>   <node oor:name="UserData"></node>
> 
> Having this specific node empty (as it is above) will cause the problem to
> occur.

Ah, very interesting. On my machine, where the problem doe NOT occur, the values are:

<node oor:name="30378" oor:op="replace">
  <node oor:name="UserData">
    <prop oor:name="Data" oor:op="fuse" oor:type="xs:string">
      <value>V2,V,0,AL:(9,16,0/0/591/188,591;188)</value>
    </prop>
  </node>

Whatever this means, it is obvious that the UserData note is NOT empty, and this supports the observation that an empty value of the UserData note causes the problem.

Hint for MacOS X users: the file 'registrymodifications.xcu' is at
~/Library/Application Support/LibreOffice/3/user/

We will have to find out
a) what registrymodifications.xcu contents prevents command edtit pane from 
   appeareing 
b) How does that contents come into registrymodifications.xcu 

I am not optimistic. But I will do some tests with "config file that blocks the math formula editor"

In MacOS the problem is solved just deleting the file

Library/Application Support/LibreOffice/3/user/registrymodifications.xcu

From home User.

*** Bug 50159 has been marked as a duplicate of this bug. ***

[Reproducible] with reporter's "registrymodifications.xcu" and "LibreOffice 3.5.5.1  German UI/Locale [Build-ID: c9944f7-48b7ff5-0507789-54a4c8a-8b242a8] on German WIN7 Home Premium (64bit); what ever that might mean.

I observed that Math Editor worked notmal again after I had switched back to my normal "registrymodifications.xcu", but the Editing Pane now was undocked, during my tests before I switched to reporter's "registrymodifications.xcu" the editing pane was docked.

I wonder whether this is still reproducible for an update from 3.4.6 to 3.5.6

The problem did/does not occur after upgrade from 3.5.5 to 3.6.0 to 3.6.1
So possibly the bug will get less relevant with version 3.6 becoming the current version.

(In reply to comment #32)
> The problem did/does not occur after upgrade from 3.5.5 to 3.6.0 to 3.6.1
> So possibly the bug will get less relevant with version 3.6 becoming the
> current version.

True, the problem does not occur in 3.6.1 in the Windows version (Vista).
But it is new in the Linux-64 version! 

The workaround (macro) works, no need to copy the first line above the 'sub'

Simple workaorund, so not "Critical", but of course annoying.

@duwn01@foni.net:
<http://wiki.documentfoundation.org/BugReport_Details#Version>

@Stephan:
Any Idea? Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf

Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9db74c6133ede2a28af077fd563398176ff0d858

fdo#46071: Do not hide windows based on nil "Visible" property



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

See the commit message of <http://cgit.freedesktop.org/libreoffice/core/commit/?id=9db74c6133ede2a28af077fd563398176ff0d858> "fdo#46071: Do not hide windows based on nil 'Visible' property" for details.

Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a4cdd39b154cfc0c7cb9912f8d31b59dec3e5e60&g=libreoffice-3-6

fdo#46071: Do not hide windows based on nil "Visible" property


It will be available in LibreOffice 3.6.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

The content of attachment 57101 [details] has been deleted