Issue 116412 - view jumps when copying slides
Summary: view jumps when copying slides
Status: CLOSED FIXED
Alias: None
Product: Impress
Classification: Application
Component: code (show other issues)
Version: DEV300m95
Hardware: Unknown All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: groucho266
QA Contact: issues@graphics
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-11 17:35 UTC by richlv
Modified: 2017-05-20 10:34 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description richlv 2011-01-11 17:35:52 UTC
in a document with enough slides to have a scrollbar in the slide pane, select 
first slide, then, holding down ctrl, last one. press ctrl+c to copy them - 
view jumps to the top of the slide pane. should not happen.
Comment 1 aleetesting 2011-02-19 15:12:10 UTC
(Aleksander Lipski, 19/01/2011) I have confirmed this behavior on DEV300m99. 
Here is an alternative set of replication steps:

Steps
1. Start Impress with "Empty presentation".
2. Add slides to the slides pane (left side) in order have scrollbar visible so 
there is no possibility to see 1st and last slides on the same view.
3. Select 1st slide.
4. Scroll down to the end of the slides pane and select last slide with pressed 
CTRL key (both slides should be selected)
5. Copy selected slides by using CTRL+C shortcut or by clicking "Copy" from 
"Edit" menu.

The selection view jumps after copying the slides from the view of the last 
selected slide to the view of the 1st selected slide.

This behavior is inconsistent with the way that MO PowerPoint and Windows 
Folders handle similar steps. In both cases the selection never changes under 
same circumstances.
This above behavior is also inconsistent with the Impress itself. When the 
scrollbar in step 4 is moved (in either way) after selection of the last slide 
and if then we copy the slides the view is of selection is not jumping.
Comment 2 wolframgarten 2011-02-21 08:54:08 UTC
Reproducible. But for me in DEV300m100 it is the SHIFT key to select all the
slides in between. Reassigned.
Comment 3 richlv 2011-02-22 07:39:23 UTC
oh, sure it's shift - but the report was about selecting only the first & last 
slide, not all of them ;)
Comment 4 groucho266 2011-03-23 13:01:03 UTC
The bug is caused by this chain of events:
1. On pressing Ctrl+C a new transferable object is created.  For this the  selected pages are cloned and stored in the transferable.
2. During the cloning process, the new page objects reference the original model.  Only when all pages have been cloned the temporary model of the transferable is set at the pages.
3. Because the cloned pages reference the original model, any changes to the pages are notified to that model.
4. The slide sorter listens for model changes of the original model and is thus informed of all the changes that are made during the cloning.
5. The changes to the new page objects are interpreted by the slide sorter as changes to the original model.  It can not know that the changes are temporary and irrelevant.
6. As one response to the perceived model change the selection is moved into the visible area.  There is an exception to this response: when the scroll bar was moved recently then the visible area is not modified.
7. The selection does not fit into the visible area (the selection was explicitly constructed this way).
8. When the selection does not fit into the visible area then the top/left part of it is made visible.

The root cause is that the newly created page objects temporarily referencing the original model.  Everything else goes as expected.

Possible ways to fix this:
a) Create the new page objects with the right model.  This is a change that has to be made to several classes in the page class hierarchy.  The modified behavior may break existing functionality.
b) Temporarily ignore model change events.
c) Temporarily mark the scroll bar as positioned by the user and thus prevent its automatic positioning as response to model changes.

b) and c) are workaround but will less likely introduce regressions.
Comment 5 groucho266 2011-03-23 14:49:42 UTC
Opted for solution c).  It poses the smallest risk for producing a regression and has the right semantics: user moved the scroll bar, directly or indirectly by e.g. key presses, and does not want it changed.