From chimera at paulc.com  Sat Mar  8 10:03:39 2008
From: chimera at paulc.com (paulc)
Date: Sat, 8 Mar 2008 13:03:39 -0500
Subject: [Camino] TMZ
Message-ID: <p06240803c3f88209510c@[66.65.122.119]>

Please don't laugh, it's not out of puerile interest, I HAVE to keep 
an eye on this site for work. It's mostly all video, and I'd  guess 
flash video. Everything works just fine in Safari and Firefox, but 
not Camino (1.5.5). Yes, Camino announces itself as Firefox, so no 
need to tell me to try that.

It may not be the flash part (assuming video ARE flv)... any link to 
video draws a new window first... that window "opened" but noting 
typically is actually drawn in it. My guess is there might be some 
javascript Camino is choking on.

From nuffer at pipeline.com  Sun Mar  9 07:22:18 2008
From: nuffer at pipeline.com (Noemi)
Date: Sun, 9 Mar 2008 10:22:18 -0400
Subject: [Camino] Lost Passwords?
In-Reply-To: <p06240803c3f88209510c@[66.65.122.119]>
References: <p06240803c3f88209510c@[66.65.122.119]>
Message-ID: <4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>

Hi folks,

Camino seems to have suddenly forgotten about half the passwords in  
my keychain (but not all).  Most of the ones it has forgotten are  
ones I've added in the last 3 or 4 months.  Any idea what could have  
caused that and how to avoid its happening again?  The last time I  
upgraded was a few weeks before this happened.

thanks.

From stuart.morgan at alumni.case.edu  Sun Mar  9 07:46:43 2008
From: stuart.morgan at alumni.case.edu (Stuart Morgan)
Date: Sun, 9 Mar 2008 09:46:43 -0500
Subject: [Camino] Lost Passwords?
In-Reply-To: <4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
Message-ID: <201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>

On Sun, Mar 9, 2008 at 9:22 AM, Noemi <nuffer at pipeline.com> wrote:
>  Camino seems to have suddenly forgotten about half the passwords in
>  my keychain (but not all).  Most of the ones it has forgotten are
>  ones I've added in the last 3 or 4 months.  Any idea what could have
>  caused that and how to avoid its happening again?

Most likely, you reset either Camino or Safari, either of which would
remove any passwords created by Camino since you started using Camino
1.5.

-Stuart

From nuffer at pipeline.com  Sun Mar  9 08:08:59 2008
From: nuffer at pipeline.com (Noemi)
Date: Sun, 9 Mar 2008 11:08:59 -0400
Subject: [Camino] Lost Passwords?
In-Reply-To: <201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
Message-ID: <53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>


Wait, resetting *Safari* causes one to lose Camino passwords?  *Mind  
boggles.*  Is that going to be a permanent "feature"?


On Mar 9, 2008, at 10:46 AM, Stuart Morgan wrote:

> On Sun, Mar 9, 2008 at 9:22 AM, Noemi <nuffer at pipeline.com> wrote:
>>  Camino seems to have suddenly forgotten about half the passwords in
>>  my keychain (but not all).  Most of the ones it has forgotten are
>>  ones I've added in the last 3 or 4 months.  Any idea what could have
>>  caused that and how to avoid its happening again?
>
> Most likely, you reset either Camino or Safari, either of which would
> remove any passwords created by Camino since you started using Camino
> 1.5.
>
> -Stuart
> _______________________________________________
> Camino mailing list
> Camino at mozdev.org
> https://www.mozdev.org/mailman/listinfo/camino


From stuart.morgan at alumni.case.edu  Mon Mar 10 07:12:05 2008
From: stuart.morgan at alumni.case.edu (Stuart Morgan)
Date: Mon, 10 Mar 2008 07:12:05 -0700
Subject: [Camino] Lost Passwords?
In-Reply-To: <53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
Message-ID: <6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>

On Mar 9, 2008, at 8:08 AM, Noemi wrote:

> Wait, resetting *Safari* causes one to lose Camino passwords?  *Mind
> boggles.*  Is that going to be a permanent "feature"?

We use the standard OS password storage system as it is intended to be  
used, which is a feature, and is permanent. As for whether Safari will  
always choose to remove anything in that store that it can read  
(rather than just things it created, as Camino does) is something  
you'd have to ask Apple, since we don't control Safari development.

-Stuart

From nuffer at pipeline.com  Mon Mar 10 07:31:11 2008
From: nuffer at pipeline.com (Noemi)
Date: Mon, 10 Mar 2008 10:31:11 -0400
Subject: [Camino] Lost Passwords?
In-Reply-To: <6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
	<6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
Message-ID: <55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>


OK...

It's clearly possible to create keychain entries that Safari can't  
read, as evidenced by all the other apps that don't lose their  
passwords when Safari is reset.  Why does Camino create entries that  
Safari can read?

Thanks for answering my questions about this.


On Mar 10, 2008, at 10:12 AM, Stuart Morgan wrote:

> On Mar 9, 2008, at 8:08 AM, Noemi wrote:
>
>> Wait, resetting *Safari* causes one to lose Camino passwords?  *Mind
>> boggles.*  Is that going to be a permanent "feature"?
>
> We use the standard OS password storage system as it is intended to be
> used, which is a feature, and is permanent. As for whether Safari will
> always choose to remove anything in that store that it can read
> (rather than just things it created, as Camino does) is something
> you'd have to ask Apple, since we don't control Safari development.
>
> -Stuart
> _______________________________________________
> Camino mailing list
> Camino at mozdev.org
> https://www.mozdev.org/mailman/listinfo/camino


From nguyenhm16 at mac.com  Mon Mar 10 08:10:18 2008
From: nguyenhm16 at mac.com (Hung Michael Nguyen)
Date: Mon, 10 Mar 2008 08:10:18 -0700
Subject: [Camino] Lost Passwords?
In-Reply-To: <55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
	<6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
	<55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
Message-ID: <F0DBCA8E-0118-1000-A5D2-ADC736197A02-Webmail-10020@mac.com>

Camino used to work that way, but I think this new way, where the passwords are interoperable between Camino and Safari (with the downside that Safari can remove them) works better... there really should be no functional difference between a saved password for Camino and Safari, and you shouldn't have to save it twice.

Mike.


--
Mike Nguyen
nguyenhm16 at mac.com
nguyenhm16 (AIM)
281-788-6453 (cell)

Legum servi sumus ut liberi esse possimus.
-Cicero
 
On Monday, March 10, 2008, at 09:31AM, "Noemi" <nuffer at pipeline.com> wrote:
>
>OK...
>
>It's clearly possible to create keychain entries that Safari can't  
>read, as evidenced by all the other apps that don't lose their  
>passwords when Safari is reset.  Why does Camino create entries that  
>Safari can read?
>
>Thanks for answering my questions about this.
>
>
>On Mar 10, 2008, at 10:12 AM, Stuart Morgan wrote:
>
>> On Mar 9, 2008, at 8:08 AM, Noemi wrote:
>>
>>> Wait, resetting *Safari* causes one to lose Camino passwords?  *Mind
>>> boggles.*  Is that going to be a permanent "feature"?
>>
>> We use the standard OS password storage system as it is intended to be
>> used, which is a feature, and is permanent. As for whether Safari will
>> always choose to remove anything in that store that it can read
>> (rather than just things it created, as Camino does) is something
>> you'd have to ask Apple, since we don't control Safari development.
>>
>> -Stuart
>> _______________________________________________
>> Camino mailing list
>> Camino at mozdev.org
>> https://www.mozdev.org/mailman/listinfo/camino
>
>_______________________________________________
>Camino mailing list
>Camino at mozdev.org
>https://www.mozdev.org/mailman/listinfo/camino
>
>

From stuart.morgan at alumni.case.edu  Mon Mar 10 08:43:53 2008
From: stuart.morgan at alumni.case.edu (Stuart Morgan)
Date: Mon, 10 Mar 2008 08:43:53 -0700
Subject: [Camino] Lost Passwords?
In-Reply-To: <55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
	<6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
	<55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
Message-ID: <A3C1F2A9-3640-494C-8D60-EFF697E057EE@alumni.case.edu>

On Mar 10, 2008, at 7:31 AM, Noemi wrote:

> It's clearly possible to create keychain entries that Safari can't
> read, as evidenced by all the other apps that don't lose their
> passwords when Safari is reset.

Sure; Safari uses web form and HTTP auth passwords, so those are the  
types it reads. Most applications aren't browsers, and thus don't save  
passwords of those types.

> Why does Camino create entries that Safari can read?

Because we are storing the same information, for exactly the same  
purpose, that Safari would. It's not like we reverse-engineered  
Safari's keychain storage format and bent over backward to rig up  
entries that Safari can read; Safari can read them because we updated  
Camino's keychain code to correctly use the standard keychain types  
(which we didn't use before only because Camino's original keychain  
implementation predates the creation of standard keychain type for  
these sorts of passwords).

Using the keychain APIs correctly is a feature, and the  
interoperability with other browsers that use the keychain correctly  
which comes along with that is also a feature. The only arguable point  
is whether or not Safari should view the reset feature as applying  
only to things it created, or anything applicable to Safari, and that  
is something that we have no power to decide or change. If you  
disagree with Safari's current behavior, you would need to file a bug  
with Apple--although they may view this behavior as correct, just as  
Safari uses the system cookie storage system, and reseting cookies  
from within Safari's interface will affect just about any network- 
based applications that haven't explicitly opted out of using the  
system cookie store.

-Stuart

From aguite at gmail.com  Mon Mar 10 09:02:46 2008
From: aguite at gmail.com (Aric Guite)
Date: Mon, 10 Mar 2008 12:02:46 -0400
Subject: [Camino] Lost Passwords?
In-Reply-To: <A3C1F2A9-3640-494C-8D60-EFF697E057EE@alumni.case.edu>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
	<6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
	<55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
	<A3C1F2A9-3640-494C-8D60-EFF697E057EE@alumni.case.edu>
Message-ID: <27A62C8D-485B-4507-AB1A-E46F1809B4E8@gmail.com>

The problem with all of this is that it is not (from my perspective as  
an end user) expected behavior.

Arguments about Camino doing the "standard" thing or not aside, losing  
my Camino passwords when I reset Safari but not losing my Safari  
passwords when I reset Camino is  a problem. What are we to do? Wait  
for Apple to fix their bug?

Is there a way we can have an option for Camino to do the non-standard  
thing and store its passwords differently? Being stuck on the right  
side of the argument but still being hit by defective behavior is  
something that I think should be dealt with in some way.

~Aric


On 10-Mar-08, at 11:43 AM, Stuart Morgan wrote:

> On Mar 10, 2008, at 7:31 AM, Noemi wrote:
>
>> It's clearly possible to create keychain entries that Safari can't
>> read, as evidenced by all the other apps that don't lose their
>> passwords when Safari is reset.
>
> Sure; Safari uses web form and HTTP auth passwords, so those are the
> types it reads. Most applications aren't browsers, and thus don't save
> passwords of those types.
>
>> Why does Camino create entries that Safari can read?
>
> Because we are storing the same information, for exactly the same
> purpose, that Safari would. It's not like we reverse-engineered
> Safari's keychain storage format and bent over backward to rig up
> entries that Safari can read; Safari can read them because we updated
> Camino's keychain code to correctly use the standard keychain types
> (which we didn't use before only because Camino's original keychain
> implementation predates the creation of standard keychain type for
> these sorts of passwords).
>
> Using the keychain APIs correctly is a feature, and the
> interoperability with other browsers that use the keychain correctly
> which comes along with that is also a feature. The only arguable point
> is whether or not Safari should view the reset feature as applying
> only to things it created, or anything applicable to Safari, and that
> is something that we have no power to decide or change. If you
> disagree with Safari's current behavior, you would need to file a bug
> with Apple--although they may view this behavior as correct, just as
> Safari uses the system cookie storage system, and reseting cookies
> from within Safari's interface will affect just about any network-
> based applications that haven't explicitly opted out of using the
> system cookie store.
>
> -Stuart
> _______________________________________________
> Camino mailing list
> Camino at mozdev.org
> https://www.mozdev.org/mailman/listinfo/camino


From nuffer at pipeline.com  Mon Mar 10 09:21:27 2008
From: nuffer at pipeline.com (Noemi)
Date: Mon, 10 Mar 2008 12:21:27 -0400
Subject: [Camino] Lost Passwords?
In-Reply-To: <27A62C8D-485B-4507-AB1A-E46F1809B4E8@gmail.com>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
	<6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
	<55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
	<A3C1F2A9-3640-494C-8D60-EFF697E057EE@alumni.case.edu>
	<27A62C8D-485B-4507-AB1A-E46F1809B4E8@gmail.com>
Message-ID: <A32DD74E-FFB4-4508-B7F9-A6F5E33F0546@pipeline.com>


Yes, that would be my feeling too.  I definitely understand the  
desire to use standards for the sake of forwards-compatibility and  
interoperability; but unexpected data loss is a big deal.

On Mar 10, 2008, at 12:02 PM, Aric Guite wrote:

> The problem with all of this is that it is not (from my perspective as
> an end user) expected behavior.
>
> Arguments about Camino doing the "standard" thing or not aside, losing
> my Camino passwords when I reset Safari but not losing my Safari
> passwords when I reset Camino is  a problem. What are we to do? Wait
> for Apple to fix their bug?
>
> Is there a way we can have an option for Camino to do the non-standard
> thing and store its passwords differently? Being stuck on the right
> side of the argument but still being hit by defective behavior is
> something that I think should be dealt with in some way.
>
> ~Aric

From jswitte at indiana.edu  Mon Mar 10 10:41:07 2008
From: jswitte at indiana.edu (Jim Witte)
Date: Mon, 10 Mar 2008 13:41:07 -0400
Subject: [Camino] Lost Passwords?
In-Reply-To: <A3C1F2A9-3640-494C-8D60-EFF697E057EE@alumni.case.edu>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
	<6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
	<55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
	<A3C1F2A9-3640-494C-8D60-EFF697E057EE@alumni.case.edu>
Message-ID: <70825F4B-806D-4504-A900-AA021B4B9B3E@indiana.edu>

>> It's clearly possible to create keychain entries that Safari can't
>> read, as evidenced by all the other apps that don't lose their
>> passwords when Safari is reset.

   Is it possible to make passwords that Safari can *read*, but not  
delete?  I suppose that would be similar to a file permission (I  
think) of r+, w-, x- ?

Jim

From stuart.morgan at alumni.case.edu  Mon Mar 10 10:51:01 2008
From: stuart.morgan at alumni.case.edu (Stuart Morgan)
Date: Mon, 10 Mar 2008 10:51:01 -0700
Subject: [Camino] Lost Passwords?
In-Reply-To: <27A62C8D-485B-4507-AB1A-E46F1809B4E8@gmail.com>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
	<6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
	<55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
	<A3C1F2A9-3640-494C-8D60-EFF697E057EE@alumni.case.edu>
	<27A62C8D-485B-4507-AB1A-E46F1809B4E8@gmail.com>
Message-ID: <201fcf140803101051r19b8b69fna448569169942c33@mail.gmail.com>

On Mon, Mar 10, 2008 at 9:02 AM, Aric Guite <aguite at gmail.com> wrote:
>  The problem with all of this is that it is not (from my perspective as
>  an end user) expected behavior.

Then Safari isn't explaining their reset option adequately, and you
should file a bug with Apple about either changing the behavior, or
explaining it better. The site is http://bugreport.apple.com (you'll
need to create a free account).

>  losing my Camino passwords when I reset Safari but not losing my
>  Safari passwords when I reset Camino is  a problem.

We could make Camino remove non-Camino web passwords (we have no
intention of doing so, but it's certainly possible), however I don't
see how that would help the confusion about Safari's behavior.

>  Is there a way we can have an option for Camino to do the non-standard
>  thing and store its passwords differently?

Someone could write an input manager hack that would have that effect,
or you could use a third-party password management solution. We aren't
going to write and maintain a second, non-standard password storage
system as part of Camino though, because that's not consistent with
Camino's design philosophy or goals.

>  Being stuck on the right side of the argument but still being
>  hit by defective behavior is something that I think should be
>  dealt with in some way.

I agree that Safari doesn't do a good job explaining the behavior, but
again, whether or not the behavior itself is defective is a matter of
opinion. Apple is clearly moving to a model where there is a central
repository of certain types of data, and anyone can use or interact
with that store. This is their model for passwords, for calendars, for
todos, for rss subscriptions, for contacts, for cookies, etc.

I understand your argument, but undermining a primary purpose of the
OS's shared keychain system is not the right answer from our
perspective, any more than it would be the right answer for Camino to
stop using the keychain entirely if some application had a reset
button that deleted *everything* in the keychain (which would be
trivial to write). There are a lot of benefits for users to having
data in shared, interoperable systems, and if every application stops
using those systems as soon as any one application does something
unexpected or undesirable, then the whole model collapses, and users
are locked in to specific applications.


The bottom line is that interoperability with the OS system of
password storage (and by extension every application that also does
the right thing) is an explicit feature of Camino, and not one that we
are going to remove just because one client of that shared data
(Safari) has a feature that is not sufficiently explained by that
application. I understand that some people disagree with that position
(heck, some people have asked us to stop using the keychain entirely,
purely on the basis that they don't think we shouldn't share data with
other applications); Camino's built-in password manager may not be the
right password system for those people.

-Stuart

From stuart.morgan at alumni.case.edu  Mon Mar 10 10:53:01 2008
From: stuart.morgan at alumni.case.edu (Stuart Morgan)
Date: Mon, 10 Mar 2008 10:53:01 -0700
Subject: [Camino] Lost Passwords?
In-Reply-To: <70825F4B-806D-4504-A900-AA021B4B9B3E@indiana.edu>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
	<6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
	<55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
	<A3C1F2A9-3640-494C-8D60-EFF697E057EE@alumni.case.edu>
	<70825F4B-806D-4504-A900-AA021B4B9B3E@indiana.edu>
Message-ID: <201fcf140803101053j7d13bdb6wf4e5e049338811de@mail.gmail.com>

On Mon, Mar 10, 2008 at 10:41 AM, Jim Witte <jswitte at indiana.edu> wrote:
>  Is it possible to make passwords that Safari can *read*, but not delete?

The keychain uses an ACL system, where specific applications are
authorized for specific keychain items, but those controls are only
applied to reading the password data, not deleting the entry.

-Stuart

From stuart.morgan at alumni.case.edu  Mon Mar 10 11:30:18 2008
From: stuart.morgan at alumni.case.edu (Stuart Morgan)
Date: Mon, 10 Mar 2008 11:30:18 -0700
Subject: [Camino] Lost Passwords?
In-Reply-To: <27A62C8D-485B-4507-AB1A-E46F1809B4E8@gmail.com>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
	<6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
	<55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
	<A3C1F2A9-3640-494C-8D60-EFF697E057EE@alumni.case.edu>
	<27A62C8D-485B-4507-AB1A-E46F1809B4E8@gmail.com>
Message-ID: <201fcf140803101130r7d063e04g63d9e578e6779b20@mail.gmail.com>

On Mon, Mar 10, 2008 at 9:02 AM, Aric Guite <aguite at gmail.com> wrote:
>  What are we to do? Wait for Apple to fix their bug?

You may not have to; my comments about Safari behavior are based on
the testing I did at the time I wrote the new keychain code, which was
before Leopard was released. In a brief test I just did, Safari 3 on
Leopard doesn't appear to delete Camino entries (although since I
wasn't testing thoroughly I may be wrong). If they have changed the
behavior, it's possible that it was changed in Safari 3 for Tiger as
well.

-Stuart

From mak at bgp.nu  Mon Mar 10 11:40:06 2008
From: mak at bgp.nu (Mark Knopper)
Date: Mon, 10 Mar 2008 14:40:06 -0400
Subject: [Camino] Lost Passwords?
In-Reply-To: <201fcf140803101130r7d063e04g63d9e578e6779b20@mail.gmail.com>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
	<6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
	<55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
	<A3C1F2A9-3640-494C-8D60-EFF697E057EE@alumni.case.edu>
	<27A62C8D-485B-4507-AB1A-E46F1809B4E8@gmail.com>
	<201fcf140803101130r7d063e04g63d9e578e6779b20@mail.gmail.com>
Message-ID: <A2834C44-B80E-4386-9C0F-BC51678D1480@bgp.nu>

I just tried this with Leopard 10.5.2 (9C2028), Safari 3.1 (5525.13),  
and Camino Version 2.0a1pre (1.9b5pre 2008031000). I first went to a  
site on Camino to enter and have it save a password, then reset Safari  
and then went back to Camino and my password was still there.

	Mark


On Mar 10, 2008, at 2:30 PM, Stuart Morgan wrote:
> On Mon, Mar 10, 2008 at 9:02 AM, Aric Guite <aguite at gmail.com> wrote:
>> What are we to do? Wait for Apple to fix their bug?
>
> You may not have to; my comments about Safari behavior are based on
> the testing I did at the time I wrote the new keychain code, which was
> before Leopard was released. In a brief test I just did, Safari 3 on
> Leopard doesn't appear to delete Camino entries (although since I
> wasn't testing thoroughly I may be wrong). If they have changed the
> behavior, it's possible that it was changed in Safari 3 for Tiger as
> well.
>
> -Stuart
> _______________________________________________
> Camino mailing list
> Camino at mozdev.org
> https://www.mozdev.org/mailman/listinfo/camino
>


From aguite at gmail.com  Mon Mar 10 12:53:58 2008
From: aguite at gmail.com (Aric Guite)
Date: Mon, 10 Mar 2008 15:53:58 -0400
Subject: [Camino] Lost Passwords?
In-Reply-To: <201fcf140803101051r19b8b69fna448569169942c33@mail.gmail.com>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
	<6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
	<55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
	<A3C1F2A9-3640-494C-8D60-EFF697E057EE@alumni.case.edu>
	<27A62C8D-485B-4507-AB1A-E46F1809B4E8@gmail.com>
	<201fcf140803101051r19b8b69fna448569169942c33@mail.gmail.com>
Message-ID: <94C62560-DF57-4092-BA5C-C6F6DB1F7B31@gmail.com>

I agree with mostly everything you've said, except with the the part  
that implies that if another application (be it Safari or otherwise)  
deletes my Camino passwords, I'm going to have to just live with it.

Would it be possible for Camino to maintain a backup of all of the  
passwords it has created, and if they are missing (and not by Camino's  
doing), prompt the user saying something like "It seems that another  
application has modified or deleted your Camino Internet Passwords.  
Would you like to restore them?"

It just seems that while having and using a central source for this  
data is a great idea for many reasons, we're relying on all other  
applications being well behaved. Having some sort of user friendly way  
of managing that risk seem like it may be prudent.

~Aric

On 10-Mar-08, at 1:51 PM, Stuart Morgan wrote:
>
> I agree that Safari doesn't do a good job explaining the behavior, but
> again, whether or not the behavior itself is defective is a matter of
> opinion. Apple is clearly moving to a model where there is a central
> repository of certain types of data, and anyone can use or interact
> with that store. This is their model for passwords, for calendars, for
> todos, for rss subscriptions, for contacts, for cookies, etc.
>
> I understand your argument, but undermining a primary purpose of the
> OS's shared keychain system is not the right answer from our
> perspective, any more than it would be the right answer for Camino to
> stop using the keychain entirely if some application had a reset
> button that deleted *everything* in the keychain (which would be
> trivial to write). There are a lot of benefits for users to having
> data in shared, interoperable systems, and if every application stops
> using those systems as soon as any one application does something
> unexpected or undesirable, then the whole model collapses, and users
> are locked in to specific applications.
>
>
> The bottom line is that interoperability with the OS system of
> password storage (and by extension every application that also does
> the right thing) is an explicit feature of Camino, and not one that we
> are going to remove just because one client of that shared data
> (Safari) has a feature that is not sufficiently explained by that
> application. I understand that some people disagree with that position
> (heck, some people have asked us to stop using the keychain entirely,
> purely on the basis that they don't think we shouldn't share data with
> other applications); Camino's built-in password manager may not be the
> right password system for those people.
>
> -Stuart
> _______________________________________________
> Camino mailing list
> Camino at mozdev.org
> https://www.mozdev.org/mailman/listinfo/camino


From florian.boyd at gmail.com  Mon Mar 10 12:59:12 2008
From: florian.boyd at gmail.com (Florian)
Date: Mon, 10 Mar 2008 12:59:12 -0700
Subject: [Camino] Lost Passwords?
In-Reply-To: <94C62560-DF57-4092-BA5C-C6F6DB1F7B31@gmail.com>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
	<6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
	<55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
	<A3C1F2A9-3640-494C-8D60-EFF697E057EE@alumni.case.edu>
	<27A62C8D-485B-4507-AB1A-E46F1809B4E8@gmail.com>
	<201fcf140803101051r19b8b69fna448569169942c33@mail.gmail.com>
	<94C62560-DF57-4092-BA5C-C6F6DB1F7B31@gmail.com>
Message-ID: <98635f8a0803101259u4ecd4ae1k9de26c0bfaffe7fc@mail.gmail.com>

>
> that implies that if another application (be it Safari or otherwise)
> deletes my Camino passwords, I'm going to have to just live with it.



I think the point is the passwords are *website* passwords. Not Camino
passwords. Not Safari passwords. The password database is maintained by the
Keychain and is shared by all the browsers.

?Florian

From nuffer at pipeline.com  Mon Mar 10 13:07:39 2008
From: nuffer at pipeline.com (Noemi)
Date: Mon, 10 Mar 2008 16:07:39 -0400
Subject: [Camino] Lost Passwords?
In-Reply-To: <98635f8a0803101259u4ecd4ae1k9de26c0bfaffe7fc@mail.gmail.com>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
	<6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
	<55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
	<A3C1F2A9-3640-494C-8D60-EFF697E057EE@alumni.case.edu>
	<27A62C8D-485B-4507-AB1A-E46F1809B4E8@gmail.com>
	<201fcf140803101051r19b8b69fna448569169942c33@mail.gmail.com>
	<94C62560-DF57-4092-BA5C-C6F6DB1F7B31@gmail.com>
	<98635f8a0803101259u4ecd4ae1k9de26c0bfaffe7fc@mail.gmail.com>
Message-ID: <5F9221C4-9015-4555-B3A2-A8370AE34B07@pipeline.com>


Sure, but your browsing history is your Safari browsing history or  
your Camino browsing history.  Ditto with cache, bookmarks, etc.   
It's counterintuitive to be unable to reset one browser for fear of  
losing data you want to use in the other.

Frankly, I dislike the idea of sharing cookies, too -- it seriously  
complicates things in terms of testing whether the problems one  
experiences on a site are browser-based or session-based or what.

On Mar 10, 2008, at 3:59 PM, Florian wrote:

>>
>> that implies that if another application (be it Safari or otherwise)
>> deletes my Camino passwords, I'm going to have to just live with it.
>
>
>
> I think the point is the passwords are *website* passwords. Not Camino
> passwords. Not Safari passwords. The password database is  
> maintained by the
> Keychain and is shared by all the browsers.
>
> ?Florian
> _______________________________________________
> Camino mailing list
> Camino at mozdev.org
> https://www.mozdev.org/mailman/listinfo/camino


From stuart.morgan at alumni.case.edu  Mon Mar 10 13:56:03 2008
From: stuart.morgan at alumni.case.edu (Stuart Morgan)
Date: Mon, 10 Mar 2008 13:56:03 -0700
Subject: [Camino] Lost Passwords?
In-Reply-To: <94C62560-DF57-4092-BA5C-C6F6DB1F7B31@gmail.com>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
	<6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
	<55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
	<A3C1F2A9-3640-494C-8D60-EFF697E057EE@alumni.case.edu>
	<27A62C8D-485B-4507-AB1A-E46F1809B4E8@gmail.com>
	<201fcf140803101051r19b8b69fna448569169942c33@mail.gmail.com>
	<94C62560-DF57-4092-BA5C-C6F6DB1F7B31@gmail.com>
Message-ID: <201fcf140803101356o4ab272c1p94a1982c515c07ed@mail.gmail.com>

On Mon, Mar 10, 2008 at 12:53 PM, Aric Guite <aguite at gmail.com> wrote:
>  I agree with mostly everything you've said, except with the the part
>  that implies that if another application (be it Safari or otherwise)
>  deletes my Camino passwords, I'm going to have to just live with it.

In addition to Florian's point, which is a good one, I don't see where
I implied that. I explained how to file a bug against the software
that is actually doing the deletion that people are unhappy about,
which isn't at all the same thing as telling you to "just live with
it".

If you downloaded Foo, a bookmark management program that had a reset
button that, whenever you pressed it, unexpectedly deleted all of
Camino's bookmarks (because it used them as a source), would you
expect us to change the file Camino stores bookmarks in so that Foo
wouldn't find it any more, or would you complain to the developer of
Foo, and stop using that button in Foo in the meantime?

I'm confused at what seems to be a perception that it is unreasonable
to say that the right place for Safari behavior to be changed is in
Safari, rather than Camino. If I checked in code that made Reset
Camino have the same behavior that Safari has/had, would you email
Apple and tell them that Safari must stop using the standard keychain
system in order to prevent data loss?

On Mon, Mar 10, 2008 at 1:07 PM, Noemi <nuffer at pipeline.com> wrote:
>  It's counterintuitive to be unable to reset one browser for fear of
>  losing data you want to use in the other.

Then I suggest that you contact the developers of any browser with a
reset function that has that behavior; Camino is not one of them.

-Stuart

From aguite at gmail.com  Mon Mar 10 15:01:08 2008
From: aguite at gmail.com (Aric Guite)
Date: Mon, 10 Mar 2008 18:01:08 -0400
Subject: [Camino] Lost Passwords?
In-Reply-To: <201fcf140803101356o4ab272c1p94a1982c515c07ed@mail.gmail.com>
References: <p06240803c3f88209510c@66.65.122.119>
	<4F500197-CE2F-4C2D-BDDF-9A574B238C94@pipeline.com>
	<201fcf140803090746r1cebb50bw132369ba57cb26ad@mail.gmail.com>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
	<6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
	<55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
	<A3C1F2A9-3640-494C-8D60-EFF697E057EE@alumni.case.edu>
	<27A62C8D-485B-4507-AB1A-E46F1809B4E8@gmail.com>
	<201fcf140803101051r19b8b69fna448569169942c33@mail.gmail.com>
	<94C62560-DF57-4092-BA5C-C6F6DB1F7B31@gmail.com>
	<201fcf140803101356o4ab272c1p94a1982c515c07ed@mail.gmail.com>
Message-ID: <B6E794A1-547D-4075-BF48-02148CFAC732@gmail.com>

I will admit that I spoke perhaps too harshly.

I agree that Safari is screwing up here, but if it is as trivial to  
write software (maliciously or otherwise) that will delete any subset  
of the keychain as you say, then my keychain isn't safe at all. I'm  
trying to understand how I can protect it beyond writing bug reports  
(which I did, right after you suggested it). Because the data I create  
with your software is vulnerable to changes or deletions made by other  
software (and is also changing the behavior of your software), I want  
to know that I'm pursuing all avenues in the interest of making sure  
it never happens again.

I don't think that's unreasonable.

-Aric




On 10-Mar-08, at 4:56 PM, Stuart Morgan wrote:

> On Mon, Mar 10, 2008 at 12:53 PM, Aric Guite <aguite at gmail.com> wrote:
>> I agree with mostly everything you've said, except with the the part
>> that implies that if another application (be it Safari or otherwise)
>> deletes my Camino passwords, I'm going to have to just live with it.
>
> In addition to Florian's point, which is a good one, I don't see where
> I implied that. I explained how to file a bug against the software
> that is actually doing the deletion that people are unhappy about,
> which isn't at all the same thing as telling you to "just live with
> it".
>
> If you downloaded Foo, a bookmark management program that had a reset
> button that, whenever you pressed it, unexpectedly deleted all of
> Camino's bookmarks (because it used them as a source), would you
> expect us to change the file Camino stores bookmarks in so that Foo
> wouldn't find it any more, or would you complain to the developer of
> Foo, and stop using that button in Foo in the meantime?
>
> I'm confused at what seems to be a perception that it is unreasonable
> to say that the right place for Safari behavior to be changed is in
> Safari, rather than Camino. If I checked in code that made Reset
> Camino have the same behavior that Safari has/had, would you email
> Apple and tell them that Safari must stop using the standard keychain
> system in order to prevent data loss?
>
> On Mon, Mar 10, 2008 at 1:07 PM, Noemi <nuffer at pipeline.com> wrote:
>> It's counterintuitive to be unable to reset one browser for fear of
>> losing data you want to use in the other.
>
> Then I suggest that you contact the developers of any browser with a
> reset function that has that behavior; Camino is not one of them.
>
> -Stuart
> _______________________________________________
> Camino mailing list
> Camino at mozdev.org
> https://www.mozdev.org/mailman/listinfo/camino


From stuart.morgan at alumni.case.edu  Mon Mar 10 15:26:49 2008
From: stuart.morgan at alumni.case.edu (Stuart Morgan)
Date: Mon, 10 Mar 2008 15:26:49 -0700
Subject: [Camino] Lost Passwords?
In-Reply-To: <B6E794A1-547D-4075-BF48-02148CFAC732@gmail.com>
References: <p06240803c3f88209510c@66.65.122.119>
	<53AF1B41-865F-4BF8-8ACB-9AFF72113ED2@pipeline.com>
	<6165C26A-07D3-43A5-BA49-FC8D8F976B5C@alumni.case.edu>
	<55226FC8-94A4-4580-9129-5F6AA4069E68@pipeline.com>
	<A3C1F2A9-3640-494C-8D60-EFF697E057EE@alumni.case.edu>
	<27A62C8D-485B-4507-AB1A-E46F1809B4E8@gmail.com>
	<201fcf140803101051r19b8b69fna448569169942c33@mail.gmail.com>
	<94C62560-DF57-4092-BA5C-C6F6DB1F7B31@gmail.com>
	<201fcf140803101356o4ab272c1p94a1982c515c07ed@mail.gmail.com>
	<B6E794A1-547D-4075-BF48-02148CFAC732@gmail.com>
Message-ID: <201fcf140803101526x3487e0fcg40ae4fc7dd978891@mail.gmail.com>

On Mon, Mar 10, 2008 at 3:01 PM, Aric Guite <aguite at gmail.com> wrote:
>  if it is as trivial to write software (maliciously or otherwise) that will
>  delete any subset of the keychain as you say, then my keychain isn't
>  safe at all.

That depends on what you mean by safe. The keychain is designed to
prevent malicious applications from being able to learn or use
passwords you have saved in other applications, and in that regard it
is indeed safe (at least, I'm not aware of any general exploits that
allow password extraction). It's not safe from deletion, but no file
that you own is safe from deletion by software that you run.

>  Because the data I create with your software is vulnerable to changes
>  or deletions made by other software (and is also changing the behavior
>  of your software), I want to know that I'm pursuing all avenues in the
>  interest of making sure it never happens again.

Replace "your software" with "all software"; in a user-permission
based operating system, if you own a file, then applications running
as you can change them. An application could delete the file that
stores all of your keychain entries without even using the keychain
API. It could modify Safari preferences. It could add bookmarks to
Camino. It could change the star rankings on the songs in your iTunes
library. It could just delete every file in your home folder.

The way to protect your data under the assumption that the
applications your run are (intentionally or not) out to get you is a
real backup solution (like Time Machine).

-Stuart

From GreggHoover at copper.net  Wed Mar 12 08:21:27 2008
From: GreggHoover at copper.net (Gregg Hoover)
Date: Wed, 12 Mar 2008 11:21:27 -0400
Subject: [Camino] Stop Sites From Auto Refreshing
References: <28D5CF1D-6034-4580-B431-067F23AFEB07@copper.net>
Message-ID: <3B95D49F-DCA4-410D-80EF-1A8783586868@copper.net>

How can I configure Camino 1.5.5 to prevent sites that auto-refresh  
from doing so? It would be nice if that was a Hidden or even a  
visible Preference.

With a 2.5 kbs max speed dial up ISP and party line era phone  
service, some pages refresh even before they finish loading the first  
time. For example, I cannot get a complete loading of DrudgeReport.

Thanks


From stuart.morgan at alumni.case.edu  Wed Mar 12 09:38:58 2008
From: stuart.morgan at alumni.case.edu (Stuart Morgan)
Date: Wed, 12 Mar 2008 09:38:58 -0700
Subject: [Camino] Stop Sites From Auto Refreshing
In-Reply-To: <3B95D49F-DCA4-410D-80EF-1A8783586868@copper.net>
References: <28D5CF1D-6034-4580-B431-067F23AFEB07@copper.net>
	<3B95D49F-DCA4-410D-80EF-1A8783586868@copper.net>
Message-ID: <201fcf140803120938o509f0fa6x3ecbcbb1e983b483@mail.gmail.com>

On Wed, Mar 12, 2008 at 8:21 AM, Gregg Hoover <GreggHoover at copper.net> wrote:
>  How can I configure Camino 1.5.5 to prevent sites that auto-refresh
>  from doing so?

You can't; core support for blocking meta-refresh was only added in
Gecko 1.9 (which isn't finished yet, so isn't in released versions of
Camino). We have an open feature request for adding user control of
meta-refresh in Camino 2 or later, when it will be possible for us to
do so.

-Stuart

From zimbabao at yahoo.com  Wed Mar 12 23:03:42 2008
From: zimbabao at yahoo.com (Rajaram S. Gaunker)
Date: Wed, 12 Mar 2008 23:03:42 -0700 (PDT)
Subject: [Camino] unsubscribe
Message-ID: <338892.80732.qm@web34305.mail.mud.yahoo.com>



----- Original Message ----
From: Matthew Metzger <news at metzger.cc>
To: camino at mozdev.org
Sent: Wednesday, 20 February, 2008 2:39:09 AM
Subject: [Camino] print history

Hello,

I'm the system administrator for a school. Quite frequently, I get a 
request from a staff person to look at a student's browsing history.

Is there an easy way to get a report of the history in plain text or 
pdf. The "Print" option under File is not able to be selected when 
viewing the history.

I looked at the history.dat file and have not been able to find an easy 
way to generate a plain text report of the student's history. I tried: 
grep "http" history.dat , but that didn't work so well.

Any thoughts on how other schools are handling this would great.

thanks,

Matthew

_______________________________________________
Camino mailing list
Camino at mozdev.org
https://www.mozdev.org/mailman/listinfo/camino





From jswitte at indiana.edu  Thu Mar 13 09:59:11 2008
From: jswitte at indiana.edu (Jim Witte)
Date: Thu, 13 Mar 2008 12:59:11 -0400
Subject: [Camino] History.dat file 'decrytor' resources
In-Reply-To: <338892.80732.qm@web34305.mail.mud.yahoo.com>
References: <338892.80732.qm@web34305.mail.mud.yahoo.com>
Message-ID: <A1DFC370-775C-4685-8BFA-64A6EF95D8A7@indiana.edu>

On Mar 13, 2008, at 2:03 AM, Rajaram S. Gaunker wrote:

> Is there an easy way to get a report of the history in plain text or
> pdf. The "Print" option under File is not able to be selected when
> viewing the history.
> I looked at the history.dat file and have not been able to find..

   Short answer - not that I know of.

   Longer answer:

   There's a perl script out  called Mork there that will decode the  
rather cryptic (to put it MILDLY) history.dat files Mozilla browsers  
produce.  I don't know if the history.dat file structure has changed  
since this was done - so something more sane (like Safari's  
LastSession file perhpas?), or to something that breaks Mork,  
although I'd think not..  The file is cryptic enough as it is..

   I'm not aware of something that will take the output of Mork  
(whatever form it's in - it's text is all I know), and turn it into a  
PDF file, but PDF generators are a dime a dozen it seems.  There may  
be a fully formed too out there.  Perhaps even the Mozilla project  
has done it..  Remaking the history.dat file into something more  
human reabable, even if it does take up more space would be a better  
idea (there is a bit on the 'rant' page about history.dat that is  
apparently uses 2-byte character encoding for EVERYTHING, even 1-byte  
URls [most if not all URLs in the roman alphabet].  But..  that would  
require chaning things all the way back down in the Mozilla base.  Or  
forking the Camino history, which would be hard, and possibly create  
problems with interoperability with other Mozilla browsers (IS there  
interoperability between the history files of different Mozilla things?)

   If you're a Cocoa programmer, you might try looking at the  
bookmark window code for Camino and see how it works (I haven't)  I  
imagine it just calls routines in the Mozilla base that can pull  
stuff out of the history.dat file as needed.

   But Mork is probably the easiest bet to get SOMETING out of the  
history file.

Jim

These two URLs will get you started:

http://www.google.com/search?client=safari&rls=en&q=perl+mozill 
+history.dat&ie=UTF-8&oe=UTF-8

http://johnbokma.com/mexit/2004/04/19/mork.html

From chimera at paulc.com  Wed Mar 19 14:44:04 2008
From: chimera at paulc.com (paulc)
Date: Wed, 19 Mar 2008 17:44:04 -0400
Subject: [Camino] "messed up pages"
Message-ID: <p0624080dc40738fcb587@[74.66.242.208]>

Go to:

http://io9.com/369909/why-battlestar-galactica-is-the-best-political-drama-on-tv

in Camino (1.5.5) and Firefox (3.0b4). Is this a trunk issue (BTW, 
Camino is set to announce itself as FF)?

From stuart.morgan at alumni.case.edu  Wed Mar 19 15:18:36 2008
From: stuart.morgan at alumni.case.edu (Stuart Morgan)
Date: Wed, 19 Mar 2008 15:18:36 -0700
Subject: [Camino] "messed up pages"
In-Reply-To: <p0624080dc40738fcb587@74.66.242.208>
References: <p0624080dc40738fcb587@74.66.242.208>
Message-ID: <201fcf140803191518k3815e2fer5868ddcc271c46cd@mail.gmail.com>

On Wed, Mar 19, 2008 at 2:44 PM, paulc <chimera at paulc.com> wrote:
> Go to:
>
>  http://io9.com/369909/why-battlestar-galactica-is-the-best-political-drama-on-tv

When pages don't render correctly, please file bugs at
bugzilla.mozilla.org (with actual descriptions or screenshots of
what's wrong--again, descriptions like "not get" and "messed up" make
it impossible for us to actually investigate). It's much easier to
deal with bugs in the bug tracking system, and this list is intended
for discussion, rather than individual bug reporting.

Gecko rendering bugs especially need to be filed (against Core) rather
than emailed, since the people who would debug and fix them aren't
even on this list.

>  in Camino (1.5.5) and Firefox (3.0b4). Is this a trunk issue

Camino 1.5.5 is not trunk, so it sounds like not.

> (BTW, Camino is set to announce itself as FF)

Camino 1.5.5 does not have Firefox in the user agent; that won't be
true until 1.6.

-Stuart

From spectre at floodgap.com  Wed Mar 19 16:47:38 2008
From: spectre at floodgap.com (Cameron Kaiser)
Date: Wed, 19 Mar 2008 16:47:38 -0700 (PDT)
Subject: [Camino] plug-in architecture
Message-ID: <200803192347.m2JNldT2013788@floodgap.com>

I couldn't find this anywhere, but has there been any more information on
writing Camino plugins made available? This was not obvious on the
caminobrowser.org page.

Thanks, I know this is a recurrent request.

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Some days you're the bug, and some days you're the windshield. -------------

From stuart.morgan at alumni.case.edu  Wed Mar 19 17:38:09 2008
From: stuart.morgan at alumni.case.edu (Stuart Morgan)
Date: Wed, 19 Mar 2008 17:38:09 -0700
Subject: [Camino] plug-in architecture
In-Reply-To: <200803192347.m2JNldT2013788@floodgap.com>
References: <200803192347.m2JNldT2013788@floodgap.com>
Message-ID: <201fcf140803191738p569f3c5el32bb5c489077bcbd@mail.gmail.com>

On Wed, Mar 19, 2008 at 4:47 PM, Cameron Kaiser <spectre at floodgap.com> wrote:
>  I couldn't find this anywhere, but has there been any more information on
>  writing Camino plugins made available?

I assume you mean things to modify Camino itself, rather than NPAPI
plugins? Except for third-party preference panes (which there have
been efforts to document that aren't quite finished), there isn't a
extension model for Camino yet, so there's nothing to document.

I had hoped to add very preliminary support for directly loading
third-party bundles in 1.6 (with little or no supported API at first,
but as an incremental step away from input managers that would allow
us to better manager future incompatibilities), but I didn't have
time. Perhaps for 2.0.

>  Thanks, I know this is a recurrent request.

Maybe I'm misunderstanding your question though, since I'm not aware
offhand of any developer documentation that's been regularly
requested--so if there is something specific you are looking for,
please let us know.

-Stuart

From spectre at floodgap.com  Wed Mar 19 17:51:31 2008
From: spectre at floodgap.com (Cameron Kaiser)
Date: Wed, 19 Mar 2008 17:51:31 -0700 (PDT)
Subject: [Camino] plug-in architecture
In-Reply-To: <201fcf140803191738p569f3c5el32bb5c489077bcbd@mail.gmail.com>
	from Stuart Morgan at "Mar 19, 8 05:38:09 pm"
Message-ID: <200803200051.m2K0pV3c016556@floodgap.com>

> >  I couldn't find this anywhere, but has there been any more information on
> >  writing Camino plugins made available?
> 
> I assume you mean things to modify Camino itself, rather than NPAPI
> plugins?

Perhaps I should be more specific -- I have a Firefox extension I would
like to port to Camino. It does not use XUL; it's a pure protocol handler,
written in JavaScript via XPConnect. What kinds of changes would need to be
done to allow such a thing to run under Camino? Or has that not really been
explored yet?

I know XUL is an immediate problem, but I was hoping that more abstract
handlers to extend Camino's protocol support might be possible.

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- I shouldn't have to explain this to someone old enough to type. - S. Gardner

From stuart.morgan at alumni.case.edu  Wed Mar 19 18:38:50 2008
From: stuart.morgan at alumni.case.edu (Stuart Morgan)
Date: Wed, 19 Mar 2008 18:38:50 -0700
Subject: [Camino] plug-in architecture
In-Reply-To: <200803200051.m2K0pV3c016556@floodgap.com>
References: <200803200051.m2K0pV3c016556@floodgap.com>
Message-ID: <E02A0513-25DF-41D6-B163-E44B82EFE0D3@alumni.case.edu>

On Mar 19, 2008, at 5:51 PM, Cameron Kaiser wrote:
> Perhaps I should be more specific -- I have a Firefox extension I  
> would
> like to port to Camino. It does not use XUL; it's a pure protocol  
> handler,
> written in JavaScript via XPConnect. What kinds of changes would  
> need to be
> done to allow such a thing to run under Camino? Or has that not  
> really been
> explored yet?

Whether or not a non-XUL extension works is very dependent on the  
specific extension and what it uses, so there's no general answer. If  
it's interacting entirely with core components, then it may Just Work;  
on the other hand if it's interacting with higher-level components,  
they may not exist at all in Camino.

If you have a specific part of the extension that's failing, we can  
probably point you in the right direction.

-Stuart

From spectre at floodgap.com  Wed Mar 19 18:42:19 2008
From: spectre at floodgap.com (Cameron Kaiser)
Date: Wed, 19 Mar 2008 18:42:19 -0700 (PDT)
Subject: [Camino] plug-in architecture
In-Reply-To: <E02A0513-25DF-41D6-B163-E44B82EFE0D3@alumni.case.edu> from
	Stuart Morgan at "Mar 19, 8 06:38:50 pm"
Message-ID: <200803200142.m2K1gJoX018410@floodgap.com>

> Whether or not a non-XUL extension works is very dependent on the  
> specific extension and what it uses, so there's no general answer. If  
> it's interacting entirely with core components, then it may Just Work;  
> on the other hand if it's interacting with higher-level components,  
> they may not exist at all in Camino.
> 
> If you have a specific part of the extension that's failing, we can  
> probably point you in the right direction.

Okay, then I'm just going to play with it and ask questions as I encounter
them. Is there a "proper" way to install it, or just drop things directly
into the MacOS/components, /res (etc) directory?

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Long live the Commodore 64 -- eight bits are enough! -----------------------

From stuart.morgan at alumni.case.edu  Wed Mar 19 19:48:49 2008
From: stuart.morgan at alumni.case.edu (Stuart Morgan)
Date: Wed, 19 Mar 2008 19:48:49 -0700
Subject: [Camino] plug-in architecture
In-Reply-To: <200803200142.m2K1gJoX018410@floodgap.com>
References: <200803200142.m2K1gJoX018410@floodgap.com>
Message-ID: <27B76682-459D-4C8B-BF3E-B57101767D33@alumni.case.edu>

On Mar 19, 2008, at 6:42 PM, Cameron Kaiser wrote:

> Okay, then I'm just going to play with it and ask questions as I  
> encounter
> them. Is there a "proper" way to install it, or just drop things  
> directly
> into the MacOS/components, /res (etc) directory?

You probably want to use the "chrome" folder in the profile directory;  
the directions floating around online for how to manually install  
Flashblock in Camino (from before it was built in) might be helpful.

-Stuart

From chimera at paulc.com  Thu Mar 20 12:19:44 2008
From: chimera at paulc.com (paulc)
Date: Thu, 20 Mar 2008 15:19:44 -0400
Subject: [Camino] Rendering
In-Reply-To: <mailman.5.1206039602.61508.camino@mozdev.org>
References: <mailman.5.1206039602.61508.camino@mozdev.org>
Message-ID: <p06240809c4086641b10f@[74.66.242.208]>

At 12:00 PM -0700 3/20/08, camino-request at mozdev.org supposedly scribed:

>Gecko rendering bugs especially need to be filed (against Core) rather
>than emailed, since the people who would debug and fix them aren't
>even on this list.
>
>>   in Camino (1.5.5) and Firefox (3.0b4). Is this a trunk issue
>
>Camino 1.5.5 is not trunk, so it sounds like not.
>
>>  (BTW, Camino is set to announce itself as FF)
>
>Camino 1.5.5 does not have Firefox in the user agent; that won't be
>true until 1.6.
>
>-Stuart

Part of the reason I posted this was to see if I was alone... a 
critical piece of information needed before filing official bug 
reports. I obviously incorrectly assumed that "messed up" would be 
taken as "not rendered correctly."

Ah, now I see better to say "do they use the same version of the 
rendering engine?" If not, the this could point to why that page was 
not rendered correctly.

Funny, I'm pretty sure it was you who pointed me to a third party 
plug-in that can change the user agent... a prefpane by Nate Weaver, 
who I think used to be an active participant in this list.

From stuart.morgan at alumni.case.edu  Thu Mar 20 13:29:30 2008
From: stuart.morgan at alumni.case.edu (Stuart Morgan)
Date: Thu, 20 Mar 2008 13:29:30 -0700
Subject: [Camino] Rendering
In-Reply-To: <p06240809c4086641b10f@74.66.242.208>
References: <mailman.5.1206039602.61508.camino@mozdev.org>
	<p06240809c4086641b10f@74.66.242.208>
Message-ID: <201fcf140803201329x6ab3cd16y354f1eecb3328daa@mail.gmail.com>

On Thu, Mar 20, 2008 at 12:19 PM, paulc <chimera at paulc.com> wrote:
>  Part of the reason I posted this was to see if I was alone... a
>  critical piece of information needed before filing official bug
>  reports.

Not at all, that's why we have a bug triage process. The purpose of
having filed bugs is so that investigation can follow our normal
process for dealing with reported issues. There's no expectation that
someone has to verify that others see the same problem before we
investigate (and if any of our pages imply otherwise, please let us
know where so that we can change it)--if filing bugs weren't the right
way to report issues like the ones you've been posting here, then I
wouldn't have asked that you do so.

>  I obviously incorrectly assumed that "messed up" would be
>  taken as "not rendered correctly."

It was, but that's equally vague. "Not rendered correctly" could mean
anything from "the edge of some text is clipped" to "half of the page
is missing". If we don't know what we are looking for, then it's very
difficult to find it, or to know what we might try changing to
reproduce the issue if there's nothing obviously wrong with the page
when we check it. More importantly, it's impossible for us to know if
we see the same problem you are seeing if we don't know what it is you
see.

Following an established process for reporting issues and giving
enough detail that the specific issue is clear are both standard
practices for both commercial and open-source products; Camino is not
unusual in that regard. However, I'm sorry you apparently feel that
it's an unreasonable request in our case.

-Stuart

From david.fedoruk at gmail.com  Mon Mar 24 20:44:27 2008
From: david.fedoruk at gmail.com (David Fedoruk)
Date: Mon, 24 Mar 2008 20:44:27 -0700
Subject: [Camino] Rendering
In-Reply-To: <201fcf140803201329x6ab3cd16y354f1eecb3328daa@mail.gmail.com>
References: <mailman.5.1206039602.61508.camino@mozdev.org>
	<p06240809c4086641b10f@74.66.242.208>
	<201fcf140803201329x6ab3cd16y354f1eecb3328daa@mail.gmail.com>
Message-ID: <472444350803242044g2ee7b695w25bf7ec52d8a1099@mail.gmail.com>

Then how do we determine that what we see is not user error? I always
think three time, check things very carefully before I actually file a
bug.

It feels pretty risky for use non-programmers to stick out necks out
like that and file bugs on site like I think you're saying I should
now.

Cheers
df


On Thu, Mar 20, 2008 at 1:29 PM, Stuart Morgan
<stuart.morgan at alumni.case.edu> wrote:
> On Thu, Mar 20, 2008 at 12:19 PM, paulc <chimera at paulc.com> wrote:
>  >  Part of the reason I posted this was to see if I was alone... a
>  >  critical piece of information needed before filing official bug
>  >  reports.
>
>  Not at all, that's why we have a bug triage process. The purpose of
>  having filed bugs is so that investigation can follow our normal
>  process for dealing with reported issues. There's no expectation that
>  someone has to verify that others see the same problem before we
>  investigate (and if any of our pages imply otherwise, please let us
>  know where so that we can change it)--if filing bugs weren't the right
>  way to report issues like the ones you've been posting here, then I
>  wouldn't have asked that you do so.
>
>
>  >  I obviously incorrectly assumed that "messed up" would be
>  >  taken as "not rendered correctly."
>
>  It was, but that's equally vague. "Not rendered correctly" could mean
>  anything from "the edge of some text is clipped" to "half of the page
>  is missing". If we don't know what we are looking for, then it's very
>  difficult to find it, or to know what we might try changing to
>  reproduce the issue if there's nothing obviously wrong with the page
>  when we check it. More importantly, it's impossible for us to know if
>  we see the same problem you are seeing if we don't know what it is you
>  see.
>
>  Following an established process for reporting issues and giving
>  enough detail that the specific issue is clear are both standard
>  practices for both commercial and open-source products; Camino is not
>  unusual in that regard. However, I'm sorry you apparently feel that
>  it's an unreasonable request in our case.
>
>  -Stuart
>
>
> _______________________________________________
>  Camino mailing list
>  Camino at mozdev.org
>  https://www.mozdev.org/mailman/listinfo/camino
>



-- 
David Fedoruk
B.Mus. UBC,1986
Certificate in Internet Systems Administration, UBC, 2003


http://recordjackethistorian.wordpress.com
"Music is enough for one's life time, but one life time is not enough
for music" Sergei Rachmaninov

From stuart.morgan at alumni.case.edu  Mon Mar 24 23:42:36 2008
From: stuart.morgan at alumni.case.edu (Stuart Morgan)
Date: Mon, 24 Mar 2008 23:42:36 -0700
Subject: [Camino] Rendering
In-Reply-To: <472444350803242044g2ee7b695w25bf7ec52d8a1099@mail.gmail.com>
References: <mailman.5.1206039602.61508.camino@mozdev.org>
	<p06240809c4086641b10f@74.66.242.208>
	<201fcf140803201329x6ab3cd16y354f1eecb3328daa@mail.gmail.com>
	<472444350803242044g2ee7b695w25bf7ec52d8a1099@mail.gmail.com>
Message-ID: <AEB0894D-844C-4BBB-809C-98D8258FF3CA@alumni.case.edu>

On Mar 24, 2008, at 8:44 PM, David Fedoruk wrote:

> Then how do we determine that what we see is not user error? I always
> think three time, check things very carefully before I actually file a
> bug.

I'm not sure I understand the question. Whatever thinking and checking  
you would do before emailing the mailing list would be just as valid  
before filing a bug, but there are no guarantees either way that you  
will always be right, no matter where you send the report.

> It feels pretty risky for use non-programmers to stick out necks out
> like that and file bugs on site like I think you're saying I should
> now.

All I'm suggesting is that reports of problems should be sent (with a  
reasonable amount of detail) to a system that is designed for the  
express purpose of tracking those kind of reports--where it will go  
through normal testing/verification process, and be handled the people  
who have experience and expertise in doing that--instead of sending  
them all to a mailing list where the majority of people receiving it  
will have no interest in individual site bugs, even fewer of whom will  
know how to actually verify whether it's a real bug or not (most of  
those being exactly the people who would handle bug reports), there's  
no system in place for making sure the issue is actually investigated,  
and any follow-up debugging either becomes a private email  
conversation (making things even harder to keep track of) or spams the  
entire list repeatedly.

In short, I'm just asking that suspected bugs be sent to the bug  
reporting system, and the discussion list be used for general  
discussion. It means more of the right people will see reports in the  
format that is most useful--meaning they are more likely to be  
investigated--while spamming a lot fewer of the wrong people.  
Everybody is better off, so I don't see the risk.

If you are concerned that being wrong will reflect badly on you in  
some way (and there's no reason it would from the perspective of those  
of us doing triage) I would think that in the cases where a report  
turns out to be a non-bug after all, you'd rather only one or two  
people handle that report then have those same people email an entire  
mailing list of other users (the archives of which are, unlike  
bugzilla, indexed by search engines, making the distribution even  
wider) to point out that your report turned out to be "wrong".

-Stuart

From alqahira at ardisson.org  Tue Mar 25 20:14:43 2008
From: alqahira at ardisson.org (Smokey Ardisson)
Date: Tue, 25 Mar 2008 23:14:43 -0400
Subject: [Camino] Rendering
In-Reply-To: <472444350803242044g2ee7b695w25bf7ec52d8a1099@mail.gmail.com>
References: <mailman.5.1206039602.61508.camino@mozdev.org>
	<p06240809c4086641b10f@74.66.242.208>
	<201fcf140803201329x6ab3cd16y354f1eecb3328daa@mail.gmail.com>
	<472444350803242044g2ee7b695w25bf7ec52d8a1099@mail.gmail.com>
Message-ID: <a06200709c40f0059528d@[192.168.2.7]>

At 8:44 PM -0700 on 3/24/08, David Fedoruk wrote:

>Then how do we determine that what we see is not user error? I always
>think three time, check things very carefully before I actually file a
>bug.

If you're unsure if something you might be seeing could be "user 
error" or want to double-check what you're seeing, you can test with 
a fresh profile using Troubleshoot Camino ( 
http://pimpmycamino.com/parts/troubleshoot-camino ) and compare to 
the rendering in the equivalent Firefox build as a first step.  That 
won't rule out all causes of "user error" or problems related to your 
configuration, but it will catch several common problems of those 
types.

Smokey
-- 
Smokey Ardisson
Co-Lead
Triage/QA and Website & Documentation
The Camino Project