Bug Hunting Session
Bug 45085 - VIEWING: Notes/comments are displayed in background of FORMCONTROLS
Summary: VIEWING: Notes/comments are displayed in background of FORMCONTROLS
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86 (IA32) All
: low enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 103886 (view as bug list)
Depends on:
Blocks: Calc-Comments
  Show dependency treegraph
 
Reported: 2012-01-22 06:56 UTC by Zarko Zivanov
Modified: 2016-11-29 18:38 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Tooltips below form controls (233.19 KB, image/png)
2012-01-22 06:56 UTC, Zarko Zivanov
Details
file with controls and notes, from 3.5.0RC3 (9.64 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-02-06 05:32 UTC, Cor Nouws
Details
file with controls and notes, from 3.4.5 (9.25 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-02-06 05:33 UTC, Cor Nouws
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zarko Zivanov 2012-01-22 06:56:43 UTC
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
Comment 1 Zarko Zivanov 2012-01-22 08:16:22 UTC
I just tested LO 3.5.0rc1 (as part of QA/BugHunting Session 3.5.0.-2), and this is still a bug.
Comment 2 Cor Nouws 2012-02-06 05:31:17 UTC
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.
Comment 3 Cor Nouws 2012-02-06 05:32:43 UTC
Created attachment 56668 [details]
file with controls and notes, from 3.5.0RC3
Comment 4 Cor Nouws 2012-02-06 05:33:21 UTC
Created attachment 56669 [details]
file with controls and notes, from 3.4.5
Comment 5 Markus Mohrhard 2012-02-06 11:25:36 UTC
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.
Comment 6 Cor Nouws 2012-02-06 12:06:19 UTC
(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.
Comment 7 Markus Mohrhard 2012-02-06 13:52:56 UTC
> 
> 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.
Comment 8 Cor Nouws 2012-02-06 13:57:34 UTC
(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 :-)
Comment 9 dE 2012-04-15 21:06:11 UTC
Not that much of an annoying feature.
Comment 10 Cor Nouws 2012-04-16 12:36:52 UTC
(In reply to comment #9)
> Not that much of an annoying feature.

Formattig. Annoying people with existing document ...
Comment 11 Rainer Bielefeld Retired 2012-11-21 09:56:22 UTC
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?
Comment 12 Fredrik Lonn 2013-04-07 08:01:14 UTC
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.
Comment 13 Buovjaga 2016-11-24 08:38:22 UTC
*** Bug 103886 has been marked as a duplicate of this bug. ***