Closed Bug 1582746 Opened 5 months ago Closed 5 months ago

After quick fix of bug 1582429 the TB stopped to sync WCAP calendar

Categories

(Calendar :: Provider: WCAP, defect)

Lightning 70
x86
Windows 10
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: arealone, Assigned: john.bieling)

Details

Attachments

(3 files, 1 obsolete file)

Attached file TBerrors1.txt

User Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

Configured WCAP calendar and TB does not sync it

Actual results:

Newly created calendar has exclamation mark in triangle next to its name now.

Expected results:

I expect calendar will be synced with the calendar server

Flags: needinfo?(jorgk)
OS: Unspecified → Windows 10
Hardware: Unspecified → x86
Version: Lightning 71 → Lightning 70
Mentor: jorgk

Thanks, plenty of errors in that log. This won't be as quick to fix as the other bug.

Mentor: jorgk
Flags: needinfo?(jorgk)

Does anyone know if WCAP requires cookies to work? There is an issue with TB68, which does not allow us to use cookies in network requests. Lightning CalDAV also is not able to use cookies at the moment (it ignores Set-Cookie headers). Could that be related?

Well, according to this https://en.wikipedia.org/wiki/Web_Calendar_Access_Protocol WCAP uses cookies
In the Response example there is Set-Cookie in the header:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000)/Tomcat-5.5
Set-Cookie: JSESSIONID=41DAC48C79927D68EDFAF5FBFD491236; Path=/
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 1399
Date: Mon, 21 May 2007 19:43:37 GMT

However I cannot find anything about cookies in Oracle Communications Calendar Server WCAP Developer's Guide Release 7.0
https://docs.oracle.com/cd/E54932_01/doc.705/e56603/cs_wcap_commands.htm#CSVDV169

Geoff, can we do anything here in a hurry. Do we have a WCAP server to test?

Flags: needinfo?(geoff)

Hello gents,

TB 68.1.1 is out and it allows to add new WCAP calendar without errors which were in 68.1.0.
I confirm the bug 1582429 is fixed in 68.1.1 but probably you know that better then me.

Is there any progress with the current bug?
Does the test account on WCAP server help to understand why WCAP calendar does not sync it with the server?
v.

We're moving the WCAP Provider out of the tree, therefore unfortunately we won't be providing further support. If you'd like to get involved in the development of the WCAP Provider please contact me via email.

Status: UNCONFIRMED → RESOLVED
Closed: 5 months ago
Flags: needinfo?(geoff)
Resolution: --- → WONTFIX

WCAP is removed as well as gData? That's news to me.

Not yet but soon. Bug 1579020

Couldn't you have said that earlier? I spend multiple hours investigating this!

You really want to remove it from TB68?

Removal would be for trunk I think.

The reason for this issue is this line:

https://searchfox.org/comm-central/source/calendar/providers/wcap/calWcapRequest.js#272

it must be changed to

this.execRespFunc(aStatus, result);
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---

Great. Can you provide a patch and get Geoff or Paul to review and approve it for ESR 68. Or let me do it. Note that WCAP is being removed soon in bug 1579020, but we might as well fix it for ESR so it runs for another year.

Fixed version of Lightning.

Victor, can you verify, that the attached version of lightning is working?

Please follow the instructions from Jorg (https://bugzilla.mozilla.org/show_bug.cgi?id=1582429#c27) to make sure that the new version is really loaded.

@Jorg: I currently do not have a build system up and cannot provide a real patch. As we will fix this only for TB68, can we slip it in trought the backdoor? Or do we need to go trunk -> approve beta -> approve esr?

Flags: needinfo?(arealone)
Attached patch 1584795.patch (obsolete) — Splinter Review

This is John's patch in his name.

Attachment #9098190 - Flags: review?(geoff)
Attachment #9098190 - Flags: approval-calendar-esr?(geoff)
Attachment #9098190 - Flags: approval-calendar-beta?(geoff)
Assignee: nobody → john.bieling
Status: REOPENED → ASSIGNED

Wrong patch.

Attachment #9098190 - Attachment is obsolete: true
Attachment #9098190 - Flags: review?(geoff)
Attachment #9098190 - Flags: approval-calendar-esr?(geoff)
Attachment #9098190 - Flags: approval-calendar-beta?(geoff)
Attachment #9098191 - Flags: review?(geoff)
Attachment #9098191 - Flags: approval-calendar-esr?(geoff)
Attachment #9098191 - Flags: approval-calendar-beta?(geoff)

Note: Untested by me and also derived from c-esr68. Should apply to trunk, but I haven't tried.

Comment on attachment 9098191 [details] [diff] [review]
1582746-wcap.patch

I'm okay with this.
Attachment #9098191 - Flags: review?(geoff)
Attachment #9098191 - Flags: review+
Attachment #9098191 - Flags: approval-calendar-esr?(geoff)
Attachment #9098191 - Flags: approval-calendar-esr+
Attachment #9098191 - Flags: approval-calendar-beta?(geoff)
Attachment #9098191 - Flags: approval-calendar-beta+

(In reply to John Bieling (TbSync) from comment #14)

Victor, can you verify, that the attached version of lightning is working?

Please follow the instructions from Jorg (https://bugzilla.mozilla.org/show_bug.cgi?id=1582429#c27) to make sure that the new version is really loaded.

@Jorg: I currently do not have a build system up and cannot provide a real patch. As we will fix this only for TB68, can we slip it in trought the backdoor? Or do we need to go trunk -> approve beta -> approve esr?

Hi,
I tried and it works!

Flags: needinfo?(arealone)
Target Milestone: --- → 71
Keywords: checkin-needed

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/437f7342a932
Fix copy/paste error from bug 1395118 to make WCAP work again. r=darktrojan

Status: ASSIGNED → RESOLVED
Closed: 5 months ago5 months ago
Keywords: checkin-needed
Resolution: --- → FIXED

For the record, I've ported this patch to the github repo at https://github.com/kewisch/wcap-provider

You need to log in before you can comment on or make changes to this bug.