Created attachment 55961 [details] Tooltips below form controls Problem description: If there are controls on the sheet, tooltips are displayed below controls, making them unreadable. Steps to reproduce: 1. Put some buttons to the sheet 2. Make a tooltip for a cell that is left of the buttons 3. Hover over the cell to display a tooltip -> tooltip is displayed below controls Current behavior: Tooltips are displayd below form controls. Expected behavior: Tooltips should be displayd on top of form controls. Platform (if different from the browser): Ubuntu 11.10 32-bit, LO 3.4.5, 3.4.4, 3.4.3, Mint Debian 32-bit, LO 3.3.3 Browser: Mozilla/5.0 (Ubuntu; X11; Linux i686; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
I just tested LO 3.5.0rc1 (as part of QA/BugHunting Session 3.5.0.-2), and this is still a bug.
Hi Zarko, thanks for testing and the bug. I can confirm this. Additional: when I creata a file with controls and comments in 3.4.5, initially the notes are visible. But after closing and reopening the file, they are hidden too.
Created attachment 56668 [details] file with controls and notes, from 3.5.0RC3
Created attachment 56669 [details] file with controls and notes, from 3.4.5
Is this a regression against 3.4? I think we changed something about the order different elements are painted but I'm not sure if it should also affect Notes. Might be that we just need to change the order in the code.
(In reply to comment #5) > Is this a regression against 3.4? As explained in my comment: party: with creating teh document 3.4.5 is OK. With reopening, both versions are bad.
> > As explained in my comment: party: with creating teh document 3.4.5 is OK. > With reopening, both versions are bad. Sorry Cor. Just got hope from FOSDEM and was checking bugzilla mails without reading carefully what has been discussed. I try to find some time looking into that or I'll talk to Kohei the next days.
(In reply to comment #7) > Sorry Cor. Just got hope from FOSDEM and was checking bugzilla mails without > reading carefully what has been discussed. No problem _ I often suffer from the same symptoms ;-) Thanks for looking at this :-)
Not that much of an annoying feature.
(In reply to comment #9) > Not that much of an annoying feature. Formattig. Annoying people with existing document ...
Not a new problem, already [Reproducible] with Server Installation of "LibreOffice 3.3.3 German UI/Locale [OOO330m19 (Build:301) tag libreoffice-3.3.3.1] on German WIN7 Home Premium (64bit). So inherited from OOo, and so definiteively not a "3.5 MAB" (but may be an enhancement request). AOOo decision: WONTFIX (because of conflicting interests?) I removed target information due to facts. Steps how to reproduce (creeating a sample document similar to Cor's): 0. Open new Spreadsheet from LibO start center 1. If necessary, menu 'View -> Toolbars -> Form Controls' 2. Insert a Push button covereing cells C4:E7 3. Click B9 4. Menu 'Insert -> Comment', type Text "This is a commt with some very long text in it" (or similar) 5. Click on an empty cell to leafe comment > Small comment mark is in cell B9 6. Move mouse pointer into B9 over comment mark As Expected, comment becomes visible 7. In Form Controls toolbar disable "Design Mode" 8. Redo step 6 Problem: Comment now appears behind the push button With active 'Show Comment' the problem also is visible while Form Controls are in Design Mode. The question is how a solution should look? "Comments visible" in front of form controls can make form controls unusable, but invisible Comments are not very useful. My suggestion: "Normally Invisible" Comments always should appear in front of buttons. Normally they are hidden and do not cause access problems for the form controls I can't understand why the creator of a spreadsheet inserts "Normally visible" Comments what conflict with push buttons? But if the user activates enduring visibility it is ok that the comment appears behind form controls to keep access to form controls. But an Enhancement could bring the comment to the forgeground when the user moves the mouse pointer to the Comment mark?
Yes definitely inherited from OOo. Usually happens less often in Portable OOo 3.2 though, and that's why I still use that version. One thing to think of is that this is not just a problem with form controls like buttons etc. For example it happens for a window freeze as well. The comment does not show up on top of the window freeze line. The Freeze lines is shown on top of the comment which makes it hard to edit the comment etc. This is separately filed as bugs already. As Rainer Bielefeld writes: "But an Enhancement could bring the comment to the forgeground when the user moves the mouse pointer to the Comment mark?" I agree that this would be the perfect solution. The addition to that It would be good if the comment would be brought to foreground of every possible thing that could interfere with the comment, not just form controls.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.