Last Comment Bug 821595 - No option to remember password for CalDAV calendar
: No option to remember password for CalDAV calendar
Status: RESOLVED FIXED
: regression
Product: Calendar
Classification: Client Software
Component: Provider: CalDAV (show other bugs)
: Lightning 2.1
: All All
: -- normal with 1 vote (vote)
: 2.1
Assigned To: Matthew Mecca [:mmecca]
:
Mentors:
: 814957 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-13 21:57 PST by Matthew Mecca [:mmecca]
Modified: 2013-02-21 08:06 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Fix v1 (1.31 KB, patch)
2012-12-23 08:21 PST, Matthew Mecca [:mmecca]
no flags Details | Diff | Review
Fix v2 (5.37 KB, patch)
2013-01-22 20:07 PST, Matthew Mecca [:mmecca]
philipp: review+
philipp: approval‑calendar‑aurora+
philipp: approval‑calendar‑beta+
Details | Diff | Review

Description Matthew Mecca [:mmecca] 2012-12-13 21:57:45 PST
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
Comment 1 Matthew Mecca [:mmecca] 2012-12-14 05:54:53 PST
Likely caused by Bug 723004
Comment 2 Matthew Mecca [:mmecca] 2012-12-23 08:21:47 PST
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.
Comment 3 Matthew Mecca [:mmecca] 2012-12-23 21:05:25 PST
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?
Comment 4 Patrick Cloke [:clokep] 2013-01-15 16:52:39 PST
*** Bug 814957 has been marked as a duplicate of this bug. ***
Comment 5 Philipp Kewisch [:Fallen] 2013-01-16 11:30:09 PST
(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?
Comment 6 Matthew Mecca [:mmecca] 2013-01-22 20:07:41 PST
Created attachment 705222 [details] [diff] [review]
Fix v2

Implements an nsILoadContext to pass in instead of the window.
Comment 7 Peter Lairo 2013-01-31 02:17:43 PST
Philipp has been AWOL from the newsgroups for the past 7 days. I hope he is OK.
Comment 8 Philipp Kewisch [:Fallen] 2013-02-07 07:20:37 PST
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,
Comment 9 Philipp Kewisch [:Fallen] 2013-02-07 07:22:17 PST
(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 Stefan Sitter 2013-02-07 07:25:57 PST
I think we don't need this in 1.9.x. The bug is reported for Lightning 2.1, currently in comm-beta.
Comment 11 Philipp Kewisch [:Fallen] 2013-02-07 07:32:15 PST
Comment on attachment 705222 [details] [diff] [review]
Fix v2

Indeed, sorry about that. Removing request for comm-release and approving for beta.
Comment 12 Peter Lairo 2013-02-07 13:39:55 PST
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/
Comment 14 Matthew Mecca [:mmecca] 2013-02-15 19:55:00 PST
(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 Lorenzo 2013-02-21 07:50:11 PST
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 Lorenzo 2013-02-21 08:04:33 PST
(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 Stefan Sitter 2013-02-21 08:06:04 PST
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.

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