Closed Bug 1579639 Opened Last month Closed Last month

Calendar List View order changed after installing Provider for Google Calendar (70.0b1)

Categories

(Calendar :: Calendar Views, defect)

Lightning 70
x86_64
Linux
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: walts48, Assigned: darktrojan)

Details

Attachments

(3 files)

Attached image Calendar-List.png

Steps to reproduce:

Started TB 70.0b1 with a test profile to test calendar functionality.
Created another calendar on my computer named "Events".
Installed Provider for Google Calendar 70.0b1.
Created my Google Network calendar.
Subscribed to my 5 read-only calendars and the main writable calendar.

What happened:

All calendars appeared in the correct order.
At first the lock icons for the read-only calendars did not appear.
Restarted Thunderbird.
Lock icons appeared and the order of the calendars was rearranged in the Calendar List with my Gmail calendar at the top.

What should have happened:

Lock Icons should have appeared after subscribing to the read-only calendars.
Calendar List View should have stayed in the order calendars were created.
Home
Events
Gmail
5 read-only calendars under Gmail.

Severity: normal → critical

gData is really a 3rd-party add-on which happens to be hosted in the comm-central tree for some historical reasons unknown to me. There are currently some considerations of removing if from the tree, see bug 1570933 comment #4 (last line) and discussions in other forums.

So IMHO we need to determine what part of the system is at fault, Calendar or gData. If it's gData, we'd need to close this as "invalid" like we do with all add-on related failures. Or alternatively, the add-on owner can track the fix here.

Flags: needinfo?(geoff)

According to description this is just a cosmetic issue? List of calendars can be manually sorted.

Severity: critical → normal

This is probably related to bug 1561530 and not the fault of the Google provider. I suspect the pref with the order is not being updated with new calendars and they are appearing in a default position. Will look into it.

Comment on attachment 9091247 [details]
Calendar-List.png

How are the locks applied to the calender?
Assignee: nobody → geoff
Status: NEW → ASSIGNED
Flags: needinfo?(geoff)
Attachment #9091358 - Flags: review?(paul)
Attachment #9091358 - Flags: approval-calendar-beta?(paul)
Comment on attachment 9091358 [details] [diff] [review]
1579639-calendar-list-sortorder-1.diff

Review of attachment 9091358 [details] [diff] [review]:
-----------------------------------------------------------------

Changes look good.  After re-arranging the order and restarting, the order was preserved.  Great to have tests for this.  I don't see a try server run yet.
Attachment #9091358 - Flags: review?(paul)
Attachment #9091358 - Flags: review+
Attachment #9091358 - Flags: approval-calendar-beta?(paul)
Attachment #9091358 - Flags: approval-calendar-beta+
Keywords: checkin-needed
Target Milestone: --- → 71

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/96ab8f83895f
Save calendar sort order pref when a new calendar is added. r=pmorris

Status: ASSIGNED → RESOLVED
Closed: Last month
Keywords: checkin-needed
Resolution: --- → FIXED

Looks like calendar/test/browser/browser_calendarList.js passes on Linux but not Mac or Windows on both c-c and c-b.

Where from here? Ignore the failure?

Flags: needinfo?(paul)
Flags: needinfo?(geoff)

Oh, you're kidding – the drag and drop test is failing. I suppose I should've expected that. :-/

I'll look into why, in the mean time, let's ignore it.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/9a8e0a9dac8b
follow-up: fix faulty test; rs=bustage-fix DONTBUILD

I should know better than to assume our test suites work consistently. I've changed the test to explicitly do what I originally wanted.

Flags: needinfo?(paul)
Flags: needinfo?(geoff)
Attachment #9091625 - Flags: approval-calendar-beta?(paul)
Attachment #9091625 - Flags: approval-calendar-beta?(paul) → approval-calendar-beta+
You need to log in before you can comment on or make changes to this bug.