Apache OpenOffice (AOO) Bugzilla – Issue 126689
Bizarre font size input filter behavior
Last modified: 2018-10-04 06:45:56 UTC
Tested on a Windows 10 PC, with 16GB of RAM, and an i7-4712MQ processor @ 2.3GHz Open Office Build Info: AOO411m6(Build:9775) - Rev. 1617669 2014-08-13 09:06:54 (Mi, 13 Aug 2014) While testing the class of values that are accepted and rejected by the font size input filter, I noticed some frankly bewildering behavior from the font size box. 1. I attempted to input text into the field. It's accepted, and then deleted and replaced with the previous valid value. I thought to myself "Oh, it deletes invalid input and replaces it with the last valid input. That's good" 2. I attempted to do mathematical operations within the input box, to see how it's behavior would be altered. I expected it to perceive it as invalid input, or to parse and evaluate the expression. What occurred, which I did not expect, was that all operations were filtered from the input, and then all digits were appended together and treated as one number. for example, 10*5 is interpreted as 105, rather than 50, or simply being rejected. Further experimentation shows that all non-numeric input, except for one decimal point, is filtered from the input before it's interpreted. 3. I tried one last type of input that I hadn't yet; negative values. When given any negative values, rather than filtering the negative sign as expected, and as it did in example #2, it interprets the given value, AS A NEGATIVE NUMBER, and then restricts it to the minimum font size of 2. This bug report exists to suggest that a single, simple, and intuitive manner be adopted for handling all input into the font size field, and other fields that exhibit this behavior throughout the program, because as it stands, they appear to have far too many different ways of handling input for something as simple as a numeric input field. I would propose a simple call to parseFloat, and if it fails, leave the value as the last valid one, else, make it positive and set it, as opposed to whatever complicated chain of checks and filtering is occurring now.
Created attachment 85323 [details] Test case for text '8k' in Font size
Created attachment 85324 [details] Test Case result for entering '8k' as font size
Configuration used for Reproducing the bug: Windows 10 64-bit, Apache Open Office Writer Build AOO420m1(Build:9800) - Rev. 1692551 Rev.1692551 In addition to what the original report mentions, I tried entering an Alphanumeric entry for the font size, (screenshots for which are attached to this comment) namely '8k', and the Program rightly truncated the text so as to only accept '8'. On the other hand, when I entered an entry in the field such that it starts with a number and ends with a number, BUT has a character in between, it rightly truncates the string again, so as to include only the numerical-portion, e.g for '8k9', '89' is entered as the font size, and rightly so, as the user's accidental keystrokes may get ignored by the program. When a float number with a large significant value is entered into the font size field, it simply rounds it off. Similar to issue #4279(https://bz.apache.org/ooo/show_bug.cgi?id=4279), if You enter a percentage value in the field, Writer simply removes the '%' and enters 100pts as the font size. This makes it clear that the font size filter only accepts absolute values. Also, in my follow-up tests I noticed that Writer does an unexpected rounding-off when a float number is entered. E.g: When '25.3' is entered in the font size filter, it is reduced to '25.2', the same is seen for some other values like '25.8' getting reduced to '25.7'. What makes this all the more unusual is the fact that it is observed only for certain values in the 10^-1 decimal place, for instance in this case at (3 * 10^-1) and for (8 * 10^-1).
Replicated this bug on a Windows 10 PC. After reading this report, it seems like the author explains only one error which is when the user inputs mathematical operations in the font size input field, it inputs the incorrect value. An example is 5*10 inputs 105. I did some follow up tests and found out when the user inputs some floating point numbers such as 28.9 the field automatically changes it to 28.8. This only happens with some floating point numbers and not all of them. The impact that this bug produces for the users is very low in my opinion. As not many users will try to input 5*2 instead of just 10.
Marking this confirmed based on the tests by Ayush and Malhabsi2013.
I think this is the normal behavior of OpenOffice. I prefer the Microsoft approach (you get a message box, "this is not a valid number") but this class of issue has appeared in OOo bug reports for years and years and has been rejected routinely. The OOo team has to decide what its design rules are (or, actually, I think they have decided) and deal with this report in a manner consistent with that decision.
I would accept this as a bug. The decimal number change is at least suspicious. I will try and look into this.
(In reply to Peter from comment #7) > I would accept this as a bug. > The decimal number change is at least suspicious. I will try and look into > this. Peter were you ever able to follow up on this?
Actually I forgot about this. :(