Bug 105282 - Button form control hyperlinked to Draw page or Impress slide never updates target URL when it should (comment 15)
Summary: Button form control hyperlinked to Draw page or Impress slide never updates t...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Hyperlink Form-Controls
  Show dependency treegraph
 
Reported: 2017-01-12 11:55 UTC by ManuMolero
Modified: 2024-03-12 15:37 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
sample (8.69 KB, application/vnd.oasis.opendocument.graphics)
2017-08-31 08:13 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ManuMolero 2017-01-12 11:55:10 UTC
Description:
I use hiperlinks inside the document to detail things in a block diagram but if you insert a new page and you do not select the last one, or you duplicate some page, all your links does not reorganize so they do not go to the selected page before. It goes to other one so it is a dissaster and generate a very hard problem to correct with all the hiperlynks of the draw. 
It only works if the new page is inserted at the end of the page list but if you want a new page is inserted in the middle of the pages or you want to duplicate one the failure appears.
It would be desiderable that the libreoffice draw pages could be renamed or could have some "logical name"

Steps to Reproduce:
1.Insert 4 pages in a document. Insert some symbol on each page that allows you to identify each one. 
2.Create a hyperlink button in page 1 that links to page 3. Disable edition mode and push the button in page one. It goes to page 3... Nice. Reenable edition mode.
3. Duplicate page 2. And then disable editor mode and push the button in page 1 

Actual Results:  
It goes to page 3 but now is not the page 3 that you have selected in the hyperlink before is the new page 3 that has been generated when you duplicate page 2.

Expected Results:
It should go to the hyperlink you have selected before making page duplication


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Comment 1 Xisco Faulí 2017-01-12 11:59:12 UTC
Hello Manu,

Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Comment 2 QA Administrators 2017-07-27 12:06:32 UTC Comment hidden (obsolete)
Comment 3 QA Administrators 2017-08-30 19:31:54 UTC Comment hidden (obsolete)
Comment 4 Yousuf Philips (jay) (retired) 2017-08-31 08:13:03 UTC
Created attachment 135897 [details]
sample

Steps:
1. Open attached document
2. Click the 'Jump to Page 3' button on page 1
3. It has jumped to page 3, which has the name 'Slide 3'
4. Select page 2
5. Insert > Duplicate page
6. Notice now that the page previously named 'Slide 3' was renamed 'Slide 4' and clicking the 'Jump to Page 3' button on page 1 no longer lands where it previously did.
Comment 5 Yousuf Philips (jay) (retired) 2017-08-31 08:18:30 UTC
So it seems that when a page is auto titled as 'Slide X', inserting or duplicating a slide renumbers all the pages, which results in this incorrect behaviour, but if a page is named/titled by the user, this behaviour doesnt happen.

Heiko, Stuart, Cor, Regina: What is your take?
Comment 6 Regina Henschel 2017-08-31 08:47:58 UTC
For links in text form the URL is adapted, but not for links as button.

I would say it is a principle problem in Draw/Impress, that the page names are adapted automatically. Long time ago Calc has a similar problem. Then sheet naming in Calc was changed to strictly divide the internal numbering from the sheet name.

I think, it is a bug. Draw/Impress should adapt the reference in all places or use a model with fix page names.
Comment 7 Heiko Tietze 2017-08-31 11:46:16 UTC
Clearly a bug to me when the reference is a particular page id/number and not a page name.
Comment 8 Regina Henschel 2017-08-31 11:57:48 UTC
And worse: If you open the file in a different UI language no link works, because then the target "Slide #3" does not exist at all, in a German UI it is "Folie #3". So a text link also fails.
Comment 9 QA Administrators 2018-09-01 02:41:27 UTC Comment hidden (obsolete)
Comment 10 Regina Henschel 2018-09-01 11:48:03 UTC
The bug still exists in Version: 6.2.0.0.alpha0+ (x64)
Build ID: 57bf6e93e65124cd7988373d8c06a81910397e10
CPU threads: 8; OS: Windows 10.0; UI render: GL; 
Locale: en-US (en_US); Calc: CL
Comment 11 QA Administrators 2019-09-02 09:23:18 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2021-09-02 03:51:39 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2023-09-03 03:15:55 UTC Comment hidden (obsolete)
Comment 14 Stéphane Guillou (stragu) 2024-03-11 12:02:11 UTC Comment hidden (obsolete)
Comment 15 Stéphane Guillou (stragu) 2024-03-12 08:10:43 UTC
In recent trunk build, sample file's button has to link to "#Page 3" instead of "#Slide 3" to test. Still reproducible in recent trunk build:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: f42363c51672a5b3685b0b9b11e932680530dce3
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

Giving a name to a slide also does not update an existing link. However, once it has a custom name, and the hyperlink points correctly to it, a change in position will update the link.

(In reply to Regina Henschel from comment #8)
> And worse: If you open the file in a different UI language no link works,
> because then the target "Slide #3" does not exist at all, in a German UI it
> is "Folie #3". So a text link also fails.
So we've identified 3 examples of when the link should update but doesn't:
- default name + position changes;
- default name + UI language changes;
- change in custom name.
I've changed the summary accordingly.

Impress behaves the same. Same with image button. Same in OOo 3.3 -> inherited.
And it is inconsistent with how hyperlinked text _used_ to behave (see below).

Very much related to bug 139472, but not marking as duplicates as I'm not sure the same path is used for text links and form controls. Relevant wisdom in bug 139472 comment 4.

--------- Related:

(In reply to Regina Henschel from comment #6)
> For links in text form the URL is adapted, but not for links as button.
Indeed: Testing Draw with a hyperlink in a text box, results were different _until the change from "slide" to "page" in LO 6.4_. OOo 3.3 to LO 6.3 worked as expected when deleting an intermediate page.

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 1fd359790ed4a27902248d92ee343a4aeaf63c8e
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

Impress continues to behaves as expected, updates the link when a slide is deleted.
I've reported this Draw-only regression in bug 160162.