When we enter the scope of a table or a shape's textbox, there is usually a shift in the position of the slide, and slide elements, on the screen. This occurs due to the appearance or disappearance of toolbars, e.g. Table or Text Formatting. Regardless of whether the toolbars should or shouldn't appear - their appearance must _not_ move anything on the screen (and not rescale the slide). Instead, they may occlude the top or bottom part of what's currently visible - with no movement. The movement is jarring and confusing.
*** This bug has been marked as a duplicate of bug 124835 ***
Aside from duplicate, you can avoid the jump by selectively unlocking and undocking the offending contextual toolbar(s). And also worth looking at using the Contextual Single UI MUFFIN user interface in conjunction with the undocked TBs. In turn being reworked for bug 125040 to make the Single Toolbar user interface context sensitive across the UI modes.
(In reply to V Stuart Foote from comment #2) s/across the UI modes/across the LO modules/
This bug is not a dupe, since it is not about the jumpiness of the _UI_. It is strictly about the _content_. I am not requesting that that the contextual UI not appear, or appear differently. The request here is that _when_ it appears, just as it appears now, the position (and scale) of the content on my PC monitor does not change. The other bug does not discuss this at all, it only discusses how to change the UI behavior. This bug does not require any changes to the UI.
(In reply to Eyal Rozenberg from comment #4) > This bug is not a dupe, since it is not about the jumpiness of the _UI_. It > is strictly about the _content_. And that is the "jumpiness" of the UI that folks have complained about with contextual TB since the OOa era. It is exactly a dupe as any solution of bug 124835 would be implemented to *not* shift/alter the VCL canvas in exposing the contextual TBs!
(In reply to V Stuart Foote from comment #5) > (In reply to Eyal Rozenberg from comment #4) > > This bug is not a dupe, since it is not about the jumpiness of the _UI_. It > > is strictly about the _content_. > > And that is the "jumpiness" of the UI that folks have complained about with > contextual TB since the OOa era. Your last sentence directly contradicts mine. I'm ok (well, not, but for the purposes of this bug) with the UI being jumpy. > It is exactly a dupe as any solution of bug > 124835 would be implemented to *not* shift/alter the VCL canvas in exposing > the contextual TBs! The fact that changes proposed on that bug are likely to resolve is not sufficient to make the two bugs duplicates.
Jumping UI means not primarily more or less toolbars but a change of the document position. => duplicate
I was about to agree with Stuart and Heiko here, in that this is a duplicate of bug 124835. (And it is true that the issue you describe is already spelled out in its description.) But it might be worth splitting it, as the canvas does not jump only with toolbars popping up and disappear. A simple example is turning off the rulers (in either Writer or Impress). So if Stuart and Heiko are OK with it, please go ahead and de-dup/re-dup what you think fits into the two topics: - _Document canvas_ jumping because of change in surrounding UI (rulers, toolbars, etc.) (bugs 125816 and 149282 and this one) - Overall UI jumping because of contextual toolbars specifically (bug 124835). But please make sure to clarify the summaries enough to really distinguish them. Thank you.
(In reply to Stéphane Guillou (stragu) from comment #8) > But it might be worth splitting it, as the canvas does not jump only with > toolbars popping up and disappear. > A simple example is turning off the rulers (in either Writer or Impress). And another case is if someone writes an extension which affects the UI in some situations, enlarging or reducing the area used by the canvas. The LO code should take care to keep the canvas stabilized.