https://bz.apache.org/ooo/show_bug.cgi?id=126689
Issue ID: 126689
Issue Type: DEFECT
Summary: Bizarre font size input filter behavior
Product: Writer
Version: 4.1.1
Hardware: PC
OS: Windows 10
Status: UNCONFIRMED
Severity: Minor
Priority: P5 (lowest)
Component: formatting
Assignee: [email protected]
Reporter: [email protected]
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.
--
You are receiving this mail because:
You are the assignee for the issue.
