GNOME Bugzilla – Bug 796398
CRASHER in Register Date input.
Last modified: 2018-06-30 00:10:50 UTC
1. Crasher - try to force date in register to be > 9999. - eg input date 15/12/9999 and keep pressing '+' - or input date 15/12/2000 and press another '0' to make date 15/12/20000 both lead to hard crash 2. Non-crasher - try input date 1/1/1400 or earlier - will revert to 1/1/1970 - input dates 2-january-1400 onwards, press [enter] - no probs - input date 9-january-1400 and keep pressing '-' - cycles 9/1/1400->1/1/1400 then [unicode-000B] then [today] then [yesterday] etc - input date 1-january-1400 press [enter] - date becomes 1/1/1970 Probably a series of unconnected behavioural cases which could be fixed in a single date sanitizer somewhere in register.
The crash part is already fixed in git and will be in 3.2. Sanitizing should happen in the date constructor; we take dates lots of places beside the register. But what do *you* expect the behavior to be when entering an invalid date?
Personally... depending on how I tried to achieve an invalid date - Pressing '+' or '-' would cease working at the edges, i.e. 30/12/9999, 31/12/9999, then stop changing. Or 3/1/1400 -> 2/1/1400. - Typing 03/01/2000 and pressing another '0' would not add another digit. To me this makes sense because I can't type anything other than digit or '/', so, this date field seems tailor made to accept valid dates only. - Typing 02/01/1200 and pressing [Enter] or [Tab] directly would either open error message "invalid date" or disable Enter/Tab behavior... the latter has disadvantage of not being exactly clear why cursor doesn't move.
- also pressing '[' ']' '_' '=' too would set the date to the minimum/maximum allowable dates
(In reply to Chris from comment #3) > - also pressing '[' ']' '_' '=' too would set the date to the > minimum/maximum allowable dates That last bit doesn't make sense: The min/max allowable are extremely unlikely to be useful. Maybe the beginning and end of the current accounting period would make sense, but they'd be new accelerators (see gnc_handle_date_accelerators in gnucash/gnome-utils/dialog-utils.c). '=' and '_' are associated with '+' and '-' respectively so that they're shift-insensitive. I don't think users would like us changing those.
Perhaps I should clarify better. Pressing - and = will decrease/increase by 1 day. Pressing _ and + will decrease/increase by 1 week. Pressing [ and ] will decrease/increase by 1 month. Pressing m and h will decrease/increase to begin/end of month. Pressing y and r will decrease/increase to begin/end of year. Actually thinking ahead, perhaps it's better to disable these keys if they would lead to an invalid date. i.e. date is 15-10-9999 and pressing ] repeatedly would lead to 15-11-9999, 15-12-9999, then stop.
(In reply to Chris from comment #5) > Perhaps I should clarify better. > > Pressing - and = will decrease/increase by 1 day. > Pressing _ and + will decrease/increase by 1 week. > Pressing [ and ] will decrease/increase by 1 month. > Pressing m and h will decrease/increase to begin/end of month. > Pressing y and r will decrease/increase to begin/end of year. <mod1><-_>/<+=> also does month increments, and <control><_->/<=+> does years. In the code it looks like <shift><-_>/<+=> does weeks, but of course a normal human thinks of the unshifted <-_> as just - and the shifted as _. The numeric keypad <+> and <-> also work, including if you shift them. That might be a bit confusing: Unshifted KP<+> will increment a day (equivalent to '=') and shifted it will increment 7. Anyway, not germane to this bug. > > Actually thinking ahead, perhaps it's better to disable these keys if they > would lead to an invalid date. i.e. date is 15-10-9999 and pressing ] > repeatedly would lead to 15-11-9999, 15-12-9999, then stop. Yes, I think that makes more sense.
I've had it in my 'to do' list for a while to update the documentation in the Guide 4.2.3. Using Entry Shortcuts re these date shortcuts. The current unstable guide does mention using _ and + but does not say they adjust the date by a week. What's <mod1>? Is that shift? Is it possible to use mouse over on the date fields to give these hints? Or put them in the (what I call) status bar at the bottom of the window after the long date display of the current value of the date field?
MOD1 is *supposed* to be <ALT> on all three platforms but when I test on a Mac it's the command key (which is supposed to be MOD2) that makes a month increment. I think that would make a pretty big tooltip (the name for the help that pops up if you leave the pointer over a control for more than a second) or a status-bar item. Aside from that I don't think the status bar really works for help from a human-factors standpoint: Users don't expect to see it.
Hi John, If we include all the date options in the tooltip it would be huge. Maybe just the unmodified options, e.g. _/+ decrease/increase date by 1 wk -/= decrease/increase date by 1 day m/h decrease/increase to beginning/end of month y/r decrease/increase to beginning/end of year t/t todays date Failing that, it would be useful for me anyway, if the status bar text said something like: See the Guide section 4.2.3 Using Entry Shortcuts for date shortcuts as it always takes me too long to find.
Have added the accelerator key restrictions to PR 366 along with a dialog for date out of range. Regarding the tooltip idea, I was wondering if a better approach would be to improve the existing tip of the day with above details, much quicker to find.
Hi Bob, I will update the existing Tip of the Day about this but I don't really think that searching tips is a usable replacement for a tooltip. I don't have a usability problem with large tooltips, other than they disappear before you can read all of it, so have to make it appear several times. In my experience, tooltips rarely show except when I want them too.
Context help, maybe? The tooltip could say "There are shortcuts, push <F1> to see them."
Context help is OK with me but I'd still prefer info in tooltip to save time.
Bob's PR is merged, so that leaves only settling the documentation.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=796398. Please continue processing the bug there and please update any external references or bookmarks.