The default bug view has changed. See this FAQ.

No option to remember password for CalDAV calendar

RESOLVED FIXED in 2.1

Status

Calendar
Provider: CalDAV
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: mmecca, Assigned: mmecca)

Tracking

({regression})

Lightning 2.1
regression

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

4 years ago
The prompt for username / password no longer offers the option to use Password Manager to remember the password. Works in TB Build ID 20121013030543, fails in 20121017030201
(Assignee)

Comment 1

4 years ago
Likely caused by Bug 723004
Keywords: regression
(Assignee)

Comment 2

4 years ago
Created attachment 695310 [details] [diff] [review]
Fix v1

If we don't pass a window in, the prompter defaults to private browsing mode and doesn't offer the option to save the password.
Assignee: nobody → matthew.mecca
Status: NEW → ASSIGNED
Attachment #695310 - Flags: review?(philipp)
(Assignee)

Comment 3

4 years ago
Comment on attachment 695310 [details] [diff] [review]
Fix v1

This fixes the problem for calendar creation, but it seems the active application window isn't always available yet when the password is first prompted at startup. Maybe we can delay the initial calendar load until after the window is loaded?
Duplicate of this bug: 814957
(In reply to Matthew Mecca [:mmecca] from comment #3)
> Comment on attachment 695310 [details] [diff] [review]
> Fix v1
> 
> This fixes the problem for calendar creation, but it seems the active
> application window isn't always available yet when the password is first
> prompted at startup. Maybe we can delay the initial calendar load until
> after the window is loaded?

I could imagine some hacks, I don't think we should wait for the window:

nsLoginManagerPrompter checks PrivateBrowsingUtils.isWindowPrivate(this._window) which in turn does this:

return aWindow.QueryInterface(Ci.nsIInterfaceRequestor)
                   .getInterface(Ci.nsIWebNavigation)
                   .QueryInterface(Ci.nsILoadContext);
   },

Maybe we could make the caldav provider implement a mock nsIWebNavigation/nsILoadContext and pass the same interfacerequestor that we use for the network channel redirects.

Even better, maybe we can make this global by implementing it in calProviderUtils.

Want to give it a try?
(Assignee)

Comment 6

4 years ago
Created attachment 705222 [details] [diff] [review]
Fix v2

Implements an nsILoadContext to pass in instead of the window.
Attachment #695310 - Attachment is obsolete: true
Attachment #695310 - Flags: review?(philipp)
Attachment #705222 - Flags: review?(philipp)

Comment 7

4 years ago
Philipp has been AWOL from the newsgroups for the past 7 days. I hope he is OK.
Comment on attachment 705222 [details] [diff] [review]
Fix v2

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

Looks good, r=philipp. Lets take this for 1.9.x if possible.

::: calendar/base/modules/calProviderUtils.jsm
@@ +196,5 @@
> +cal.LoadContext.prototype = {
> +    QueryInterface: function cLC_QueryInterface(aIID) {
> +        return cal.doQueryInterface(this, cal.LoadContext.prototype, aIID,
> +                                    [Components.interfaces.nsISupports,
> +                                     Components.interfaces.nsILoadContext]);

Since we are not going to make the loadcontext extend another class, I'd prefer using XPCOMUtils.generateQI here.

@@ +202,5 @@
> +
> +    associatedWindow: null,
> +    topWindow: null,
> +    topFrameElement: null,
> +    isAppOfType: function cLC_isAppOfType(appType) { return false; },

No specific need for named functions anymore since bug 433529 will land some time. Also, you can make use of ES5 style functions like:

topFrameElement: null,
isAppOfType: function() false,
isContent: false,
Attachment #705222 - Flags: review?(philipp)
Attachment #705222 - Flags: review+
Attachment #705222 - Flags: approval-calendar-release?
Attachment #705222 - Flags: approval-calendar-beta?
Attachment #705222 - Flags: approval-calendar-aurora?
(In reply to Peter Lairo from comment #7)
> Philipp has been AWOL from the newsgroups for the past 7 days. I hope he is
> OK.

I am fine, thanks :) Been busy with some final exams, things should get better now.

Comment 10

4 years ago
I think we don't need this in 1.9.x. The bug is reported for Lightning 2.1, currently in comm-beta.
Comment on attachment 705222 [details] [diff] [review]
Fix v2

Indeed, sorry about that. Removing request for comm-release and approving for beta.
Attachment #705222 - Flags: approval-calendar-release?
Attachment #705222 - Flags: approval-calendar-beta?
Attachment #705222 - Flags: approval-calendar-beta+
Attachment #705222 - Flags: approval-calendar-aurora?
Attachment #705222 - Flags: approval-calendar-aurora+

Comment 12

4 years ago
Assuming "aurora" means "alpha", and assuming alpha is NOT the same as comm-central, then what about the trunk aka nightly aka "comm-central" builds? Will this bug be fixed in tomorrow's trunk builds?

https://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-central/
(Assignee)

Comment 13

4 years ago
comm-central - https://hg.mozilla.org/comm-central/rev/92fce13b87d4
comm-aurora - https://hg.mozilla.org/releases/comm-aurora/rev/03bac50b08eb
comm-beta - https://hg.mozilla.org/releases/comm-beta/rev/03961992450c
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1
(Assignee)

Comment 14

4 years ago
(In reply to Peter Lairo from comment #12)
> Assuming "aurora" means "alpha", and assuming alpha is NOT the same as
> comm-central, then what about the trunk aka nightly aka "comm-central"
> builds? Will this bug be fixed in tomorrow's trunk builds?
> 

This should be available in the next build.

Comment 15

4 years ago
This still seems to be an issue in Lightning 2.1b1 on SeaMonkey 2.16 (Linux binary version) for caldav (actually through DavMail)

Comment 16

4 years ago
(In reply to Lorenzo from comment #15)
> This still seems to be an issue in Lightning 2.1b1 on SeaMonkey 2.16 (Linux
> binary version) for caldav (actually through DavMail)

Possible work-around for SeaMonkey:
- Deactivate calendar
- close seamonkey (esp. if you have Master Password)
- open seamonkey browser
- Enter the caldav url in the address bar
- Enter user name and password
- *do* click on the "Remember Password" button
- Re-activate the calendar

Comment 17

4 years ago
Lightning 2.1b1 was created before this patch was checked in and therefore doesn't contain the fix. You'll have to wait for an official 2.1b2 or 2.1 build, or apply the patch to your 2.1b1 installation or build Lightning 2.1 yourself.
You need to log in before you can comment on or make changes to this bug.