Created attachment 76732 [details]
Example doc w/ frames
Put the cursor in front of XXX1 in the table and insert a frame. Even if you set the background of the frame to No Fill, the resulting frame has the same background shading as the cell to which it is attached (see frame 3). This is annoying because it means I can't attrach frames where they belong - i have to cheat and anchor them to the page so they have no background.
Thanks for reporting!
I can confirm this behavior. Although I don't know this is intended by the developer, I'm going to mark this as NEW.
I think it is good to verify/ask the UX (user experience) list https://www.libreoffice.org/get-help/mailing-lists/ for their opinion.
tested using Linux Mint 14 x64, LibreOffice 126.96.36.199.
This would appear to be a duplicate of bug 34585. What appears to be occuring is that the Insert > Frame... type of draw:frame object is having its background set to that of the anchor point. Using the example document, inserting a frame as described in the first (shaded) cell indeed results in a shaded frame background. Dragging the anchor to the next (unshaded) cell results in a white frame background. As bug 34585 indicates it is impossible to set a transparent (no colour) background for this type of frame. By comparison a draw:frame object created by clicking on the Text icon in the Drawing toolar does have a transparent background and is not influenced by the anchor location.
Tested under Crunchbang 11 running TDF/LO v188.8.131.52 Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28.
Yes, most likely these are related.
I agree with Owen that this is a dupe of bug 34585 and am marking it as such. Setting a frame's background to "No Fill" does not actually make it transparent, it just sets the frame's background colors to match the anchor point's background.
But I don't believe he's right about there not being a work around. As is mentioned in the other report, you can simply change the frame's background from "No Fill" to a color and change the transparency to 100% and it should work as expected of a true no-fill frame.
*** This bug has been marked as a duplicate of bug 34585 ***