Download it now!
Bug 133158 - LO Writer form controls tab order is broken
Summary: LO Writer form controls tab order is broken
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.0.0.alpha0+
Hardware: All All
: high major
Assignee: Justin L
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 133422 (view as bug list)
Depends on:
Blocks: Form-Controls
  Show dependency treegraph
 
Reported: 2020-05-18 23:57 UTC by peterpqa
Modified: 2020-06-29 15:13 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Bug 133158 attachment - form tab order broken (32.44 KB, application/vnd.oasis.opendocument.text)
2020-05-19 00:02 UTC, peterpqa
Details
Field Name overrides Tab Order (35.04 KB, application/vnd.oasis.opendocument.text)
2020-05-25 18:31 UTC, peterpqa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description peterpqa 2020-05-18 23:57:55 UTC
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
Comment 1 peterpqa 2020-05-19 00:02:03 UTC
Created attachment 160988 [details]
Bug 133158 attachment - form tab order broken
Comment 2 Dieter 2020-05-22 07:08:18 UTC
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?
Comment 3 peterpqa 2020-05-22 15:35:48 UTC
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/
Comment 4 peterpqa 2020-05-22 15:41:38 UTC
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.
Comment 5 Dieter 2020-05-22 15:51:12 UTC
(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?
Comment 6 peterpqa 2020-05-22 16:11:29 UTC
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,
Comment 7 peterpqa 2020-05-22 18:40:12 UTC
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.
Comment 8 peterpqa 2020-05-22 21:28:43 UTC
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.
Comment 9 Dieter 2020-05-24 11:42:05 UTC
(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.
Comment 10 Stang 2020-05-24 19:07:56 UTC
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.
Comment 11 peterpqa 2020-05-24 19:18:22 UTC
Many thanks to Stang (aka Ratslinger). Also, is there anyone on the LO Bugzilla team with a Mac, who can test the problem?
Comment 12 Dieter 2020-05-25 08:15:24 UTC
(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
Comment 13 Alex Thurgood 2020-05-25 15:50:30 UTC
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
Comment 14 peterpqa 2020-05-25 18:30:02 UTC
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?
Comment 15 peterpqa 2020-05-25 18:31:43 UTC
Created attachment 161274 [details]
Field Name overrides Tab Order

Field Name overrides Tab Order
Comment 16 Alex Thurgood 2020-05-26 15:40:37 UTC
(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.
Comment 17 Xisco Faulí 2020-05-29 08:04:02 UTC
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
Comment 18 Xisco Faulí 2020-05-29 08:12:09 UTC
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
Comment 19 Justin L 2020-05-29 10:57:23 UTC
@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.
Comment 20 Xisco Faulí 2020-05-29 11:05:19 UTC
(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 ?
Comment 21 Justin L 2020-05-29 11:51:36 UTC
(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
Comment 22 Justin L 2020-06-03 08:18:32 UTC
(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.
Comment 23 Xisco Faulí 2020-06-03 12:46:38 UTC
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!!
Comment 24 Xisco Faulí 2020-06-29 15:13:30 UTC
*** Bug 133422 has been marked as a duplicate of this bug. ***