Bug 84877 - In JPEG export, fields coerced to valid values so quickly that it interferes with entry
Summary: In JPEG export, fields coerced to valid values so quickly that it interferes ...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
(earliest affected) release
Hardware: All All
: low trivial
Assignee: Not Assigned
Depends on:
Blocks: Graphics-Export
  Show dependency treegraph
Reported: 2014-10-10 16:44 UTC by Luke.A.Somers
Modified: 2019-04-20 16:58 UTC (History)
0 users

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description Luke.A.Somers 2014-10-10 16:44:39 UTC
Problem description: The coercion of numbers to valid values in the JPEG export form is so quick that it interferes with entering the desired (valid) numbers.

Steps to reproduce:
1. export a drawing as JPEG
2. set the value in this field to 8.5 if it isn't already
3. put the insertion point to the left of the decimal
4. press backspace, then 4 

Current behavior:
the field passes through these states:

Expected behavior:
the field passed through these states:
(note the factor of 9 difference)

Steps to reproduce another example:
5. Put 37 into the pixels/cm field if it isn't already
6. put the insertion point to the right of this number
7. Press backspace twice and then 50

Current behavior:
the field passes through these states:
Expected behavior:
the field passes through these states:

(note the factor of 7 difference)
Comment 1 Luke.A.Somers 2014-10-10 16:46:58 UTC
Better yet, instead of entering 50 in step 7, enter 100.

The resulting value is 999 (truncated from 3100) instead of 100.
Comment 2 A (Andy) 2014-10-25 14:24:14 UTC
Strange/Buggy behaviour is reproducible with LO (Win 8.1)

Note: In step 2 the field WIDTH of the JPG OPTIONS dialogue box is mentioned, which is opened after FILE -> EXPORT -> selection of jpg -> pressing the SAVE button.
Comment 3 QA Administrators 2015-12-20 16:18:11 UTC Comment hidden (obsolete)
Comment 4 QA Administrators 2017-01-03 19:49:58 UTC Comment hidden (obsolete)
Comment 5 Luke.A.Somers 2017-01-04 21:42:23 UTC
Problem persists in LibreOffice for mac. Apparently unchanged.
Comment 6 QA Administrators 2018-01-05 03:40:49 UTC Comment hidden (obsolete)
Comment 7 Luke.A.Somers 2018-01-09 17:14:38 UTC
Still present, no change.
Comment 8 Luke.A.Somers 2018-01-09 17:15:47 UTC
Oh shoot, I accidentally changed the version field. Can someo
Comment 9 eisa01 2018-03-10 12:45:23 UTC
I can not reproduce the quality field bug (Step 1-4)

I can reproduce somehow buggy behaviour in pixels/cm field, but slightly different:
1. Type 37
2. backspace twice (7 gets deleted, then nothing gets deleted)
3. field displays 3 with the cursor to the right
4. Type 5
5. field displays 53, having inserted 5 to the left instead

This was also reproducible on Windows, so setting version to all

Build ID: fb29e6eeeaad5255bb924ff59162a83ed80bfb0a
CPU threads: 2; OS: Mac OS X 10.12.6; UI render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-03-09_03:22:00
Locale: en-US (en_US.UTF-8); Calc: group
Comment 10 QA Administrators 2019-03-11 03:48:08 UTC Comment hidden (obsolete)
Comment 11 eisa01 2019-04-20 16:58:23 UTC
This works for me now
Comment 12 eisa01 2019-04-20 16:58:47 UTC
(In reply to eisa01 from comment #11)
> This works for me now

Build ID: ea9c13be02ba731074fa4207944ff7df40a0fb5c
CPU threads: 2; OS: Mac OS X 10.13.6; UI render: default; VCL: osx; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2019-04-10_20:43:17
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded