OOo bug report: https://issues.apache.org/ooo/show_bug.cgi?id=92060 It would be nice to have this one fixed for LibreOffice.
Created attachment 54579 [details] bug
See attached Video.
Thanks for bugreport Reproducible in 3.5.2 only on Windows (used 7 32 bit) Steps to reproduce: 0. Start Writer 1. Press Ctrl (and not release) 2. Scroll mouse wheel Expected: page rule (on top of document, where page margins, paragraph indents, tabstops shown) placed in correct place Actually: page moves in one direction and ruler in another and remains there. On Windows: after releasing Ctrl ruler placed in correct place On Linux: ruler placed in correct place automatically
Is someone working on this issue?
All platforms are affected.
Is someone able to fix this?
** 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 on a currently supported version of LibreOffice (4.4.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
Bug is still present in... Version: 4.4.1.2 Build-ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 Gebietsschema: de_DE
** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
I still see the bug with build 5.2.1.2. (Tested OS: Linux)
I'm rather sure that this bug has been introduced with the centered page view in OpenOffice.org.
Hello OfficeUser, Have you checked that this bug is already reproducible in Libreoffice 3.3?
** 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! Warm Regards, QA Team MassPing-UntouchedBug
Still reproducible with: Version: 6.0.3.2 Build-ID: 8f48d515416608e3a835360314dac7e47fd0b821 CPU-Threads: 8; BS: Linux 4.4; UI-Render: Standard; VCL: gtk2; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
(In reply to Xisco Faulí from comment #12) > Have you checked that this bug is already reproducible in Libreoffice 3.3? It is indeed.
Pro forma.. still reproducible Version: 6.2.0.0.alpha1+ Build ID: 6896f39ffd8a6c4b32b8f601a6a93678247456bd CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-11-05_22:40:18 Locale: nl-NL (nl_NL); Calc: CL
Dear OfficeUser, 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 https://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! Warm Regards, QA Team MassPing-UntouchedBug
Still in LO Version: 7.3.0.0.alpha0+ (4450137924eb8626a57283e1ab4f4ad62dd2d595) / Windows.
Still reproduce this in: Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Still an issue on: Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded - - - 1. Hold CTRL. 2. Scroll mouse-wheel DOWN or UP. - Zooms document in or out. 3. Let go of CTRL. Ruler now jerks into correct place. - - - If might feel a little better if ruler: - updated every zoom level (Step 2) instead of waiting for you to: - release the CTRL button (Step 3). (I just tested latest Word 365 (Version 2401, Build 17231.20236), and Step 2 is the way it works too.) (Seems like Sasha in comment 3 says Linux works this way too, but not Windows?) - - - Side Note: Now that I recently upgraded to a 4K monitor, I'm zooming in+out more often. And this is one of those tiny little visual bugs that, to me, just *feels* like a "lack of polish".
Added regression keyword because this behaviour has been introduced with multi-page view in Writer
Hossein, could this be an interesting easyHack? Some pointers from Oliver Specht back in 2010, from https://bz.apache.org/ooo/show_bug.cgi?id=92060#c10: ---- gang65: IIRC the first step is the setting of the zoom value. Called in sw/source/ui/uiview/viewport.cxx The second step is the update of the position values of the rulers(left/right margins, indents, tabs etc.). This is asynchronously called. Once the status of these values is invalidated - at the time of the zoom change - the framework calls the status update method - in SwView::StateTabWin() in sw/source/ui/uiview/viewtab.cxx and then transports the new status to the ruler in svx/source/dialog/svxruler.cxx in the methods SvxRuler::Update...( ... ) >This bug only appears when the whole ruler is visible. This is because of the way the page is moved in the window. If the full page is visible and the zoom is increased then the left margin moves to the left while the ruler zoom change moves the ruler to the right. At higher zoom levels the left page margin moves to the right like the ruler does.
Affects both <Ctl>+<mouseWheel> zoom, and the <Ctrl>+<Shift>+<PgUp | PgDn> stepped zoom as implemented for bug 45705 Calculation and positioning of the menu bar is done after document canvas zoom completes. Seems timer based (following pause in zoom step) in that multiple zoom steps can be made, and at pause the horizontal ruler will recalculate and reposition. Would there be a performance impact, or visual lag, to recalculate ruler scale and placement with each zoom step?
Created attachment 192873 [details] ONLYOFFICE_ruler.webm
> Would there be a performance impact, or visual lag, to recalculate ruler scale and placement with each zoom step? This is what other ("polished") office software does while maintaining good performance. I have attached "ONLYOFFICE_ruler.webm".
(In reply to V Stuart Foote from comment #23) > ... > Calculation and positioning of the menu bar is done ... s/menu bar/ruler bar/