When viewing a presentation from a ODP or PPTX file, the thumbnail in the Start Center (which usually shows the first slide/page) is updated to an image of the last slide viewed.
This does not make any sense for two reasons: 1) the first slide/page usually has the title of the presentation and it can be used for quick identification; 2) the presentation will not resume at the last viewed slide by default (and as far is I know there is no way to resume; it could be a new nice feature if it doesn't exist)
How to reproduce:
1) Open a ODP or PPTX file
2) Click on any slide from the Slide Pane
3) Close the presentation (File > Close or any other way)
This is a regression from branch 4.2 where closing the presentation at any point will not change the thumbnail.
This bug only applies to ODP and PPTX presentations. It does not apply to PPT files.
NOTE: This also occurs if in step 2 you switch to Slide Show (F5 or Shift+F5)and move forward(or backward) any number of slides and then press Esc to exit
In branch 4.2 there were no thumbnails for PPTX so the bug is only a Regression for ODP files
Win 7 Pro 64-bit Version: 126.96.36.199.alpha1+
Build ID: b3de73f32af6276a60f5678861c461631a75e743
TinderBox: Win-x86@39, Branch:master, Time: 2015-09-01_06:18:16
Locale: en-US (fi_FI)
(In reply to Pedro from comment #0)
> This is a regression from branch 4.2 where closing the presentation at any
> point will not change the thumbnail.
That's not exactly a regression, because even in 4.2 if you save the presentation, the thumbnail will be updated with the currently visible slide (and that's the behavior all the way back to, at least, OOo 2.0). It's now just a bit more visible, because since 4.3 we store the thumbnail also in the user profile (to support formats other than ODF), and this thumbnail is updated at file close, if the presentation wasn't modified.
Adding keyword 'bibisectRequest'.
(In reply to Xisco Faulí from comment #4)
> Adding keyword 'bibisectRequest'.
No need to bibisect. The problem is precisely described in comment 3, i.e. the change in 4.3 caused by generating thumbnail on file close to store in user's profile, which was made in Bug 72469.
then, I'll add 'bisected' as the commit is identified.
Probably it's good if UX team takes a look at it and decides what to do with it.
Just adding the UX mailing list.
This user profile thumbnail set to last page viewed before closing or saving affects both--Impress and Draw. Writer and Calc are not affected.
Think one way to resolve this would be an option to always open to the first slide/page (for Draw) and cache that image--so that optionally on closing the image of the first slide/page (for Draw) could be written to user profile and shown on thumbnail view.
Otherwise this is not a regression--it did not exist until we added thumbnail views to startcenter at 4.2--and later provided thumbnails for non-ODF formats at 4.3.
Note that a preview thumbnail is not recorded into the ODF document(s)until they are saved--but the thumbnail of last viewed slide/page for ODF or other documents are written to the user profile when the document is closed. Caching the 1st page (or opening page) could be an option--just for writing to the user profile copy of the thumbnail view.
(In reply to V Stuart Foote from comment #8)
> Think one way to resolve this would be an option to always open to the first
> slide/page (for Draw) and cache that image--so that optionally on closing
> the image of the first slide/page (for Draw) could be written to user
> profile and shown on thumbnail view.
That would be perfect.
Unless a new option to resume on the last slide viewed is added (that would be an interesting new feature but should be optional) then it doesn't make sense to show the thumbnail of the last viewed slide.
> Otherwise this is not a regression--it did not exist until we added
> thumbnail views to startcenter at 4.2--and later provided thumbnails for
> non-ODF formats at 4.3.
Agreed for non-ODF formats. It is an enhancement request for those. But for ODP (and ODG from your comments) is was a regression since in branch 4.2 the thumbnail was the first slide (as expected) and in 4.3 the thumbnail changed to the last viewed slide.
> Note that a preview thumbnail is not recorded into the ODF document(s)until
> they are saved--but the thumbnail of last viewed slide/page for ODF or other
> documents are written to the user profile when the document is closed.
> Caching the 1st page (or opening page) could be an option--just for writing
> to the user profile copy of the thumbnail view.
Yes, that is the ideal solution.
I still don't see the point of having a thumbnail of the last page viewed if the document does not open on that page (for long ODT text documents where that might be useful, the thumbnail IS the first page...)
There seems to be some inconsistency in the thumbnail creation logic.
This issue with the last slide/page viewed used as thumbnail view saved to profile applies to both Impress and Draw.
This same issue hit me today and i believe it should always thumbnail the first slide of the presentation, whether or not it opens to the first slide or the last edited slide. This would also make the behaviour consistent across apps.
Writer has a feature to jump to the last edited point in the document, though it seems i cant find where to enable it :D, but i still believe it thumbnails the first page even when this feature is enabled.
I would believe the same behaviour should go for Draw.
(In reply to Yousuf Philips (jay) from comment #11)
> This same issue hit me today and i believe it should always thumbnail the
> first slide of the presentation, whether or not it opens to the first slide
> or the last edited slide. This would also make the behaviour consistent
> across apps.
> Writer has a feature to jump to the last edited point in the document,
> though it seems i cant find where to enable it :D, but i still believe it
> thumbnails the first page even when this feature is enabled.
You don't need to enable it
> I would believe the same behaviour should go for Draw.
For consistency sake it should always show the first page for all document types
Agreement on the change, so go for it (comment 8 for the proposed solution).
(Would have taken Maxim's argument myself)
QA: Missing the assignment to a META ticket ;-)
(In reply to Heiko Tietze from comment #13)
> Agreement on the change, so go for it (comment 8 for the proposed solution).
What do you mean "go for it"? I'm not a developer :)
This was simply a request for an enhancement. If no developer finds this interesting then it can be closed.
I'm no longer using LibreOffice but I still think this makes sense.
** Please read this message in its entirety before responding **
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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Regression still occurs with version 188.8.131.52