Description: I'm on LO Mac 6.4.3.2, macOS 10.15.4 (same problem in recent LO and macOS versions) The attached example Writer form has 207 fields (all named "Field" - see Note 1), Most fields are text boxes, and some are check boxes. All fields have a customized tab order number (see Note 2), left-to-right, row-by-row. Previously (2017? 2018?), LO Writer obeyed my customized tab order. But now, when I open my form, the tab order is random. I discovered a temporary workaround: Form > Design Mode ON, Form > Form Properties..., then click on the last field in each category (making no changes), then Form > Design Mode OFF. After that, during that LO session, tab order will be correct. But after quitting LO and then re-opening the form, the problem returns. The example form was created several years ago. So the problem may involve backward compatibility. A new form created from scratch under 6.3 or 6.4 might not have this problem. (Note 1. In the past, LO permitted field name alphanumeric order override tab order number. So I had to make "Field" the name of every field. Separate bug?) (Note 2. Tab order numbers are by category. That is, Category 1: 7 fields, tab order 101-107, Category 2: 40 fields, tab order 201-240, Category 3: 12 fields, tab order 301-312, etc.) Steps to Reproduce: See Description Actual Results: See Description Expected Results: LibreOffice Writer should have obeyed my custom tab order for form controls. Reproducible: Always User Profile Reset: No Additional Info: See Description
Created attachment 160988 [details] Bug 133158 attachment - form tab order broken
I can't confirm with Version: 7.0.0.0.alpha1+ (x64) Build ID: 4804d969bacd25ad586b3bf70d3dc8c27adb48ef CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: en-GB (de_DE); UI: en-GB Calc: threaded perhaps Mac only?
In the user forums, Ratslinger reported tab order problems in my example on Ubuntu 20.04 with LO v6.4.3.2. So apparently the problem is not Mac-only. See: https://ask.libreoffice.org/en/question/245078/lo-writer-form-controls-tab-order-is-broken/
Also, if you only tab through the first row, the example appears normal. You may not see the problem unless you tab all the way through the example to the end.
(In reply to peterpqa from comment #4) > Also, if you only tab through the first row, the example appears normal. You > may not see the problem unless you tab all the way through the example to > the end. Would be a lot of work to go through 207 fields. So could you please narrow it down, where I can find the wrong order?
It should be fairly quick and easy to just click in row 1 field 1 "ADDRESS OF REQUESTED PROPERTY" and then rapidly tab tab tab through the form. No need to type in any text. The problem starts for me after tabbing out of the last field in row 1. The cursor jumps to row 6 (one field), then row 2 field 1, then row 3 field 10,
I think I found a durable workaround: Open a new text file and set margins to match the example. In the example, select all and copy. Paste into the new file. Tab order in the new file is all correct - except row 1 field 4 (lease months) is now misbehaving. This seems to suggest a backward-compatibility problem. The last time I worked with this form was May or June 2019, so probably v6.2.8.2. No tab order problem back then.
Sorry, I spoke too soon on the copy & paste workaround. It did not fix the tab order problem in my other form. (Unfortunately, it is proprietary and I can't provide a sanitized version.) I downloaded Mac v6.2.8.2, and both forms perform perfectly in that version. Even row 1 field 4.
(In reply to peterpqa from comment #6) > It should be fairly quick and easy to just click in row 1 field 1 "ADDRESS > OF REQUESTED PROPERTY" and then rapidly tab tab tab through the form. No > need to type in any text. > > The problem starts for me after tabbing out of the last field in row 1. The > cursor jumps to row 6 (one field), then row 2 field 1, then row 3 field 10, I can't confirm this. If Ratslinger could confirm the problem in ask.libreoffice.org, perhaps you can ask him to confirm it here in Bugzilla too.
Yes (confirming Ask post), Using Version: 6.4.4.2 Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded on Ubuntu 20.04 Mate and the attached document the Tab (or Enter) sequence is buggy the first time through. On initial opening the sequence, starting in the upper left, will tab through the end of the first line but then jumps to the sixth line (Dependants). Some other erratic behavior until end of document. At end the cursor next returns to start of document (upper left) and works fine throughout. It continues to work correctly starting over whenever wanted until closed. Opening again the problem starts anew. Also, if at first opening if the cursor is placed in lower right (last field) then start, all is OK also.
Many thanks to Stang (aka Ratslinger). Also, is there anyone on the LO Bugzilla team with a Mac, who can test the problem?
(In reply to Stang from comment #10) > Yes (confirming Ask post), Stang, if you're able to onfirm a bug, you're also allowed to change status to NEW. => NEW because of comment 10
Tab order works correctly with Version: 6.2.8.2 Build ID: f82ddfca21ebc1e222a662a32b25c0c9d20169ee Threads CPU : 8; OS : Mac OS X 10.15.4; UI Render : par défaut; VCL: osx; Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded and jumps all over the place with: Version : 6.4.3.2 Build ID : 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8 Threads CPU : 8; OS : Mac OS X 10.15.4; UI Render : par défaut; VCL: osx; Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded ==>> regression
Since you are already looking into this tab-order bug, there is another tab-order problem you might want to address at the same time. In v6.2.8.2, Field Name overrides Tab Order, so I had to name every field as "Field". See the attached "Alpha Name" example. All fields are named "Field" except the highlighted ones. With the current bug, I cannot confirm that this second problem persisted in 6.3 or 6.4. Perhaps in Windows?
Created attachment 161274 [details] Field Name overrides Tab Order Field Name overrides Tab Order
(In reply to peterpqa from comment #15) > Created attachment 161274 [details] > Field Name overrides Tab Order > > Field Name overrides Tab Order Please report this as a separate bug, thanks.
Also reproduced with gen Version: 7.0.0.0.alpha1+ Build ID: 442c7b95e2ee94b66a9854d0cb22f8ecb76532c6 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: x11; Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=5cf057c3365a0feafc8f2e4f4a9e24d69a581999 author Justin Luth <justin_luth@sil.org> 2019-07-06 13:42:12 +0300 committer Justin Luth <justin_luth@sil.org> 2019-07-19 06:14:12 +0200 commit 5cf057c3365a0feafc8f2e4f4a9e24d69a581999 (patch) tree d05cfac73d8175fa99f55a1f8e6ea500f06dbdc8 parent d33cc4f7edc2ce21a9c5a01a7f5e85cfd324c6d9 (diff) tdf#125609 toolkit: don't use XTabController::getControls Bisected with: bibisect-linux64-6.4 Adding Cc: to Justin Luth
@Xisco: I couldn't reproduce this in my Ubuntu. Feel free to revert this change - it isn't needed anymore, but was left in because the previous implementation was also missing stuff. But better to have the problems you know than the problems you don't know, so anyone who can reproduce this (and thus verify that the revert actually does fix the problem) can please go ahead and process the reverts.
(In reply to Justin L from comment #19) > @Xisco: I couldn't reproduce this in my Ubuntu. Feel free to revert this > change - it isn't needed anymore, but was left in because the previous > implementation was also missing stuff. But better to have the problems you > know than the problems you don't know, so anyone who can reproduce this (and > thus verify that the revert actually does fix the problem) can please go > ahead and process the reverts. you tried with SAL_USE_VCLPLUGIN=gen, right ?
(In reply to Xisco Faulí from comment #20) > you tried with SAL_USE_VCLPLUGIN=gen, right ? Ah, no. Ratslinger confirmed above with Ubuntu, so I didn't bother trying that. I can confirm when using SAL_USE_VCLPLUGIN=gen, and also confirm that the revert fixes it. OK - I'll do the reverting work myself. https://gerrit.libreoffice.org/c/core/+/95135
(In reply to Justin L from comment #21) > OK - I'll do the reverting work myself. It turns out that I wasn't smart enough to do the reverting myself, so thanks to Noel Grandin who helped complete the task. The reverting is done and so this should be fixed for LO 6.4.5.
Verified in Version: 7.1.0.0.alpha0+ Build ID: 8d0b7e5b2f6773f4b3feb75f1ac73ea1a26609f7 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Justin, @Noel, thanks for fixing this issue!!
*** Bug 133422 has been marked as a duplicate of this bug. ***