[upstream] Creating a new slide by double click not working correctly

Description:
Version: 6.1.3.2
Build-ID: libreoffice-6.1.3.2-snap1

You can create new slides in impress by double clicking on the empty part of the slides pane (below the existing slide). However, this works only as expected while the slides pane actually has empty space at the bottom.

As soon as I have created a few slides, the slides pane is completely filled, and two things happen:

(1) Improvement: It is very hard to double click on the thin white space at the bottom of the filled slides pane. This could be improved by always letting a few pixels at the bottom to click on.

(2) Bug: You can actually manage to double click there and this creates a new slide. However, this new slide is not filed at the end of slides (as it should) but appears at a strange location somewhere in the middle of slides. This is definitely wrong.

Steps to Reproduce:
1. Create new slides until the slides pane is filled.
2. Observe that there's almost no (just very thin) space at the bottom of slides pane to click at.
3. Try to create another slide by double-clicking on that (very thin) space.

Actual Results:
The new slide is created not at the end of slides, but somewhere in the middle.

Expected Results:
The new slide is created at the end of slides.

Reproducible: Always

User Profile Reset: No

OpenGL enabled: Yes

Additional Info:
Version: 6.1.3.2
Build-ID: libreoffice-6.1.3.2-snap1
CPU-Threads: 4; BS: Linux 4.18; UI-Render: Standard; VCL: gtk3;
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group threaded

Confirmed from my side for

Version: 6.3.0.0.alpha0+
Build ID: e4c2d0bb57ab8ea8f5c400d103d01376b8140f22
CPU threads: 1; OS: Linux 4.14; UI render: default; VCL: kde5;
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-11-30_21:37:10
Locale: ru-RU (ru_RU.UTF-8); UI-Language: en-US
Calc: threaded

Also reproduced in

Version: 4.4.0.0.alpha2+
Build ID: b21df5a993a3815cf736fe3d2eab73eee646b38e

in

Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)

the double click wasn't implemented...

This seems to have begun at the below commit.
Adding Cc: to Andrzej J.R. Hunt ; Could you possibly take a look at this one?
Thanks

Implemented in this commit

bc2d7d4d0ac466a92703f7ba85cf75c19488aa70 is the first bad commit
commit bc2d7d4d0ac466a92703f7ba85cf75c19488aa70
Author: Matthew Francis <email address hidden>
Date: Sat Sep 5 22:43:10 2015 +0800

    source-hash-61a20e43b1ec7641bed073244c988e3ea981f086

    commit 61a20e43b1ec7641bed073244c988e3ea981f086
    Author: Andrzej J.R. Hunt <email address hidden>
    AuthorDate: Sat Oct 26 17:10:52 2013 +0100
    Commit: Caolán McNamara <email address hidden>
    CommitDate: Fri Nov 8 10:25:49 2013 -0600

        SlideSorter: insert new slide on double-click.

        Previously inserting a new slide required using a context menu
        (via right-click) or the main menu-bar. It is now possible
        to insert a blank slide by double-clicking in an empty area
        of the slide sorter.

        Change-Id: Id7ac5f9d3befd02d0a89ad5e1631885c0493ad3d
        Reviewed-on: https://gerrit.libreoffice.org/6442
        Reviewed-by: Caolán McNamara <email address hidden>
        Tested-by: Caolán McNamara <email address hidden>

As for improvement, that's welcome.
As for bug, I don't understand it. To me it looks like new slide is created at the end. Anyway, it's the same as the previous one, so how could you tell the difference.

No, you can easily tell where the new slide is created, simply by tying defferent text into the existing slides (suggestion: Type "1" into slide 1, "2" into slide 2, etc.). If you do so, you will find that as soon as the existing slides fill the side bar, the new slide will be created at an unexpected position.

I just tested it again (Version: 6.3.3.2.0+), and new slides consistently appear at position #8 (although I have more than 10 slides). That's definitiely the wrong place. Try it.

Dear Rüdiger Kupper,

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

This bug is still present in the originally described form in LO 7.2.4.1 Build b8e68b5bf61ce56d972a163ea31a18aecdcd64cd as of Ubuntu 21.10.

Dear Rüdiger Kupper,

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