+++ This bug was initially created as a clone of Bug #44721 +++ When moving a control with the mouse (drag'n drop), the control is actually about 1.25cm *above* the mouse pointer. The control starts at the mouse pointer, but then "jumps up".
Hi Lionel, I don´t understand the intention of this bugreport. Do you expect a confirmation?
(In reply to comment #1) > I don´t understand the intention of this bugreport. Do you expect a > confirmation? The intention is that the bug eventually gets fixed. Not clear by whom yet. It would be useful to see whether other people can reproduce on same OS (GNU/Linux) and/or other OSes (MS Windows, MacOS X), to see if the problem is in platform-specific or platform-generic code.
I have tested the following: Open a report for editing. Mark a control with the mouse. move the control with the mouse from "Detail" to "Group" and back. The cursor look like a hand. It is positioned in the middle of the control. My System: OpenSuSE 11.4, teted with LO-Dev Version 3.6.3.0+ (Build ID: 0c3fcef) LO Version 3.6.1.1 (Build ID: 4db6344) LO 3.3.4 When I have seen the videos at https://bugs.freedesktop.org/show_bug.cgi?id=44721 I don't understand what you mean. There isn't moved a control with the mouse. The mouse is used for changing the width or hight of a control. Could be you mean the cursor "hand", which suddenly appears while changing the width? Haven't seen such a behaviour before.
@Lionel I also don´t understand what you want to say respectively I´m not able to reproduce the single steps respectively the wrong behavior.
Now I have had the same behaviour. I wanted to push a rectangle from the footer of a group to detail. When moving the rectangle the lines, which show this moving, suddenly jump about 1,5 cm above the mouse-cursor. I wanted to insert the rectangle at the position which is shown by the lines - but it has been inserted at the position of the mouse (again in the footer, not in the detail-section). I set the status to New.
Another hint: Same Database-Document - in one report I can reproduce this behaviour in a different way (pasted at the position of the mouse - shown at another position by the lines), in another report I can't reproduce the behaviour (report, which is edited, when choosen "English" as GUI-Language ...).
(In reply to comment #6) > <snip> I can reproduce this behaviour Hi Robert, Lionel needs the specification of OS you used (to clarify which OS is affected). Changed status to "NEEDINFO" (please change again to "NEW" after reply).
@Jochen, see comment 3. I have tested it with OpenSuSE 11.4 32-bit (linux rpm) and three different versions of LO. Behaviour is all the same.
(In reply to comment #8) > I have tested it with OpenSuSE 11.4 32-bit (linux rpm) Can you also test with a windows-OS?
@Lionel: A Bug reported for a 3.6 Version can not be a 3.5 MAB "by definition", so I remove this one from that Tracking bug. Please feel free to add it to an other MAB tracking bug due to <http://wiki.documentfoundation.org/Most_Annoying_Bugs>
Moving this to 3.6 MAB since we are closing 3.5 MAB meta tracker. Personally I think that this is just a minor inconvenience and shouldn't be on MAB. Also a test document with clear steps might help as I'm not seeing the issue (on just a blank database form) but more likely than not I just am just missing a step somewhere. Marking as NORMAL as there is no data loss or anything, just a bit off
Also, how can it block 52471 if that one is fixed?
(In reply to comment #11) > Personally I think that this is just a minor inconvenience and shouldn't be > on MAB. I found it makes designing reports quite cumbersome. It is like a gun that shoots 2m above the crosshairs. It makes it rather difficult to aim. > Also a test document with clear steps might help as I'm not seeing > the issue (on just a blank database form) but more likely than not I just am > just missing a step somewhere. The problem is in *reports* (done with report builder, not report design), not in forms. It is one of these problems "sometimes I have it, sometimes not, I don't understand under which conditions I have it". It has been some time since I worked with reports and thus was in position to encounter this bug, but back in December it made me abandon the mouse and enter X/Y coordinates in the properties instead. I'll try to re-reproduce it in the next weeks.
(In reply to comment #12) > Also, how can it block 52471 if that one is fixed? Bug 52471 is not fixed, it is marked as a duplicate (I'm not sure that is actually correct, but that is another issue). I'm also not sure the "blocks" relationship is correct anyway. Maybe it should rather be in "see also".
@Lionel do you still reproduce the bug on recent LibO releases (4.0.4 or 4.1.0)
(In reply to comment #15) > do you still reproduce the bug on recent LibO releases (4.0.4 or 4.1.0) Yes, I still reproduce with my 4.2.0.alpha development build.
Ok. let's move it to the mab4.0 list.
(This is an automated message.) Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Moving to mab4.1 (Bug 60270) because: - 4.0 reached EOL (End Of Life) - bug confirmed in later version
is this bug still valid in current 4.2.4.2 release? if yes, please move it from mab4.1 to mab 4.2 list since 4.1.x is EOL
I still see it in master and 4.2 on OSX, moving to mab4.2
Can someone who had confirmed this bug bibisect it?
Here's a good way to recreate the issue and a workaround. The issue occurs when sections of the report have a minimum height. Create a report with a few groups with group headings then, in design mode, use the 'Shrink' control to make the group headings and sections as small as possible then attempt to move an object on the screen, the mouse pointer will be significantly offset from the object as you move it and it will jump from section to section due to the misalignment. This should recreate the issue easily. A temporary workaround for folks encountering this issue is to just open the report sections up some and shrink them when you're done.
It would help if you attached a document that gets us as far as possible along the reproducible steps. I suppose at least getting us through: "Create a report with a few groups with group headings then"
please retest with recent 4.3.x or 4.4.x versions. if issue persists, please move it to mab4.3 list since 4.2.x is EOL
TESTING with LO 4.3.5.1 + LO 4.4.0.0.beta2 on Ubuntu 14.04 - Using attachment 64781 [details] (from the parent bug report). (If it opens as read-only, make sure to right-click and select 'Edit') I tried to reproduce these results, but the instructions aren't entirely clear. (In reply to Steven M Campbell from comment #23) > Here's a good way to recreate the issue and a workaround. The issue occurs > when sections of the report have a minimum height. > > Create a report with a few groups with group headings Trying to add group elements to the existing report in the test ODB failed, as they would disappear after walking through the mini-wizard to create one.
(In reply to Lionel Elie Mamane from comment #16) > > do you still reproduce the bug on recent LibO releases (4.0.4 or 4.1.0) > > Yes, I still reproduce with my 4.2.0.alpha development build. Lionel/Alex: We're nearly done porting mab4.2 -> mab4.3. Can one of you confirm that this bug is still present in 4.3, 4.4, or 4.5 so we can bump it forward? Thanks!
Created attachment 110876 [details] Describes the difference between moved control and mouse-position.
Created attachment 110877 [details] Database with report for testing. Open the report for editing. Mark one filed of the report with the mouse. Try to move the field with the mouse. The position of the mouse is under the control. It isn't as much as Lionel described and I could confirm with one report - don't know which. But the behavior is the same in old LO-versions and in LO 4.3.5.2, also the newer LO 4.4 and LO 4.5-Dev. Tested with OpenSUSE 12.3 64bit rpm Linux.
Created attachment 110903 [details] bug demonstration video Yes, reproduced in 4.3.3.2 (Debian build). Here's a screencast (video) to show the problem. You clearly see that although the mouse is moved only horizontally (from left to right), the moved control "jumps" up by 0.75cm vertically.
(In reply to Lionel Elie Mamane from comment #30) > ... the moved control "jumps" up by 0.75cm > vertically. at least is improved from the 1.25 cm of the initial report :-)
I can reproduce this in LO 3.3.0, so it doesn't appear to be a regression but an inherited bug. -> Removing Whiteboard: bibisectRequest and Keywords: regression -> Setting Version to "Inherited from OOo"
Adding self to CC if not already on
Just for the record, on pc Debian x86-64 with master sources updated 2 days ago, I can reproduce this. I wonder who could give some code pointers so someone may start to dig into this one.
Just informing that I accidentally changed the importance to 'enhancement' for a while (I am really sorry, I didn't realize that I was editing the wrong bug). I don't remember the original status, so I'm changing it back to 'normal', just like Joel Madero did, according to Comment 11. Finally, I sincerely offer you my apologies for the troubles this mistake might cause to you.
same behaviour here, my system: LO 5.1, Debian testing amd64, LO is from homepage, not from repos. i have this behaviour since i use LO (about since version 3). its a nuisance, when editing reports to make them look better. resizing with mouse works properly, also resizing and positioning with the context-menu manually by editing x or y values in numbers works properly, only when drag'n'drop per mouse, the object jumps when selcted.
** 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.2.5 or 5.3.0 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-20170306
Bug still exists with LO 5.3.1.1, OpenSUSE 42.1 Leap, 64bit rpm Linux. The difference between moved control and mouse-position disappears when deleting sorting and grouping. When I tried to change the height of the group of https://bugs.documentfoundation.org/attachment.cgi?id=110876 I got a part of the group without background. After saving the report and reopening, the background of the group appears and the buggy behavior with mouse-position and control-position has gone.
** 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
*** Bug 118905 has been marked as a duplicate of this bug. ***
Lowering importance: Highest + Inherit from OOo doesn't make much sense at this point anymore...
(In reply to Xisco Faulí from comment #41) > Lowering importance: Highest + Inherit from OOo doesn't make much sense at > this point anymore... Why doesn't it make much sense anymore? Does anybody want to remove from LO? Report Builder is used with every database-engine connected to Base.
Balding happens to the best of us. You're roaring along in your 20's, living life to the fullest - with a head full of hair, of course. Then you hit 30, and the thickness of your mane starts to decline. According to the https://www.thestyledare.com/2020/06/jensen-ackles-haircuts.html American Hair Loss Association, more than 65 percent of men notice some hair loss by their 35th birthday, even if they're in denial. By the time they turn 50, 85 percent of men are considerably balding. So what's a guy to do? There's no need to panic if you are one of the many men who are balding. Jude Law and Dwayne Johnson, John Travolta and Bruce Willis, Jason Statham and lots of other celebrities prove that older balding men often look sexier and more stylish than younger boys. https://www.thestyledare.com/ Still can't believe it's possible? We've got the best-looking haircuts and hairstyles for balding men, from long hairstyles to short cuts with beards and more. What is the best haircut for balding? Nowadays, this question has lots of solutions from special losing hair products to on-top male hairstyles to cover bald spots. In the pictures below you'll find hairstyles for balding men with thinning hair in front or a bald spot on the crown. Is short hair better for balding? Definitely yes, since any almost bald haircut https://www.thestyledare.com/2020/06/how-to-know-if-you-can-grow-beard.html minimizes most of the risks and looks good no matter how thin your hair is. Such close cut or burr cut is less aggressive than taking a razor to your hairline, but it hides any patchiness. Have a balding crown? No problem. Wear your hair with confidence: just crop it shorter on the sides and a bit longer on top, work some texturizing product into your hair to boost thickness and balance the receding hairline. Also known as men's crop, french crop, or men's fringe, the Caesar cut is perfect for men with thinning hair in the back. You need to create some texture coming down to your face: brush the front hair forward and make sure that it's neither too long nor too short. If your hair lies flat, it may visually seem even https://www.thestyledare.com/2020/04/medium-hairstyles-for-men.html finer, drawing attention to bald spots. So, it's better to cut your hair shorter and make it a bit messy with hair wax. Play with a deep side part and texture hide all bare areas. The crew cut is one of those short sexy haircuts that pairs perfectly with any age. Moreover, this trendy cut works great to hide any bare spots: just keep it a bit longer and spike up. That's why this one is one of the favorites for balding men. For Womens Medium-length hair is the perfect length for anyone who's over 50. No matter your face shape, you can't really go wrong with a cut that falls somewhere between the chin and a few inches below the shoulders. It's super popular, and it never goes out of style. What's more is that it's still long enough to be considered sexy, but not so long that you'll look like you're trying to be 25 again. Finding the perfect shoulder-length cut for you depends on your hair texture, your face shape, and your lifestyle—but when all three are taken into account you can come out with a wonderful https://www.thestyledare.com/2020/05/long-bob-with-bangs.html hairstyle that will make you feel like yourself. The most flattering medium styles include long bobs, shaggy styles, wavy hair, and pin straight cuts. Bangs can take years off a face, and layers can both lighten thick hair and add loads of body to fine hair. There are plenty of ways to go with a medium-length haircut. This haircut works on Diane Keaton because it doesn't compete with her funky wardrobe. It's simple, flattering and no-nonsense. An edgier cut would overwhelm her. It's a perfect example of the haircut fitting a woman's personality. Keep in mind that Keaton always sports some pretty amazing glasses. If you wear glasses, you can use them to play up your style. It's a fashion accessory that not everyone has, so make the most of it and explore your options to find a fit that matches your personal style. As people age, their hair naturally loses https://www.thestyledare.com/2020/04/medium-length-haircuts.html some of its body, which can leave it looking a little...lifeless. To get some volume back in fine, thinning hair, you'll want to have layers cut in, then use a volumizing mousse or spray to style it. Be sure to add product to the roots and at the crown, but never on top of your hair, because that'll only weigh it down. Blow dry it with a diffuser, or even just scrunch it dry to create body. Raquel Welch may have been in her 70s when this photo was taken, but her lustrous, voluminous hair works for any age. Plus, the bright highlights give her a youthful glow she might not have had otherwise.
Dear Lionel Elie Mamane, 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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug