If a new CellStyle is created and the fillBackgroundColor and fillForegroundColor are set using the values from the column's default style, then both the foreground and background colors are set to 64 which is intended to represent AUTOMATIC. Microsoft's documentation, though, indicates that 64 is the system foreground color and 65 is the system background color. http://msdn.microsoft.com/en-us/library/documentformat.openxml.spreadsheet.indexedcolors%28v=office.14%29.aspx In excel, everything looks fine until you edit the cell at which point, the cell becomes a black box (black foreground and background) while the cell is being edited.
Any chance you could use Excel to create a simple test file, which shows the 64 for the foreground but the 65 for the background? That could then be used towards a unit test for the problem
Not sure I can force a 65 from Excel directly. It appears to just leave the element unspecified which internally defaults. I can, though, create a test where an Excel file is created with both values and hopefully demonstrate the problem. I'll attach a couple of tests shortly
Created attachment 31639 [details] Test case test case that produces an xlsx file that demonstrates the problem.
Created attachment 31640 [details] sample file produced by the test. editing the first cell causes black box while editing editing second cell which has background color set to 65 is fine
Added a testcase and a sample file that demonstrates the problem. The test produces an XLSX file that has 2 cells. The first cell has a cell style whose fillBackground is set from the column style (which is 64). The second cell has a fillBackground explicitly set to 65. If you open the spreadsheet in Excel and edit the first cell, you'll see that the cell turns to a black box while editing. I'm using Excel 2013 on Windows 7 (in case it matters)
Created attachment 31642 [details] second sample.xlsx I believe I inadvertently saved the previous sample.xlsx in excel. Excel removed the <bgColor indexed="65"/> element from the styles.xml when it saved. This attachment is what is actually produced by the test
For HSSF there is some very strange back-and-forth conversion which seems to try to handle this transparently, i.e. conver to 64 and 65 as needed, see e.g. HSSFCellStyle.checkDefaultBackgroundFills(), however I'm not sure if this does what it should always and if it would make sense to do similar things on the XSSF side. Usually I'd rather remove this special handling in HSSF as well, however it might cause compatibility issues with previous versions of POI...
A user on the ML confirmed that setting backgroundfillcolor to 65 is a valid workaround for this.