709727 - Fails to handle large numbers in the setting "Default Snooze Length"

Status: UNCONFIRMED

(Calendar :: Preferences, defect)

Description

[ebba]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2

Steps to reproduce:

1. Launch Lightning v1.0 
2.Open "Tools>Settings>Lightning>Alarms"
3.Type more than 16 numbers in the input field for Default time alarm goes off before a task


Actual results:

When entering 17 or more numbers, the precision is lost, e.g. 1234567890123456789 becomes 1234567890123456768.
If 22 numbers are typed, the number gets reset to 1.


Expected results:

Better handling, e.g. by not allowing more than 10 numbers?

Comment 1

[Felix Möller]

I cannot reproduce this on Linux with Thunderbird 8 and Lightning 1.1b1.

The field wraps on entering the 11th number to zero.

Comment 3

[ebba]

Interesting! We can reproduce this by using different Windows machines, with Thunderbird 8 and Lightning 1.0

Comment 4

[Wayne Mery (:wsmwk)]

Another

Comment 5

[Arthur K. (he/him)]

So when I tried to enter snooze length 1234567890123456789123456789, error console threw:

09:52:05.238 Uncaught ReferenceError: updateUIText is not defined calendar-alarm-dialog.xhtml:1:1
onselect chrome://calendar/content/calendar-alarm-dialog.xhtml:1

09:52:19.511 Element.releaseCapture() is deprecated. Use Element.releasePointerCapture() instead. For more help https://developer.mozilla.org/docs/Web/API/Element/releasePointerCapture menupopup.js:207:15

And when looking at the CalDAV output from Error Console, it shows: X-MOZ-SNOOZE-TIME:-2598805-162320 which seems wrong / malformed.

If I am reading correctly what (https://willpittman.net:8080/index.php?title=Icalendar_thirdparty_syntax) states, it shouldn't be a mangled / hyphenated negative number but a cleanly formatted YMDT entry.

So I'm confirming there appears to be much borkage happening here. TB should not be allowing any arbitrarily high snooze lengths. Logically, allowing more than 24 hours of snooze length seems senseless since a user should just be (forced into) creating that even for the next day rather than being allowed to enter some boundless snooze length value.

<2 cents>
Hard limit that value to not allow more than 24 hours or throw an error to the user stating as much.
</2 cents>

Comment 6

[Arthur K. (he/him)]

FYI, the OP's account is disabled which seems like they gave up on waiting for fix.

Comment 7

[Arthur K. (he/him)]

When I woke my PC from sleep, one of the items I snoozed for 1000 minutes fired off. A couple error items in Error Console showed up. Don't know if it's of any use but posting just in case.

07:56:24.449 TypeError: this._idleService is undefined imCore.sys.mjs:141:20
_checkIdle resource:///modules/imCore.sys.mjs:141
observe resource:///modules/imCore.sys.mjs:111

07:56:26.080 carddav.sync: Sync with server failed. CardDAVDirectory.jsm:652:11
syncWithServer resource:///modules/CardDAVDirectory.jsm:652

07:56:26.092 uncaught exception: 2147500036

07:56:26.117 [calCachedCalendar] replay action failed: <unknown>, uri=https://apidata.googleusercontent.com/caldav/v2/<account name removed>/events/, result=2147746065, operation=[xpconnect wrapped calIOperation]