Camino Too Aggressive When Filling in Password Fields

RESOLVED DUPLICATE of bug 178607

Status

Camino Graveyard
HTML Form Controls
--
minor
RESOLVED DUPLICATE of bug 178607
15 years ago
14 years ago

People

(Reporter: David Wheeler, Assigned: Mike Pinkerton (not reading bugmail))

Tracking

unspecified
Camino1.5
PowerPC
Mac OS X

Details

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040304 Camino/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040304 Camino/0.7+

I'm the developer a of Bricoalge, a browser-based CMS. I use Camino for
development, demos, etc. The only bug I've noticed is a minor one, though it has
been around for as long as I've been using Camino.

  http://bricolage.cc/

I have Camino remember my username and password for logging in to Bricolage.
However, there are other pages in Bricolage that have password fields that are
unrelated to logging in (e.g., the user profile, where new users can be created,
existing ones updated, and include a password field for setting/changing
passwords). Annoyingly, Camino always fills in the first text field on such
pages with my username, and the first password field with my password. This
despite the fact that such pages have different URLs than the login page
(/login.html vs. /admin/profile/user/) and the fields have different names.

If it's any help in diagnosing the problem, Bricoalge runs in its own window
without the toolbar, location field, etc. Don't know if this affects how Camino
decids what's the same page as the login page.

Let me know if you need a login to my Bricolage demo server to try and diagnose
this problem.

Reproducible: Always
Steps to Reproduce:
1. Login to Bricolage.
2. Go to User profile or to Server Profile.
3. Watch Camino fill in fields it should not.

Actual Results:  
Fields were filled in with my username and password that should not have been.

Expected Results:  
The fields should have been left as-is.
(Assignee)

Comment 1

15 years ago
the logic for password fill is done by site name, not by page, so it'll
fill for any page on a site with a password. that has advantages (what
if the page changes name or is a cgi-generated url, you still want
autofill to work), but has the disadvantage you point out.

i'm open to suggestions. 
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Camino1.1
(Reporter)

Comment 2

15 years ago
Hm, dunno. How does Mozilla do it? I don't have the same issue with Mozilla.

Comment 3

14 years ago
This seems to be a dupe of Bug 187720, and both must be closely related, if not
dupes, to 178607 - no?

Comment 4

14 years ago
I don't think this is a dupe of Bug 187720, which is about htaccess and the like
vs. html forms. This is about different URLs at the same site, but all with the
same protocol.

It is the same underlying issue as bug 178607 though.

*** This bug has been marked as a duplicate of 178607 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 5

14 years ago
FWIW, to get around this bug in my application, I added autocomplete="off" to
the form tag on the pages that were inappropriately getting filled in. It works
for those browsers (including Camino) that pay attention to that attribute.

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