Scenario: A multi-page Writer all-text doc with 2 normal-view (not Web view) windows open on same doc. Label the windows MAIN and REFERENCE where active editing is in MAIN and REFERENCE is positioned 1 or 2 pages later in the doc such that there is no content overlap between the windows. Between MAIN and REFERENCE in the doc there are no manual or Styles-associated forced page breaks that potentially could buffer text flow. Editing in MAIN which changes text length in MAIN propagates by text flow to what is displayed in REFERENCE as expected. IFF (If & only If) *both* MAIN and REFERENCE page windows are *wider* than the WYSIWYG doc page, meaning the right hand scroll bar or properties sidebar is not visually overlapping the right side of the WYSIWYG doc page, then for each character typed (inserted) or deleted in MAIN: A) The MAIN WYSIWYG doc page does a sideways right jump and then a left return and Writer mis-places or looses track of the horizontal position of the cursor is as if both cursor and text jump right but only the text then returns left. For subsequent character inserts characters are inserted as expected from where the cursor was initially placed but the displayed cursor maintains a 7-character right offset in the lengthening text. Delete or backspace works as expected where the cursor was initially placed but the cursor maintains the same right offset, so things become confusing very quickly. B) For each character insertion or deletion or even mouse click in MAIN, REFERENCE flashes an otherwise absent horizontal scroll bar at the bottom of its page window.
WORKAROUND 1: Reduce the LO application window width of either MAIN or REFERENCE or both such that the right scroll bar or right properties sidebar overlaps the WYSIWYG doc page and the right jumping of the doc page in MAIN stops. A key is that this forces appearance of the horizontal scroll bar if enabled for the window. WORKAROUND 2: Disable horizontal scroll bar in *either* MAIN or REFERENCE or both via VIEW->Scrollbars->Horizontal scrollbar. LO application window width of both MAIN and REFERENCE becomes a don't care. LO Version: 5.2.3.3 (x64) Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Locale: en-US (en_US); Calc: group Windows 10 Pro x64 in Intel.
Tried it, made sure there is no horizontal scrollbar. Could not reproduce the weirdness. Would be interesting to see a video: https://obsproject.com/ Win 10 Version: 5.2.4.2 (x64) Build ID: 3d5603e1122f0f102b62521720ab13a38a4e0eb0 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Locale: fi-FI (fi_FI); Calc: group Arch Linux 64-bit, KDE Plasma 5 Version: 5.4.0.0.alpha0+ Build ID: 57779b5f3a49fedd952aed70ddcce22f48b98ea5 CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on January 13th 2016
OB Studio has a multitude of settings. Request settings advice for best screen capture video for diagnostic purposes of LO application windows, ideally of just the LO app windows and not entire display(s). There will be 2 LO app windows involved to show reported effects. Currently running 2 displays of 1920x1080. Then, I cannot imagine the video file will be small. Submit via bugs.documentfoundation.org ?
(In reply to R. Bingham from comment #3) > Currently running 2 displays of 1920x1080. Aha, so the problem is with 2 displays? Do you see the problem on a single display with 2 windows?
Attempting various setups for video capture and variations on dual LOwriter window situation across one or two displays. Prepared a clean LOwriter doc of Lorum ipsum and could not exactly reproduce what I had seen earlier with a private working doc. However, I can reproduce functionally equivalent behavior under slightly different conditions. Reported bug was with a private doc and one window each display with both windows set for LO 120% view. With fresh Lorum ipsum doc the horizontal jitter and cursor misplacement behavior reported only becomes severe when MAIN (editing) LO windows is at 75% while REFERENCE still at 120%. Acquired OB Studio and after much fiddling and poking achieved video cap of both displays simultaneously. However, I now know I will need video editing software to cut down the result even and add on-screen notes for each trial variation. However video cap also complicates showing the dynamic behavior: the machine load from recording and stream-scaling video cap at 30 fps changes the relatively 'smooth' horizontal jitter into something more like irregular video driver jags. Will post video cap when I have it.
(In reply to R. Bingham from comment #5) > Acquired OB Studio and after much fiddling and poking achieved video cap of > both displays simultaneously. However, I now know I will need video editing > software to cut down the result even and add on-screen notes for each trial > variation. Ok, OpenShot is one video editing soft you could try. Direct download of installer: http://github.com/OpenShot/openshot-qt/releases/download/v2.2.0/OpenShot-v2.2.0-x86_64.exe Website: http://www.openshot.org/ I haven't tried it myself, but it should be pretty simple.
FYI: Still working the video. Have been through 5 open source video editors attempting one that A) has basic features for title card & freeze frame, and B) does not crash long enough to get something complete. Filed bugs on many of them. Going down rev on Openshot may get me there.
LO updated from first report: LO Writer Version: 5.2.5.1 (x64) Build ID: 0312e1a284a7d50ca85a365c316c7abbf20a4d22 CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Locale: en-US (en_US); Calc: group Hardware: HP DV7T 7000 Laptop Intel i7 G3 4-core, 16 GB RAM Intel 4000 Graphics NVIDIA GeForce GE 630M (now disabled) 2 x Dell P2414H displays OS: MS Windows 10 Pro x64 v1511 All OS & driver patches current Behavior has changed with LO update from first report. No longer glitchy jumps. Now calm left or right displacement of WYSIWYG page within Writer window. Have .webm about 1 minute 30 secs of dynamic behavior with title cards and everything but it is 15 MB and there is a 10MB attachment size limit. Is there an alternate method for submitting video?
(In reply to R. Bingham from comment #8) > Have .webm about 1 minute 30 secs of dynamic behavior with title cards and > everything but it is 15 MB and there is a 10MB attachment size limit. Is > there an alternate method for submitting video? You can email it to me directly and I can take a look at recompressing it. I have experience with such video editing.
I couldn't reproduce the issue regardless of whether I use a single display/monitor or two. But I'm curious to see the video. Tested with version: 5.3.0.3 Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1 CPU Threads: 8; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; Locale: de-DE (de_DE); Calc: CL Windows 10 Pro x64 (Intel Xeon).
I was hoping for a FTP site associated with this Document Foundation Bugzilla where I could drop the .webm video file. I prefer using standard DF infrastructure if it exists rather emailing to a person. If I must email, my ISP supports up to a 20MB attachment on my end but an attachment >10MB in size is at risk when handled by intermediate email relays beyond my ISP. The screen cap video was captured using Open Broadcast Studio v18 and title cards and other explanatory info edited in using Shotcut v17.02. Export was set for 1280x720 25FPS progressive .webm VP9 with codec dual-pass so not high def nor high-speed & .webm VP9 is fairly compressed anyway. I have cut the title cards time since the video can be halted if anyone wants review the dense info. Basically, I step through a demo of showing two windows on one display and progressively reduce LO magnification settings from 120% to 75% in alternating windows steps to show behavior changes. Currently ~00:01:30 running time at 14.8 MB.
If email is problematic, you can use a file hosting service like http://wikisend.com/
Supporting .webm video available at: http://wikisend.com/download/302034/LO-bug-105271-supporting-video-v2.webm Time to live set for 20 days from 4 Mar 2017. Let me know if longer needed up to wikisend max of 90 days.
Created attachment 131648 [details] Video showing the problem I re-encoded the video with this 2-pass method (executing two commands one after the other: ffmpeg -i LO-bug-105271-supporting-video-v2.webm -c:v libvpx-vp9 -pass 1 -b:v 200K -threads 1 -speed 4 -tile-columns 0 -frame-parallel 0 -g 9999 -aq-mode 0 -an -f webm /dev/null ffmpeg -i LO-bug-105271-supporting-video-v2.webm -c:v libvpx-vp9 -pass 2 -b:v 200K -threads 1 -speed 0 -tile-columns 0 -frame-parallel 0 -auto-alt-ref 1 -lag-in-frames 25 -g 9999 -aq-mode 0 -c:a libopus -b:a 64k -f webm LO-bug-105271-supporting-video-v3.webm Method taken from http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide Best Quality (Slowest) Recommended Settings
> Behavior has changed with LO update from first report. No longer glitchy > jumps. Now calm left or right displacement of WYSIWYG page within Writer > window. Is the new behaviour still reproducible with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Retested with LO Version: 5.4.3.2 (x64) Build ID: 92a7159f7e4af62137622921e809f8546db437e5 CPU threads: 8; OS: Windows 6.19; UI render: default; Locale: en-US (en_US); Calc: group Issue appears resolved. Of course, many changes in the platform: New HW: Intel Xeon m1535 v6. Windows updated twice to version 1709 from v1511, NVIDIA drivers updated many times. Dah, dah, dah. Setting status RESOLVED.
Da, harasho.