summaryrefslogtreecommitdiff
path: root/sw/CppunitTest_sw_ooxmlimport.mk
diff options
context:
space:
mode:
authorMiklos Vajna <vmiklos@collabora.com>2019-02-07 11:06:24 +0100
committerMiklos Vajna <vmiklos@collabora.com>2019-02-07 12:25:07 +0100
commit961ba62df045473e5793d9e103be86eaad8d9575 (patch)
tree4713751f2c803da99928bf7caedd94ee7de02ac5 /sw/CppunitTest_sw_ooxmlimport.mk
parent6673aa3fefad3b64469e3c6457161e09f6c27f5f (diff)
tdf#123032 sw, AddVerticalFrameOffsets: fix shape pos after mouse move
Regression from commit 50223ea6e212b60b7d33839c2753c5601fb50f95 (tdf#98987 sw: add AddVerticalFrameOffsets compat mode, 2016-03-31), the problem was that vertical position of the shape was wrong after mouse move, even if we attempted to take fly frames of the paragraph into account. (Similar situation is when saving and loading the file; which is much easier to test.) Fly frames are created as the text frames is formatted, and then SwTextFrame::CalcBaseOfstForFly() can calculate the vertical offset correctly. But in the "move with mouse" case SwToContentAnchoredObjectPosition::CalcPosition() was invoked by the time the old flys of the text frame were already removed, but the new ones were not yet added. Solve the problem by formatting the text frame from SwAnchoredDrawObject::MakeObjPosAnchoredAtPara() (if any of its validity flags are set to false) -- this is expected to be safe, as the object formatter is invoked by SwLayAction::FormatContent(), i.e. there is no recursive SwFrame::Calc() call here. Change-Id: I95851874e3da3f50f304421537c6743e04bdfc7b Reviewed-on: https://gerrit.libreoffice.org/67490 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
Diffstat (limited to 'sw/CppunitTest_sw_ooxmlimport.mk')
0 files changed, 0 insertions, 0 deletions