The rename command was split 6 years ago for bug 84258 into RenamePage and RenameSlide. I don't get "Rename Slide" in Draw but "Rename Page" (and Slide in case of Impress).

Please try again with a clean user profile (Help > Restart in Safe Mode > Continue in Safe Mode).

I tried a new profile. The same behavior. 

This also occurs with LO 7.2.6. With a new profile too.

I am unable to reproduce your issue with either:

Version: 7.3.1.3 (x64) / LibreOffice Community
Build ID: a69ca51ded25f3eefd52d7bf9a5fad8c90b87951
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: default; VCL: win
Locale: es-ES (en_IE); UI: en-US
Calc: threaded

or

Version: 7.2.6.2 (x64) / LibreOffice Community
Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Locale: en-IE (en_IE); UI: en-GB
Calc: CL

Did you follow Heiko's recommendation to use "Help > Restart in Safe Mode > Continue in Safe Mode"?

(In reply to Dave Barton from comment #3)


> Did you follow Heiko's recommendation to use "Help > Restart in Safe Mode >
> Continue in Safe Mode"?

Yes, I did. 

This also occurs with LO 7.0.4 in Debian.

Version: 7.0.4.2
Build ID: 00(Build:2)
CPU threads: 2; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: en-US
Debian package version: 1:7.0.4-4+deb11u1
Calc: threaded

Did you do exactly the steps in comment 1?

(In reply to lol from comment #4)

> Did you do exactly the steps in comment 1?

Yes it appears to be an error in the procedure/function called from the main menu "Page -> Rename Page" option.

Confirmed as a bug in 7.3.1.3, 7.2.6.2 and:
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 6adabd915d931b845fcf2fef15fbf3fca14ec9b3
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Locale: en-IE (en_IE); UI: en-GB
Calc: CL

This seems to be a definite bug, but I will test for both rpm & deb installations.

Have now tested on deb & rpm installs of TDF provided editions of 7.3.13 and can definitely confirm this bug.

Obvious typo: 7.3.13 should read 7.3.1.3

(In reply to Dave Barton from comment #6)
> Have now tested on deb & rpm installs of TDF provided editions of 7.3.13 and
> can definitely confirm this bug.

Of unclear origin. Draw and Impress should use Slide and Pages, thus not a matter of UX.

(In reply to Dave Barton from comment #5)

> Yes it appears to be an error in the procedure/function called from the main
> menu "Page -> Rename Page" option.

Maybe I find the reason why you couldn't reproduce the bug at first. Did you clicked first on the page in the page pane? See the different steps.

Steps:

1. Open Draw
2. Open the dialog via Page - Rename Page...
3. Dialog appears with the title "Rename Slide"

Steps:

1. Open Draw
1a. Click on the page in the Page Pane
2. Open the dialog via Page - Rename Page...
3. Dialog appears with the title "Rename Page"

If the focus is on the page in the page pane the dialog has a another title.

Created attachment 179115 [details]
Screencast

Both, the context menu as well as the main menu run the same command and show the rename dialog with page not slide.

(In reply to Heiko Tietze from comment #10)
> Created attachment 179115 [details]
> Screencast
> 
> Both, the context menu as well as the main menu run the same command and
> show the rename dialog with page not slide.

It apparently depends on the order.. If you use the menubar Page -> Rename it will show 'Rename Slide' 

If you use the context menu first, also Page -> Rename will we called "Rename Page"

Also in
Version: 6.1.6.3
Build ID: 5896ab1714085361c45cf540f76f60673dd96a72
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL

(In reply to Telesto from comment #11)
> It apparently depends on the order.. If you use the menubar Page -> Rename
> it will show 'Rename Slide' 

True, running the command from the main menu returns Slide until it is started from the page sorter pane - then it will be Page as well on the main menu.

Gabor, you implemented this for bug 107183. Any idea how to solve this? Apparently pDrView->GetDoc().GetDocumentType() == DocumentType::Draw is false as long no Draw specific action has been done.

Dear lol,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug