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.
*** Bug 103886 has been marked as a duplicate of this bug. ***
Coming from a post in the openoffice.org forum (https://forum.openoffice.org/en/forum/viewtopic.php?t=109574) I tested with LibO V7.5.0.3. Result: 1. This bug is resolved for annotations created with 7.5. 2. Using one of the attachments to this report: The bug still is showing. Conclusions: 1.a. This bug wasn't marked as related to or duplicate of a different bug which was fixeds meanwhile. 1.b. There was made a change with a related side effect. 2. The fix / chgange did the job incompletrely. See alo tdf#150592 . That bug was reported for V 7.4.0.3 .
*** Bug 150592 has been marked as a duplicate of this bug. ***
*** Bug 159994 has been marked as a duplicate of this bug. ***
(In reply to Wolfgang Jäger from comment #14) > Result: > 1. This bug is resolved for annotations created with 7.5. Are you sure you tested with Design Mode turned off? (Tools > Forms > Design Mode) I tested with 24.2.1 and can still reproduce from scratch. Version: 24.2.1.1 (X86_64) / LibreOffice Community Build ID: 359ef544e625d2ffbfced462ab37bd593ca85fa7 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Arranging the comments to front and the control to back has no effect. And it is inconsistent: +-------------+----------------+---------------+ | Design mode | Comments shown | Popup comment | +-------------+----------------+---------------+ | On | Behind | Above | | Off | Behind | Behind | +-------------+----------------+---------------+ 3 duplicates here, various comments on the AOO bug report also contesting the "won't fix" decision, and UX agreeing that it needs fixing in bug 150592 comment 5. So I am setting it back to bug instead of enhancement, as (on top of the above) I can't see a reason why anyone would like or expect the current behaviour (at least as a default).