Hello porter21g,
thank you very much for your bug report!

I am sorry that LibreOffice crashes for you. However, the same two things which cause LibreOffice to crash for you work fine on many other machines (e.g., on my one; I have just tried again with LibreOffice 3.5.4.2, German langpack installed, on MacOS X 10.6.8: no crashes, (re)setting the colors works as expected).

So we need to find out what makes the difference, i.e. why LibreOffice crashes in your installation. The first things to check are:

1) Please tell us which MacOS X version you use (10.6.x or 10.7.x? PPC or Intel)? This is often important.

2) Do you have any accesibility features enabled? Apple's accessibility
features like "VoiceOver" or "Enable access for assistive devices", which get
enabled in "System Preferences > Universal Access" (in German:
"Bedienungshilfen"), are known to cause many crashes in LibreOffice. So please
try to disable any accesibility features. Compare, e.g., the similar issue bug
47368.

3) Can you please try running LibreOffice with a brand new LO user profile (see
http://wiki.documentfoundation.org/UserProfile)? This seems to heal many
serious problems, cf. the brand new bug 51323.

Thank you very much for trying this out (and please report the results here,
too)!

Thanks for your questions.

I'm using OS X 10.6.8 with 2.4 GHz Intel Core 2 Duo processor

No accessibility features enabled that I'm aware of.

I re-set the user profile as you asked. Libre Office immediately crashed as I originally described, with both Background Colour and Font Colour.  I tried it on two different documents with the same result.

In case it helps, the documents are both saved in ODF Spreadsheet (.ods) format.

Thanks for your continuing investigation!

(In reply to comment #2)
> Thanks for your questions. [...]

Thank you very much for your additional testing! Well, your results make the issue rather "exiting": I should be able to reproduce the crash (we both use the same LibreOffice and MacOS X version), but until now, I could not reproduce it. I will do some more investigation and hope that I will find out ...

I'm sorry, but even after doing many additional tests I can't reproduce the crash; for me, changing background color to "No fill" and font color to "Automatic" always work as expected. 

But I have found some bug reports which are very similar, especially bug 44471 -- "FORMATTING: Changing character background color causes HANG". This and some similar reports (see bug 47368 and its many duplicates) are caused by the fact that in MacOS X "System Preferences", section "Universal Access", the option "Enable access for assistance devices" was checked (this is the first checkbox at the bottom of the "Universal Access" preference pane).

Similar crashes can also happen if other options in "Universal Access" are activated, e.g. "Voice over", or if some special MacOS user interface utilities are installed, namely
* Moom  (see bug 42014)
* Cinch (see bug 51791)
and maybe other utilities which provide windows snapping, zooming in and out of windows, etc. on MacOS X.

> No accessibility features enabled that I'm aware of.

Therefore I want to ask you again (sorry!) if you are really sure that no accessibility features are activated on your Mac -- please check again in "System Preferences", section "Universal Access"! Sometimes it happens that users just forget about such settings or that these settings are activated by 3rd-party software without notifying the user at all.

If this is not the case, please check if you have any special system utilities installed like Moom or Cinch or other utilities or apps which interact with the general handling of windows or with the user interface or appearance of MacOS X and its applications.

Sorry for asking you again, but this is really important ... Thank you in advance for your patience and answer!

I think you have identified the problem.  No options are activated in Universal Access.  However, I am using  RightZoom, which forces the zoom button to maximise the window in all cases, rather than zoom to some random size, depending on the application.

When I include LibreOffice in the list of apps excluded from RightZoom, "No Fill" and "Automatic' in Background Fill and Font Colour work perfectly.  When I remove LibreOffice from the list of excluded apps (i.e. RightZoom attempts to work on LibreOffice windows), selection of "No Fill" or " Automatic" causes LibreOffice to crash.

Incidentally, I have just installed v 3.5.5.3 of LibreOffice, and the effect of RightZoom seems to be exactly the same as on v 3.5.4, i.e. LibreOffice works correctly when excluded from RightZoom and crashes as described when RightZoom attempts to work on it.

Thank you for your good detective work.

(In reply to comment #5)
> Thank you for your good detective work.

Oh, thank you for getting back to us and reporting your results about RightZoom! This will allow us to help other users which experience such crashes.

*

Summary adapted to make it easier to find this bug report.

I mark this bug report as a duplicate of bug 47368, because the analogy with other MacOS window utilities (see bug 42014, bug 51791) indicates that RightZoom may be relied on accessibility services, too.

*** This bug has been marked as a duplicate of bug 47368 ***

Created attachment 64499 [details]
MacOS X log file for the crash caused by this issue

For the record:
I have reproduced this issue just by installing and activating RightZoom; here is the log file created by MacOS X 10.6.8 for the crash.

Created attachment 64594 [details]
Log for similar Crash - Writer, add bkg color to paragraph - LibO 3.6.0.2+, RightZoom running



For the record:

While I can reproduce this crash so easily with LibO 3.5.5.3 when RightZoom is activated, I can not reproduce this crash with LibO 3.6.0.2+ (actually, with Norbert’s debug build of 3.6.0.2+). This may be because of bug 51943 which currently makes setting the char color/bkg color from the toolbar difficult or impossible, and therefore may "hide" the present bug.

I can, however, reproduce a similar bug with Norbert’s debug build of 3.6.0.2+ and RightZoom running -- in (at least) two ways:

(1) new Writer document; type some words, select the line, select Format > Paragraph, click through all tabs (! this is necessary to reproduce!), tab Background, select a background color (e.g. Light Red), click OK > Crash.
--> I attach the log file for this crash.

(2) new Writer document; Format > Insert > Table..., add a table (default, 2 cols, 2 rows, border), click in table, Format > Table Properties..., click trough tabs forward and backward, finally select "Background", select a background color ("Red"), click OK > Crash.
--> The log file seems to be nearly identical to the one for (1).

But both 3.6.0.2+ logs look quite different from my 3.5.5.3 log (attachment 64499 [details]): no accessibility-related stuff, as far as I can see ...

Further observations:

Bug 51943 is fixed now (thanks, Thorsten!), at least in the lastest master (LOdev 3.7.0.0.alpha0+, Build ID: c549e1e, installation file: master~2012-07-25_02.21.07_LibO-Dev_3.7.0.0.alpha0_MacOS_x86_install_en-US.dmg).

Therefore I would have expected that the present bug would be reproducible again -- i.e., that selecting "No fill" from the pulldown palette under the "Background Fill" toolbar button, or selecting "Automatic" from the pulldown palette under the "Font Color" toolbar button, would crash LibO again, just like it crashes 3.5.5.3, when RightZoom is running and activated.

But the crash did not return -- with the master build cited above, I can set text color and (cell) background fill color and (in Writer) paragraph background color to any color I want, including "Automatic" or "No fill" respectively, without any crashes. I can not guarantee this for 100%, because reproducing these accesibility-related bugs was always tricky, but it seems that the present bug, as originally described by porter21g (comment #0), is gone away at least in the current master build. Therefore, it may be also fixed in the forthcoming 3.6.0.3 (we will see).

Nevertheless, setting the cell fill color (Calc) or paragraph background color (Writer) via menu and dialog window still crashes LibO, just as I wrote in comment #8.

This seems to indicate that something important has changed in the underlying code for the color pulldown palettes. Of course, Winfried Donkers changed the behaviour of the color pulldown palettes and buttons this winter, on request of Stefan Knorr/Astron (see the comments in bug 51943), and these changes seem to have eliminated the present accessibility bug by the way.

Now it would be great if this would give us a clue about how to fix the remaining accessibility crashes ...

Created attachment 65116 [details]
LibO 3.5.6.1 Font Color crash log (MacOS X 10.6.8, Intel, RightZoom running)

I'm sorry to say so, but this bug is still REPRODUCIBLE with LibO 3.5.6.1 on MacOS X 10.6.8 (Intel), when RightZoom is running and activated. So the patch 68a81bb592f269712372173abcc50483dd556d56 which was backported to 3.5.x (see

http://cgit.freedesktop.org/libreoffice/core/commit/?id=68a81bb592f269712372173abcc50483dd556d56&g=libreoffice-3-5

) did not solve this issue.

Attached you find the MacOS X log file created for the 1st variant of this crash: selecting Font Color "Automatic" from the pulldown color palette from the toolbar crashes LibreOffice 3.5.6.1.

Created attachment 65117 [details]
LibO 3.5.6.1 Highlighting Color crash log

Attached you find the MacOS X log file created for the 2nd variant of this
crash: selecting Highlighting Color "No fill" from the pulldown color palette from the toolbar crashes LibreOffice 3.5.6.1.

Created attachment 65118 [details]
LibO 3.5.6.1 (paragraph) Background Color crash log

Attached you find the MacOS X log file created for the 3rd variant of this crash: selecting (paragraph) Background Color "No fill" from the pulldown color palette from the toolbar crashes LibreOffice 3.5.6.1.

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

Mac Accessibility Related Bugs Survey Results
---------------------------------------------

Tests
.....

All tests done on Mac OS X 10.6.8 (Intel), with RightZoom installed and running to provoke the accessibility-related bugs.

Following the steps to reproduce given by the original reporter, I can NOT REPRODUCE this crash anyore with 
* LibreOffice 3.6 daily (3.6.2.0+), Build ID: cfbfa26,
  Pull time: 2012-09-07 10:35:10, German langpack installed
* LOdev 3.7.0.0.alpha0+, Build ID: 5ca197c,
  Pull time: 2012-09-06 07:07:33, US English langpack installed

The same is true for the paragraph background color; setting it to “No fill” from the pulldown palette under the Paragraph Background Fill toolbar button crashes LibreOffice 3.5.x, but not the 3.6/3.7 daily builds mentioned above.

The same is true, if I don’t use the pulldown palettes available via the toolbar buttons, but the “Character” and “Paragraph” dialog windows available from the menu “Format > Paragraph...” or “Format > Character...”; changing character color, highlighting (= character background) color, or paragraph background color to any value, including “No fill” or “Automatic” resp., does NO longer crash the 3.6/3.7 daily builds mentioned above.

Cf. the similar bug 44471 (which just covers only the character background = highlighting color), where I have reported the same results.


Analysis
........

The two 3.6/3.7 daily builds mentioned above do not yet include the two
patches which fixed bug 47368 (these were first available in the 3.6/3.7 daily builds dated 2012-09-10 or -11). This means in turn that this bug is/was NOT a duplicate of bug 47368, which was fixed by the two patches cited above.

Therefore I change the status of this bug to RESOLVED/WORKSFORME, as usual when
a bug is no longer reproducible but we don’t know which commit exactly has
fixed it.


Hints for the curious one
.........................

In comment #8, I have mentioned another way to reproduce an accessibility-related crash:
> (2) new Writer document; Format > Insert > Table..., add a table (default, 2
> cols, 2 rows, border), click in table, Format > Table Properties..., click
> trough tabs forward and backward, finally select "Background", select a
> background color ("Red"), click OK > Crash.
> --> The log file seems to be nearly identical to the one for (1).

This crash is still reproducible with the two 3.6/3.7 daily builds mentioned above, but was fixed by the first 3.6/3.7 daily builds which included the two patches for bug 47368. This means that this crash was NOT identical to the original bug reported in comment #0, but instead was identical to bug 47368.


@ Everybody:

Please reopen this bug report, IF and ONLY (!!!) if you can still reproduce
this bug more or less exactly by the steps listed in comment #0 with a LibreOffice 3.6.x version newer than 2012-09-11 or with a LibreOffice master (3.7) version newer than 2012-09-11.

If you encounter a similar issue, which is not exactly the same, please file a
NEW bug report for it (and CC me about it: bugs@eikota.de), and describe
exactly: step by step, mouse click by mouse click, how to reproduce it.

Thank you!

Mac Accessibility Related Bugs Survey Results
---------------------------------------------

Supplement on LibreOffice 3.5.x
...............................

The steps given in comment #0 still lead to a crash with LibreOffice 3.5.6.2 (Build-ID: e0fbe70-dcba98b-297ab39-994e618-0f858f0) on Mac OS X 10.6.8 (Intel) with RightZoom running to provoke the accessibility-related bugs.

But, as said above, they don’t crash anymore with LibreOffice >= 3.6.1. This
confirms my statement (comment #14) that this bug has been fixed somehow BEFORE
the two patches which fixed bug 47368 have been applied, probably already in
the 3.6 development process.

You could ask to fix this bug also in the 3.5 branch where it is still
reproducible, but the chances are bad: we don’t know which commit(s) have fixed
the issue, therefore it is not possible to backport that commit(s).

Additionally, there is a workaround suitable for most users (disable any Mac
accessibility features and accessibility-related utilities).

Therefore, this bug will probably not get fixed in the LibreOffice 3.5 branch,
sorry. So please do NOT reopen this bug report just because this bug was not
fixed in LibreOffice 3.5.x ;-)

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