This expands the details if any of these conditions are met:
* there is no html part, all we have is the event
* the pref calendar.itip.imipDetailsOpen true is set, to always show expanded
Differential Revision: https://phabricator.services.mozilla.com/D136328
--HG--
extra : rebase_source : 6eec6efc40682d09a02bcc689c6c8bb034a97848
A full custom element with attributes is no longer necessary.
This also fixes rotating the gripbars when rotating the view.
Differential Revision: https://phabricator.services.mozilla.com/D133652
--HG--
extra : amend_source : 98c801e446bbc1d1a8914ed6a2998bc7a21baf09
We no longer floor the pixels per minute to the next 0.001, which could accumulate ~1px errors over the full day.
We also use a flex display to accurately distribute this available space between the multiday hour boxes in the timebar and event columns.
Differential Revision: https://phabricator.services.mozilla.com/D133367
--HG--
extra : amend_source : 090d556f3e1957f34bf6a5a7586ead1185220d73
The UI should remain the same, with the exception of:
+ Day headings are always bold (the same as in the multiweek views). Before, only 'today' was bold.
+ Allday headers now have individual scrolling. Before, any overflow scrolling needed for one header would be shared by all headers.
+ Allday headers now have a max height in the rotated view. Moreover, the 'rows' are no longer strictly 'equalsize', which means we save some vertical space if only one day has a long header.
+ If the view is rotated, and the view overflows vertically, we can see and control both scrollbars. Before, the horizontal scrollbar would only be visible if the vertical scrollbar was at the bottom. Similarly when non-rotated.
+ Using a mixture of scrolling by dragging scrollbars and using a mouse wheel is now properly supported. Before, switching from the former method to the latter would cause the view to jump to the last wheel scroll position. Moreover, scrolling with the wheel will always snap to an exact hour.
+ There is no longer a 1px margin between the timebar and the event list. Instead, we have a 2px border.
+ The new changes work for right-to-left. This inadvertently fixes bug 1712942, plus more.
Differential Revision: https://phabricator.services.mozilla.com/D132244
This simplifies the structure of the calendar-event-column, and is a step towards making the calendar views more semantic and accessible.
Differential Revision: https://phabricator.services.mozilla.com/D129945
--HG--
extra : amend_source : 0d9b2f9111ef6743f11b5654553bd8d7d7c78eff
When a calendar is hidden but not disabled, synchronisation could cause items to be added or modified. These changes should be ignored by the agenda.
Differential Revision: https://phabricator.services.mozilla.com/D129884
--HG--
extra : moz-landing-system : lando
The log printer follows a cyclical reference until it dies of "too much recursion".
Differential Revision: https://phabricator.services.mozilla.com/D128976
--HG--
extra : rebase_source : c1909693412deb639017163ef22632b32773abf8
Libical is more picky when defining durations, it needs a "T" to specify a time. I forgot about this.
Differential Revision: https://phabricator.services.mozilla.com/D128699
--HG--
extra : rebase_source : caa6b9758b496584031ff25eec70b85139e815e7
All of these tests appear to be passing again. If they play up again, we can turn them off again.
Differential Revision: https://phabricator.services.mozilla.com/D128321
--HG--
extra : rebase_source : a033e6d68cc9a3d057b670148fe0d6a657306b49
This is still early days, only rules for parsing the included tests have been added so far. The CalExtractParserService
can be used instead of Extractor via a pref for experimentation.
Differential Revision: https://phabricator.services.mozilla.com/D125291
--HG--
extra : amend_source : 3061f336f165a4a4857fc94bee4342c15fdf04fc
This adds CalExtractParser that can be configured to use lexical and parse rules
for the desired locale.
Differential Revision: https://phabricator.services.mozilla.com/D123287
--HG--
extra : amend_source : 355ef7a0796224da8912f8b3ea44940de5138f20
... and remove the last remaining traces of Mozmill from calendar tests, except where necessary to do things with mail.
Differential Revision: https://phabricator.services.mozilla.com/D122710
--HG--
extra : rebase_source : 02a23bcf0e1761a12795b52110d3d01edf833051
These tests hijack the DNS module's functions to return the intended result.
We can't use the mock servers for the tests because we only do discovery for HTTPS, and the mock servers can't speak HTTPS. Instead, we direct the code to some files on the Mochitest server.
Differential Revision: https://phabricator.services.mozilla.com/D125501
--HG--
extra : rebase_source : 3ea40a9b8e8456991f01dc087a4b4b3d480ab62a
To begin with, this new class (actually a mixin so it can be used with different base classes) has an instance of the original calFilter. In future it might consume calFilter when we no longer need that as a separate class.
No widgets currently use the mixin but I have prototyped a new Today Pane agenda which works well. I will finish that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D123733
--HG--
rename : calendar/base/src/calFilter.js => calendar/base/content/widgets/calendar-filter.js
extra : rebase_source : af66938088c0e7949e6fdec73ccb0ceb5debd8f4
This makes us always show the generated invite html together with the normal html part.
Invites usually have an ok display in there generated by the server or sending client, and I think we don't want to normally show both parts at the same time. This patch changes the imip invite to just show an expandable summary on top of the html from the email. By clicking the arrow the details (like we had them) will be displayed, so that it still is accessible for the cases where the html representation is not there in the email, or it's bad.
Displaying the normal html content of the email solves problems expecially for "cancelled with a note" updates where you otherwise can't see the note because it's only inside the mail content.
Based on https://github.com/Betterbird/thunderbird-patches/blob/main/91/bugs/760412-always-show-text-calendar.patch
Differential Revision: https://phabricator.services.mozilla.com/D123374
--HG--
extra : rebase_source : a472f5825b80992cbe8bb8d5a72275315959332a
We've been clicking on a button that wasn't visible yet.
Differential Revision: https://phabricator.services.mozilla.com/D120809
--HG--
extra : rebase_source : 1ea25d98daaaafcd9dcd57cb87ff9c3597f6c716
Just tidying up some mess before we get started.
Differential Revision: https://phabricator.services.mozilla.com/D119143
--HG--
rename : calendar/test/modules/CalendarTestUtils.jsm => calendar/test/CalendarTestUtils.jsm
rename : calendar/test/modules/CalendarUtils.jsm => calendar/test/CalendarUtils.jsm
rename : calendar/test/modules/ItemEditingHelpers.jsm => calendar/test/ItemEditingHelpers.jsm
extra : rebase_source : 46e3b3eabd281d283a346c8b004acf2e64e28f80
extra : histedit_source : 6c2504193020911922c4efce41bc5a0a945cefaf%2Cf5c80aeaedaee5d4fca5f6a67579f8d0f9ba4bd8
This was accomplished by making the CalTransactionManager class aware of
batch transactions which can result in peeking of the transaction stack
returning null.
Differential Revision: https://phabricator.services.mozilla.com/D118928
--HG--
extra : amend_source : 0619e7758538fb82d43216f2f4aa2f8d0da8e5f5
This eliminates almost everything remaining named "Lightning" or "ltn" and not involved in L10n or preferences somehow.
Differential Revision: https://phabricator.services.mozilla.com/D118904
--HG--
extra : rebase_source : af81cd714f2c27df4eea403b4bc539ba8a806531
extra : amend_source : 6cfa1341f8f1cb0400c5ad4f32c90a006e22a3e9
This test synchronises with the remote calendar three times. An event is added the first time and should appear. It's modified the second time and should be updated. It's deleted the third time and should disappear.
Differential Revision: https://phabricator.services.mozilla.com/D118151
--HG--
extra : rebase_source : 1ed4779f49c24d0492fd55bc9851f190fe7b4eb3
extra : amend_source : 734b59aaeed5a3525ee9b9ffb67bb2ffdd4ee13d
Redefine the calendar.notifications.times pref:
- use `END:` to mean relative to the end
- use comma as separator of entries
An example is `PT2M,END:-PT3M`.
Differential Revision: https://phabricator.services.mozilla.com/D117391
--HG--
extra : amend_source : 45d82d2baec1ffe2f7f75390bb26f7934bf69614
This patch involves:
* changing the scopes we request when connecting mail (existing accounts are unaffected because the scope we originally requested is stored per-account in the preferences)
* teaching the CardDAV and CalDAV implementations to find passwords stored by username (with either the exact scope needed or many scopes)
Calendars with a username set (not sure how this happened, but they exist) will need to re-authorise. Other address books and calendars are not required to re-authorise.
Differential Revision: https://phabricator.services.mozilla.com/D117489
--HG--
extra : amend_source : b1e20b69683e846ed542115e063aace9917f00b5
We need to know if anything is going to break in the changes we're about to make.
Differential Revision: https://phabricator.services.mozilla.com/D117488
--HG--
extra : amend_source : 14db84dd2cd908e2dfdb6a7ef317adcb2627be74
Used HTML and CSS to reduce nesting of elements and to tidy their styling.
Also, made month and multiweek views more semantically correct by placing the "days of the week" headers within the <table>, and restyled it as a CSS grid.
Also, placed the month day event items within an <ol> element.
Also, renamed some classes to make them more consistent and meaningful, and dropped some duplicate or unused classes.
Differential Revision: https://phabricator.services.mozilla.com/D114731
--HG--
extra : amend_source : d277c9b32f8a00fec20364147a1cf76e0e881f9a
Also removed the test_addReminderImages unit test since it was testing ui features without 'document' or its localization, which is needed for setting img alt text.
Differential Revision: https://phabricator.services.mozilla.com/D111594
Replace the dynamic grid behaviour for the XUL box with a single column list.
Now, both the organizer labels and attendee labels use the same constructor, to keep styling consistent. And the list of attendees is represented by an unordered list <ul>, which is more semantically correct.
Also, calendar editing, summaries and email invitations all use the same constructors for attendees, which removes code duplication and keeps styling consistent. They also share the same styling sheets and localization.
In addition, the invitation document (lightning-invitation.xhtml) was rewritten to be more semantically correct and therefore more accessible. In particular, we no longer embed a table within another table's cell for the organizer row and attendees row (the unordered list is used in the latter case). Unnecessary paragraph <p> elements were removed from the cells. Row headers were marked as <th>. And the table header was moved to a <caption>.
Differential Revision: https://phabricator.services.mozilla.com/D111411
--HG--
extra : amend_source : aee820ea0e2a8c8d66cd9ca6045f1a825e3dc383
The "43" being typed into the preferences window was going to the search box instead of the number input as it should have. I think the click on the center of the input missed somehow.
--HG--
extra : rebase_source : a5ac3b0c13dac7d2fc86c6a2911ce8acffd63d87
This makes the alarm service ignore onAddItem and onModifyItem notifications in between onStartBatch and onEndBatch.
We know that onLoad will follow, at which point we reload all alarms from the calendar in question.
Ignoring the notifications prevents the alarms from firing multiple times in quick succession as the calendar loads.
I have in mind to follow this pattern across all of the UI pieces that listen to notifications, but first I really want to be sure (with tests) that sane behaviour is occurring.
I've added tests for this and (really lightly) the unifinder with all of the calendar types. More testing will be added to this later.
The ICS calendar with offline storage doesn't quite work right (as is the case in bug 1691885) but we can still test what does work.
Differential Revision: https://phabricator.services.mozilla.com/D109274
--HG--
extra : moz-landing-system : lando
This tests each combination of calendar provider and offline storage setting to ensure they behave consistently.
To do this I've added mock CalDAV and ICS servers (forked from CardDAVServer.jsm).
Differential Revision: https://phabricator.services.mozilla.com/D109272
--HG--
rename : mailnews/addrbook/test/CardDAVServer.jsm => calendar/test/CalDAVServer.jsm
rename : mailnews/addrbook/test/CardDAVServer.jsm => calendar/test/ICSServer.jsm
extra : moz-landing-system : lando
This patch adds a calendar.notifications.times pref in the form of "PT2H PT1M" to support multiple notifications. In followup patches, will add support for calendar level notification time, and UI to set the prefs.
Differential Revision: https://phabricator.services.mozilla.com/D109035
These tests have started failing all of the time. The problem is that in
waiting for an event box, we're getting the existing box before it is
replaced by the new one we're waiting for.
Differential Revision: https://phabricator.services.mozilla.com/D109862
--HG--
extra : histedit_source : aa70d4c128685dbbf2ebd7ec04ef73bd32464234
The lookup and lookupEventBox methods require full tree paths to find elements, which makes them hard to maintain when restructuring.
These were dropped from CalendarUtils, along with the path related methods and constants.
The standard querySelector and getElementById methods were used instead.
In particular, the CalendarTestUtils module was expanded with the dayView, weekView and multiweekView submodules to replace the lookupEventBox usage.
Differential Revision: https://phabricator.services.mozilla.com/D107005
--HG--
extra : moz-landing-system : lando
This appears to be happening because an edit is happening before the previous one has finished.
Waiting for the first edit to be reflected in the UI before moving on should prevent that.
Differential Revision: https://phabricator.services.mozilla.com/D104908
--HG--
extra : rebase_source : a28f9797b78d146b02f11cb54a3d91c1ba9f59b3
extra : histedit_source : f1038ede8eefcb150be56bd053d3217feee3dedd
I made an erroneous change that stopped the events being removed from the month/multi-week view
but didn't notice because there was no test coverage. This fixes the change, performs the removal
by a different method altogether, and adds test coverage.
Differential Revision: https://phabricator.services.mozilla.com/D104650
--HG--
extra : moz-landing-system : lando