Created attachment 139205 [details] database to demo this bug How to demonstrate: 1) Open the attached database ("Table Control Add Field bug.odb"). 2) Edit the "Categories" form 3) Click on the "Add Field" icon in the Form Design toolbar, (blue with rectangular grid in it). 4) In the "Add field: Table Categories" dialog press and hold the left mouse button on "CategoryID" and while holding the mouse button down, drag this into the darker top bar in the Table control, to the right of the existing ID field and release the mouse button. A field named CategoryID is created to the right of ID. 5) The bug: Again in the "Add field: Table Categories" dialog press and hold the left mouse button, but this time on "CategoryName" and while holding the mouse button down, drag this into the darker top bar in the Table control and to the right of the two other existing fields. Expected results: CategoryID & CategoryName would be added to right of the ID field. Actual result: CategoryID and CategoryID is added (twice). Notice that when you start to drag suddenly the blue highlight around CategoryName goes away and now CategoryID is magically highlighted. Also notice that if you try this again, you might sometimes be able to get what you want. _______________- LO 6.0.0.0 and 5.4.3.2; Debian 9.3; Cinnamon 3.2.7
New WORKAROUND and CLUE as to where exactly this issue is: If at first when you start to drag the mouse, you drag only right or left, that is until you exit the Add field box, then this is your workaround! And with this technique you can insert the correct field into your table control. But if at first you instead drag up or down while in the Add field box (as you head up for the insertion point), then you'll notice that the field selected changes before you leave the dialog box. So there is some other event getting triggered by the mouse drag that should not be.
Have tried this one. Have added the field with "Add Field" in many different ways to the tablecontrol. Couldn't see any buggy behavior here. Tested with: Version: 6.0.0.2 Build-ID: 06b618bb6f431d27fd2def25aa19c833e29b61cd CPU-Threads: 4; BS: Linux 4.4; UI-Render: Standard; VCL: kde4; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
Created attachment 139242 [details] screencast showing issue
No repro with Version: 6.1.0.0.alpha0+ Build ID: dd758f54fa5ea1ecd3d793bcea999d771010ff00 CPU threads: 4; OS: Mac OS X 10.13.2; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group threaded
@Howard, this might be a GTK2 UI-specific bug, as the version you tested was built with the GTK2 UI framework. I guess that the only way to test the above theory would be for someone to compare with a GTK3 build.
I have noticed that in some LO user interfaces elements, hover (over, as in CSS mouse hover) produces a highlighting as elements come under the mouse pointer. Also there is an observed temporary change of focus behavior when this occurs. In other elements this does not occur with a hover. I suspect that the wrong behavior is involved in this control at the moment it is dragged, in other words it's still using hover over & change focus mode, but after being down clicked it should turn that off so the drag does not cause focus motion. Create any database. Open the Tables. Move the mouse around and observe that most things light up when the mouse is over them. But notice that the pull down box to select a component at the top left does not have this behavior. Another example is the Form Navigator when editing a form. The elements do not light up when hovered over. @Alex, >> this might be a GTK2 UI-specific bug, as the version you tested was built with the GTK2 UI framework. Interesting idea. I confirmed that 6.0.0.0.beta2 and 6.0.0.2 downloaded from LO web site both use GTK2. Someday perhaps I might have the ability to dry what you suggest, but have too many fires to fight right now to get into that. But given that we ALL are using GTK2 (at least anyone who is installing from LO download page), then we all should be seeing roughly the same thing. But you know all that lare
No repro with Version: 6.1.0.0.alpha0+ Build ID: 63a1076594534fbe4ccd5bf2eaaf167cbe709c10 Threads CPU : 4; OS : Linux 4.8; UI Render : par défaut; VCL: gtk2; Locale : fr-FR (fr_FR.UTF-8); Calc: group threaded
I tested this on Linux Mint 18.3 Sylvia
@Howard : hoping that this isn't a Debian/Cinnamon specific issue ?
I can't reproduce it in Version: 6.1.0.0.alpha0+ Build ID: 75802ae40ae67737ae9e4f1a38434e0587affff6 CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: en-US (C); Calc: group threaded nor in Version: 6.1.0.0.alpha0+ Build ID: 75802ae40ae67737ae9e4f1a38434e0587affff6 CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk2; Locale: en-US (C); Calc: group threaded on Linux Mint 18.3 Sylvia
Have retested today on newer LO versions: 5.4.6.0 linux 6.0.0.2 linux 6.0.0.1 windows This bug is now gone. Don't know what killed it. But the behavior of the drag is different now. When dragging I now see a circle with a slash when over un-dropable ground, so someone fixed this bug, perhaps in a different component.
(In reply to Howard Johnson from comment #11) > Have retested today on newer LO versions: > > 5.4.6.0 linux > 6.0.0.2 linux > 6.0.0.1 windows > > This bug is now gone. So this has to be set to "Worksforme", not "Fixed", because there wasn't a fix.
When is "WorksForMe" used vs "Fixed"? I would have thought WorksForMe meant, "I tested it, and it works for me"? In this case I'm pretty sure somebody fixed this somewhere in LO, probably as part of an underlying library, and in response to some other bug in calc, or word, etc. Recall that I have a video attached here showing it actually failing for me, and now it works differently with the newer versions. It didn't just start working on it's own I don't think. Thanks Robert.
(In reply to Howard Johnson from comment #13) > When is "WorksForMe" used vs "Fixed"? > > I would have thought WorksForMe meant, "I tested it, and it works for me"? > > In this case I'm pretty sure somebody fixed this somewhere in LO, probably > as part of an underlying library, and in response to some other bug in calc, > or word, etc. > > Recall that I have a video attached here showing it actually failing for me, > and now it works differently with the newer versions. It didn't just start > working on it's own I don't think. > > Thanks Robert. Hi Robert, we use FIXED when we know the commit fixing the issue, otherwise we use WORKSFORME, which means, the bug was present in previous versions but it got fixed in newer versions, although we don't know which fixed it. see https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/RESOLVED#WORKSFORME