Bug 154057 - Cell focus when creating a URL link button may be inconsistent
Summary: Cell focus when creating a URL link button may be inconsistent
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.4.5.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-03-08 07:53 UTC by Colin
Modified: 2023-11-21 06:44 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Simple Sample CALC (59.85 KB, application/vnd.oasis.opendocument.spreadsheet)
2023-03-08 07:54 UTC, Colin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Colin 2023-03-08 07:53:23 UTC
Description:
Not sure if it's a bug but it does appear to be an inconsistency having the potential to exacerbate other issues.
Attached is a demo CALC with a functioning URL button and embedded composite image of the various cell foci during the creation of the link button and subsequent focus on the underlying cell.
It seems odd to me that when creating the button it does not become the centre of attention and thereby draw all focal indication to itself.
Noticeably, the focus becomes partially concealed by the finished button.
I've only noticed it since the focal border became huge.

Steps to Reproduce:
It may be more than trivial if there is impact on other operations requiring specific focal precedence.
It has been noticed that the drop shadow on the button and the residual focus on the underlying cell MAY complement each other when the cell is focused by selecting an adjacent cell and then moving into the target by using the arrow keys
Sample Calc attached

Actual Results:
See attached

Expected Results:
Open to discussion


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 7.4.5.1 (x64) / LibreOffice Community
Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: sv-SE (en_GB); UI: en-GB
Calc: threaded
Comment 1 Colin 2023-03-08 07:54:43 UTC
Created attachment 185831 [details]
Simple Sample CALC
Comment 2 Stéphane Guillou (stragu) 2023-11-18 10:22:46 UTC
I reproduce on Linux as well.

The cell cursor is only hidden behind the button when Design mode is off. It is visible when Design mode is toggled on.
(Controls larger than a cell can hide entirely the cursor when design mode if off, which to me makes sense because when a spreadsheet used as an interface is just made to be "used" rather than edited, users won't want to see cursor over controls. Don't you think?)

Kind of related to bug 108240 and others, in that a cursor _surrounding_ the cell could solve the issue (if I understood correctly what the issue is?).

UX/Design team, I don't know if this needs changing at all, apart from what is already covered in other cell cursor bug reports?

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5fe2bf914c251009ec4709fa8fdc45c3b53f676b
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded
Comment 3 Colin 2023-11-18 11:47:26 UTC
Being a little more destructive I have created another link button in the "same space" by sidling into the cell.
The default button size is about half the cell height and remains accessible whilst it remains in focus. However, the focus "corners" re-size as though they are attached to the original button and the original button layers itself on top and will not respond to the arrange functions either to force it down one layer or force it to the back.
This is an illusion. It is only the focal corners that have "re-sized" to the "dominant" button the smaller concealed button is still in focus and will respond to simple "drag" actions and as it is already below the orginal button then it can of course not be forced further down.
The original button will always "retain focus" (Hovering over it produces the correct target URL) whilst it is placed on top of the newer button but all the dragging will still only impact the newer "concealed" button.

I can't really imagine any use for 3 dimensional URL Buttons but I can envisage confusion if a user has inadvertently created multiple buttons in the same cell and "lost track" of what they are hoping to achieve.

NOW 7.5.7.1 Win 10
Comment 4 Heiko Tietze 2023-11-20 08:59:35 UTC
May I ask how you create the button? Trying with ctrl+K on the cell (and form=button) I end up with a tiny button that neither covers width nor height.
Comment 5 Colin 2023-11-20 09:38:24 UTC
(In reply to Heiko Tietze from comment #4)
> May I ask how you create the button? Trying with ctrl+K on the cell (and
> form=button) I end up with a tiny button that neither covers width nor
> height.

Did you use the sample attached?

I just tried it with Ctrl+K (although I always use the Ribbon to insert URL) and I got a button that's cell width but a little more than half height.

Now on 7.5.7.1 and the newly created button does have a different form to the original report but only in so far as it now appears to automatically adopt the cell width. I always Anchor and Fit to Cell so the cosmetic difference is noticeable.

When in form edit mode and selecting the button to potentially drag it to a new location I get a small representation of the button during the transit. Is that the sort of size you're experiencing upon creation? If so - I suspect that's a new bug.
Comment 6 Heiko Tietze 2023-11-20 10:06:29 UTC
What you get depends on the zoom level - trying with 400% fooled me ending up in less width and height than the cell (other zoom levels also do not produce the expected result). I think it's not about the cell focus but the button size, first of all.
=> BUG (not sure whether this has been filed before)

(In reply to Colin from comment #5)
> I always Anchor and Fit to Cell...
Hard to imagine that users want a button not covering the whole cell. We should do this by default.
Comment 7 Stéphane Guillou (stragu) 2023-11-20 11:10:11 UTC
> (In reply to Colin from comment #5)
> > I always Anchor and Fit to Cell...
> Hard to imagine that users want a button not covering the whole cell. We
> should do this by default.
What about users having a variety of cell sizes, but wanting the same size for all buttons in the sheet / document?
Comment 8 Colin 2023-11-20 11:12:10 UTC
(In reply to Heiko Tietze from comment #6)
>  - trying with 400% 
Wow ;)

> => BUG (not sure whether this has been filed before)
Probably safer if you verify - you must have more experience than me.
 
> (In reply to Colin from comment #5)
> > I always Anchor and Fit to Cell...
> Hard to imagine that users want a button not covering the whole cell. We
> should do this by default.
About 95% of my buttons are Anchored and fitted to the cell so making it the default would suit me. It's easy enough to change the outliers.
Enhancement request? You or Me?
Comment 9 Colin 2023-11-20 11:14:08 UTC
(In reply to Stéphane Guillou (stragu) from comment #7)
> > (In reply to Colin from comment #5)
> > > I always Anchor and Fit to Cell...
> > Hard to imagine that users want a button not covering the whole cell. We
> > should do this by default.
> What about users having a variety of cell sizes, but wanting the same size
> for all buttons in the sheet / document?

Yeuk - must look like a pavement pizza
Comment 10 Heiko Tietze 2023-11-21 06:44:39 UTC
(In reply to Stéphane Guillou (stragu) from comment #7)
> What about users having a variety of cell sizes, but wanting the same size
> for all buttons in the sheet / document?

(In reply to Colin from comment #8)
> About 95% of my buttons are Anchored and fitted to the cell so making it the
> default would suit me.
And probably most other users too. It's about the default, and of course the size needs to be possible to change.