Description: When a chart object is placed on a sheet (the chart is flipped 90 degrees right) and a hyperlink button is placed on top of the chart object then hovering the mouse anywhere on the chart produces the hint to ctrl-click to open the hyperlink as if it were a text link. I'm uncertain whether having multiple buttons is significant. If the mouse is hovered over the URL Button it produces the correct tip identifying where it is going. Attached is a composite screen grab where the top half demonstrates the tip for anywhere on the chart and the bottom half identifies what would be expected if the mouse hovers over the button. Not to worry about exposing the address. The reponse requires a Qcode scan and an encrypted passcode sent from another device. Steps to Reproduce: With tips activated and with a chart created from data over which it has been laid and a pair of Hyperlink buttons to external websites moved into position on top of some empty space on the chart (I also have two local hyperlink buttons located directly beneath the external links):- 1) Mouse hover over any area of the chart and observe that it will produce a tip as though it were a text hyperlink for the first hyperlink below the mouse location. 2) Mouse hover over the hyperlink button and observe that it correctly identifies the target. Actual Results: Unexpected and potentially inaccurate tip. It's almost as if the surface of the chart is acting as a syphon to a hypothetical tip for a hypothetical text URL. Expected Results: The tip in the top half of the image should never occur. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.6.2 (X86_64) / LibreOffice Community Build ID: f654817fb68d6d4600d7d2f6b647e47729f55f15 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
Created attachment 189795 [details] Composite screen grab showing both states of the mouse hover
What may be another symptom of the problem is that when identifying the file to which the URL relates, it used to be that one could simply hover the mouse over the URL type selector and use the mouse scroll wheel to scroll between "TEXT" & "BUTTON" as opposed to formally entering the list to select or interacting with the selector button. 7.5.6.2 was only installed yeaterday and the "feature" identified itself immediately following installation. I do have at least 617 instances prior to this installation where the scroll wheel functioned and the chart background never "syphoned" the text tip onto the screen.
(In reply to Colin from comment #2) > What may be another symptom of the problem is that when identifying the file > to which the URL relates, it used to be that one could simply hover the > mouse over the URL type selector and use the mouse scroll wheel to scroll > between "TEXT" & "BUTTON" as opposed to formally entering the list to select > or interacting with the selector button. 7.5.6.2 was only installed > yeaterday and the "feature" identified itself immediately following > installation. > Is this the new "norm"? Further experimentation identifies that all "multi-choice" selections in all parameter settings panes now require physical entry into the selection box rather than just hover and scroll. Once upon a time, pre-7.5.6.2 for me, we could scroll through the multi choice panes with the mouse outside the boundaries of the input boxes and it would scroll from top to bottom of the pane (spiritually linked to the scroll-bar) but then moving to hover over the target parameter would scroll that parameter's values. A good example is the "Properties Push Button" pane for "Control Properties" when in edit mode and right-clicking a push-button. I create multiple push buttons daily so it was a valued feature and it feels like somebody fixed something that was never broken.
Please attach a sample file, so someone can test.
Created attachment 189812 [details] Simple Demo File The Web links will only take you to the public facing logon page that's freely available to everybody on the planet - with a computer and web service that is. Obviously, the "local" links will bomb-out because the tester's local environment will not match mine. All aspects of the "feature" including the inability to scroll through the button editing pane when editing is enabled.
Correction: It produces the invalid tip syphoned from the first button wherever the mouse is located over the chart. It doesn't just produce the tip for the button immediately below the mouse. Whilst this is having a limited cosmetic effect it may be symptomatic of a bigger problem - like the "side-effect" of no longer being able to scroll through the panes and then focus the mouse-scroll onto the input box detected purely upon the current location of the mouse.
Deleting the chart, doesn't solve the issue for me. I think it is something in relation with the forms properties. Doing a copy of 'Hand' button, and pasting in it the URL of 'Data' button, it works fine for me.
(In reply to m.a.riosv from comment #7) > Deleting the chart, doesn't solve the issue for me. > I have another file with 620 Buttons stacked neatly into "Fit to cell" - "Resize with cell" columns and that works perfectly. As would be expected, the mouse scroll provides a dynamic update as it moves over each button. That sheet has a chart which is in an area that has never seen a button and there's no "interference" from URL legends. Are you observing the same issue with scrolling through the button properties and is it a seperately reportable "feature"?
(In reply to m.a.riosv from comment #7) > Deleting the chart, doesn't solve the issue for me. > > I think it is something in relation with the forms properties. > Doing a copy of 'Hand' button, and pasting in it the URL of 'Data' button, > it works fine for me. How is the issue seen after you delete the chart? I did it and I only see the tooltip when hovering over the buttons. I wonder what are the reproduction steps from scratch or with the data.
(In reply to Buovjaga from comment #9) > (In reply to m.a.riosv from comment #7) > > How is the issue seen after you delete the chart? I did it and I only see > the tooltip when hovering over the buttons. I wonder what are the > reproduction steps from scratch or with the data. You may have noticed the chart is a stacked bar chart with columns defining the positive or negative effect of the month's movement. could the chart type be significant? I've also noticed that if you left click the chart surface the tooltip becomes a permanent addition to the cursor - following it all around the chart but disappearing when the mouse moves "out of bounds"
(In reply to Buovjaga from comment #9) > (In reply to m.a.riosv from comment #7) > ... > How is the issue seen after you delete the chart? I did it and I only see > the tooltip when hovering over the buttons. I wonder what are the > reproduction steps from scratch or with the data. It shows empty tooltips for second to fourth button.
(In reply to m.a.riosv from comment #11) > .... > It shows empty tooltips for second to fourth button. Ok my bad, the same behavior as with the chart. Passing the validator to the file for version 1.3 extended: URLError.ods/content.xml[2,77434]: Error: attribute "table:cell-range-address" has a bad value I don't know if it has something to do.
(In reply to m.a.riosv from comment #11) > (In reply to Buovjaga from comment #9) > > (In reply to m.a.riosv from comment #7) > It shows empty tooltips for second to fourth button. They were intentionally "nulled" to avoid unnecessary tooltip intrusions
(In reply to Colin from comment #13) > (In reply to m.a.riosv from comment #11) > > (In reply to Buovjaga from comment #9) > > > (In reply to m.a.riosv from comment #7) > > > It shows empty tooltips for second to fourth button. > > They were intentionally "nulled" to avoid unnecessary tooltip intrusions Correction: When a button is first created the link address automatically appears as a "help" popup if the user doesn't provide an alternative. The only way to suppress it was to force a space character in the help attribute.
The only way I can reproduce it on Linux with the gtk3 VCL plugin is by following these steps: 1. Open attachment 189812 [details], scroll down a bit (but keep the "Hand" button in view) 2. Hover over the top of the "Hand" button: it displays only the URL in the tooltip 3. With mousewheel, scroll up _once_ without moving the mouse (the pointer should end up over the chart area) Result: the tooltip changes to "Ctrl-click to open hyperlink: <URL>" (and doing that _does_ open the web browser) This does not happen if there is no chart behind, or a shape instead of a chart. Version: 7.5.7.1 (X86_64) / LibreOffice Community Build ID: 47eb0cf7efbacdee9b19ae25d6752381ede23126 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded However, with the gen VCL plugin, I can reproduce directly without the trick above. Regression as I can't reproduce in OOo 3.3, but already present in libreoffice-3.3.0 (tested with gen VCL plugin in the libreoffice-64-release bibisect repository). Noticing that back in OOo 3.3, the cursor would not change to the hand cursor when hovering above the chart.
(In reply to Colin from comment #2) > What may be another symptom of the problem is that when identifying the file > to which the URL relates, it used to be that one could simply hover the > mouse over the URL type selector and use the mouse scroll wheel to scroll > between "TEXT" & "BUTTON" as opposed to formally entering the list to select > or interacting with the selector button. 7.5.6.2 was only installed > yeaterday and the "feature" identified itself immediately following > installation. > This may be a symptom of a recent windows 10 update. I've just noticed that other - less frequently used apps - that previously permitted "scroll on hover" now also continue scrolling the whole page instead of the selection box. Is it worth anybody verifiying that I haven't just "lost my marbles"