Summary: | -1 Max length Multiline Input Text Box form controls are no longer editable, and the maximum max length is much less than the textbox has handled in previous versions | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Ray <contact> |
Component: | Base | Assignee: | Matteo Casalin <matteo.casalin> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | contact, dtardon, h3734236, matteo.casalin, raal |
Priority: | medium | Keywords: | bibisected, bisected, regression |
Version: | 5.1.1.3 release | ||
Hardware: | x86-64 (AMD64) | ||
OS: | All | ||
Whiteboard: | target:5.2.0 target:5.1.4 | ||
Crash report or crash signature: | Regression By: |
Description
Ray
2016-03-28 17:56:39 UTC
This seems to have begun at the below commit. Adding Cc: to Matteo Casalin; Could you possibly take a look at this one? Thanks 5bd4464fb6178053009ae5feab788929014c147c is the first bad commit commit 5bd4464fb6178053009ae5feab788929014c147c Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sun Aug 16 05:32:04 2015 -0700 source 98244c3cb47824babc746ebc14a199977e9768d1 source 98244c3cb47824babc746ebc14a199977e9768d1 author Matteo Casalin <matteo.casalin@yahoo.com> 2015-08-15 17:35:32 (GMT) committer Matteo Casalin <matteo.casalin@yahoo.com> 2015-08-16 07:10:21 (GMT) commit 98244c3cb47824babc746ebc14a199977e9768d1 (patch) tree 0077631b678997f61a1fae245e32467bd7afbe00 parent caa828da96b120f5a3c979237081c29f8c2f3848 (diff) sal_uLong to sal_Int32/long I just tried 5.1.2.-3~bpo8+1 from Debian jessie-backports, and the bug is still there. I did notice another wrinkle. While you can't input anything in a field with a maxlength of -1, if you paste something in it (of any length, short or long) it pops up a box that says "The inserted text exceeded the maximum length of this text field. The text was truncated." and it then replaces the pasted text with "!!br0ken!!" in the input field which can then be saved and loaded but not edited. I'll have a look at this as soon as I can, this is almost certainly due to changing from unsigned to signed integer types. I just submitted a possible patch to gerrit. Is there any way to test it? From comment 1 it seems controlled by some script, could it be uploaded with related instructions? (In reply to Matteo Casalin from comment #4) > I just submitted a possible patch to gerrit. > Is there any way to test it? From comment 1 it seems controlled by some > script, could it be uploaded with related instructions? Hello Matteo, comment 1 is result from bibisecting. For test just try to set multiline text box. @Ray, please could you post some printscreens for Matteo? Thank you @raal: I meant the bug description, sorry for the confusion. @Ray: I know nothing about Base, so I need a detailed procedure in order to reproduce the bug and verify the fix. Thanks for fixing the bug, or at least trying to! I really appreciate your time and effort. If there's anything else I can do just ask. I provided some instructions below. DETAILED INSTRUCTIONS TO SEE REGRESSION: Create a new base document. Then click finish right away (don't bother trying to set up a database, we aren't going to try to store anything). Then click forms on the left side, it's between queries and reports. Then click create form in design view (kind of the top middle of the screen). Then click the text box icon and draw a big square text box that is big enough for many lines. Right click the text box, hit "Control..." Then set "Max. text length" to -1, the default "Text type" is multi-line, but if it isn't already multi-line, set it to multi-line. Close the properties window with the x on the top right. Hit the save icon, use the default name which will be Form1 Then hit the x at the top right of the form editor to close the window. Then double click on Form1, which should be about halfway down the left side of the screen toward the middle. Click in the box and try to type. Nothing will happen (This is a bug, it used to take any amount of text, at least up to about 90,000 characters, and probably well beyond that, but I never went further). If the regression is really completely fixed, you should be able to not only edit it, you should be able to paste at least 90k characters worth of text without it truncating anything. If it is accepting input, try pasting in a whole lot of text to make sure that it doesn't truncate at 32767, because it didn't truncate there before in 4.x. For comparison, you can edit form 1 (right click on "Form1" from the main Base screen, it's the same thing you left clicked to open the form) and then set the "Max text length" property to something positive (edit it the same way you did last time), and then save. Then open Form1 again and it will again be editable. This is not part of the bug, it is just a way to compare behavior with different values of Max text length so that you can see what it is supposed to do. Thanks! Thanks Ray, I should be able to perform some debug during the upcoming weekend. Just an update: I tested the patch I wrote and it seems OK to me. I'm waiting for an additional review (just asked the list) and instructions on how to proceed for it to be backported to the 5.1 branch. About your second request, after setting the maximum text length to -1 I was able to paste a 570kB text in the form. Is this what you asked for or was it related to the maximum value that can be used in the control options? Thank you! I reported a regression between 4.x and 5.x. And yes, it sounds like you fixed exactly what I asked for, so that it works as well as 4.x did. I always use a maximum text length of -1 for long fields, so I don't set the max explicitly for anything that is very large. That was a quick turnaround time too. I really appreciate it. That being said, even though it isn't a regression (I just checked, it was broken in 4.x too, and maybe earlier but I didn't check that far back), and I don't need it fixed, and I wasn't complaining about it originally, there is bug with the maximum text length field that has been there for a very long time. If the actual upper limit of maximum text length is > 500k characters, it seems that the maximum text length field ought to be able to go higher than 32767 unless there is some underlying software engineering reason it shouldn't (i.e. maybe the underlying design of the box can't enforce a max text length of > 32767 without major slowdowns, so the user should be forced to just use -1 for those). If there is an engineering reason it can't be higher than 32767 it should automatically snap back to -1 rather than its last value if someone puts in a higher number. Right now it snaps back to whatever it was before, which is what it did in 4.x. If I can give you any more information about this, or anything else, ask. Whether or not you end up fixing the other longstanding max text length box bug, you fixed the regression, and that makes the software usable for me again. I really appreciate your efforts, both on my particular bug and in general. Thanks! From my debugging session I verified that the text form maximum length is set by a function that takes a signed 16-bits integer, whose maximum value is indeed 32767. I honestly can't say if that value can be changed, since it could belong to a stable interface. I'll ask the list, though. What I noticed for sure is that the Maximum Length control may take values above that 32767, and this is something that might be addressed after verifying the upper limit that could be used. Matteo Casalin committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=eca3455190ed9a2c4796e7954f2533dc71cd1ab6 Resolves: tdf#98940 (-1 not mapping to maximum string length anymore) It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. Matteo Casalin committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c927b6692257e427d622add6324fc1c55fce9aa3&h=libreoffice-5-1 Resolves: tdf#98940 (-1 not mapping to maximum string length anymore) It will be available in 5.1.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. |