2.49.1 no longer auto completes user name or password

As the subject says, I just installed 2.49.1. In Facebook it still auto 
completes the user name but not password. After entering it still does 
not do it the next time.
On some other sites it neither auto enters the user name or password.
How can I put it back like it was?
0
Hawker
11/14/2017 12:32:18 AM
mozilla.support.seamonkey 12614 articles. 0 followers. Post Follow

28 Replies
25 Views

Similar Articles

[PageSpeed] 43

Hawker wrote:
> As the subject says, I just installed 2.49.1. In Facebook it still auto completes the 
> user name but not password. After entering it still does not do it the next time.
> On some other sites it neither auto enters the user name or password.
> How can I put it back like it was?

Confirm. Not FB with me, but in my modem's settings pages. The bug only manifests in 
particular circumstances.

Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.1
0
cmcadams
11/14/2017 2:54:20 AM
On 11/13/2017 4:32 PM, Hawker wrote:
> As the subject says, I just installed 2.49.1. In Facebook it still auto 
> completes the user name but not password. After entering it still does 
> not do it the next time.
> On some other sites it neither auto enters the user name or password.
> How can I put it back like it was?
> 

Windows 7 Ultimate SP1 (x64)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
	SeaMonkey/2.49.1

I have not seen this problem with saved logins.  There are some sites,
however, that construct their login forms in a manner that defeats the
saving of passwords and even defeats the use of existing saved
passwords.  That is a problem with the site and not with SeaMonkey.

-- 
David E. Ross
<http://www.rossde.com/>

Am I the only one who noticed the following?
*  President Trump issued executive orders
   that increase health-care costs.
*  The Republicans in Congress propose to
   eliminate itemized deductions for
   health-care costs.
0
David
11/14/2017 5:55:38 AM
Not sure if this already applies to 2.49.1.

Set signon.autofillForms.http to true and see what goes.

But I think FB should be https or?

FRG


David E. Ross wrote:
> On 11/13/2017 4:32 PM, Hawker wrote:
>> As the subject says, I just installed 2.49.1. In Facebook it still auto
>> completes the user name but not password. After entering it still does
>> not do it the next time.
>> On some other sites it neither auto enters the user name or password.
>> How can I put it back like it was?
>>
> 
> Windows 7 Ultimate SP1 (x64)
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
> 	SeaMonkey/2.49.1
> 
> I have not seen this problem with saved logins.  There are some sites,
> however, that construct their login forms in a manner that defeats the
> saving of passwords and even defeats the use of existing saved
> passwords.  That is a problem with the site and not with SeaMonkey.
> 
0
Frank
11/14/2017 8:25:35 AM
Bingo, that fixed my modem screens login problem. But...SM was happily enough filling 
most forms even with signon.autofillForms.http set to false. And there were never 
problems with 1.48 with the (presumed) same about:config settings. I'll confess I 
don't get it.

Craig


Frank-Rainer Grahl wrote:
> Not sure if this already applies to 2.49.1.
> 
> Set signon.autofillForms.http to true and see what goes.
> 
> But I think FB should be https or?
> 
> FRG
> 
> 
> David E. Ross wrote:
>> On 11/13/2017 4:32 PM, Hawker wrote:
>>> As the subject says, I just installed 2.49.1. In Facebook it still auto
>>> completes the user name but not password. After entering it still does
>>> not do it the next time.
>>> On some other sites it neither auto enters the user name or password.
>>> How can I put it back like it was?
>>>
>>
>> Windows 7 Ultimate SP1 (x64)
>> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
>> ����SeaMonkey/2.49.1
>>
>> I have not seen this problem with saved logins.� There are some sites,
>> however, that construct their login forms in a manner that defeats the
>> saving of passwords and even defeats the use of existing saved
>> passwords.� That is a problem with the site and not with SeaMonkey.
>>

0
cmcadams
11/14/2017 11:19:25 AM
autocomplete was refactored in Gecko 51 (2.48) and then again in 52 (2.49). 
Including changing some defaults when it comes to non-secure sites. Was not 
fun to play catchup. There might still linger other problems.

FRG

cmcadams wrote:
> Bingo, that fixed my modem screens login problem. But...SM was happily enough 
> filling most forms even with signon.autofillForms.http set to false. And there 
> were never problems with 1.48 with the (presumed) same about:config settings. 
> I'll confess I don't get it.
> 
> Craig
> 
> 
> Frank-Rainer Grahl wrote:
>> Not sure if this already applies to 2.49.1.
>>
>> Set signon.autofillForms.http to true and see what goes.
>>
>> But I think FB should be https or?
>>
>> FRG
>>
>>
>> David E. Ross wrote:
>>> On 11/13/2017 4:32 PM, Hawker wrote:
>>>> As the subject says, I just installed 2.49.1. In Facebook it still auto
>>>> completes the user name but not password. After entering it still does
>>>> not do it the next time.
>>>> On some other sites it neither auto enters the user name or password.
>>>> How can I put it back like it was?
>>>>
>>>
>>> Windows 7 Ultimate SP1 (x64)
>>> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
>>> ����SeaMonkey/2.49.1
>>>
>>> I have not seen this problem with saved logins.� There are some sites,
>>> however, that construct their login forms in a manner that defeats the
>>> saving of passwords and even defeats the use of existing saved
>>> passwords.� That is a problem with the site and not with SeaMonkey.
>>>
> 
0
Frank
11/14/2017 1:05:36 PM
hmm.
I wonder what else might need to be changed?
That fix didn't help me. Autocomplete of passwords is not working on any 
site I log into, Facebook, Google, AirB&B, my bank, other social 
networks, shopping places, etc.  It is a PITA for sure.
Might have something to do with my clearing cookies on close?

It all worked fine in 2.48

On 11/14/2017 8:05 AM, Frank-Rainer Grahl wrote:
> autocomplete was refactored in Gecko 51 (2.48) and then again in 52 
> (2.49). Including changing some defaults when it comes to non-secure 
> sites. Was not fun to play catchup. There might still linger other 
> problems.
> 
> FRG
> 
> cmcadams wrote:
>> Bingo, that fixed my modem screens login problem. But...SM was happily 
>> enough filling most forms even with signon.autofillForms.http set to 
>> false. And there were never problems with 1.48 with the (presumed) 
>> same about:config settings. I'll confess I don't get it.
>>
>> Craig
>>
>>
>> Frank-Rainer Grahl wrote:
>>> Not sure if this already applies to 2.49.1.
>>>
>>> Set signon.autofillForms.http to true and see what goes.
>>>
>>> But I think FB should be https or?
>>>
>>> FRG
>>>
>>>
>>> David E. Ross wrote:
>>>> On 11/13/2017 4:32 PM, Hawker wrote:
>>>>> As the subject says, I just installed 2.49.1. In Facebook it still 
>>>>> auto
>>>>> completes the user name but not password. After entering it still does
>>>>> not do it the next time.
>>>>> On some other sites it neither auto enters the user name or password.
>>>>> How can I put it back like it was?
>>>>>
>>>>
>>>> Windows 7 Ultimate SP1 (x64)
>>>> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
>>>> ����SeaMonkey/2.49.1
>>>>
>>>> I have not seen this problem with saved logins.� There are some sites,
>>>> however, that construct their login forms in a manner that defeats the
>>>> saving of passwords and even defeats the use of existing saved
>>>> passwords.� That is a problem with the site and not with SeaMonkey.
>>>>
>>

0
Hawker
11/14/2017 3:04:15 PM
Had recently seen this with a friends Firefox. Was caused by light profile 
corruption and an incompatible add-on.

Please check the Error console if you see any errors during startup or when 
opening the webpage where the passwords are not working.

Did you use a beta or alpha version higher than 2.49 before with your current 
profile?

FRG

Hawker wrote:
> hmm.
> I wonder what else might need to be changed?
> That fix didn't help me. Autocomplete of passwords is not working on any site 
> I log into, Facebook, Google, AirB&B, my bank, other social networks, shopping 
> places, etc.� It is a PITA for sure.
> Might have something to do with my clearing cookies on close?
> 
> It all worked fine in 2.48
> 
> On 11/14/2017 8:05 AM, Frank-Rainer Grahl wrote:
>> autocomplete was refactored in Gecko 51 (2.48) and then again in 52 (2.49). 
>> Including changing some defaults when it comes to non-secure sites. Was not 
>> fun to play catchup. There might still linger other problems.
>>
>> FRG
>>
>> cmcadams wrote:
>>> Bingo, that fixed my modem screens login problem. But...SM was happily 
>>> enough filling most forms even with signon.autofillForms.http set to false. 
>>> And there were never problems with 1.48 with the (presumed) same 
>>> about:config settings. I'll confess I don't get it.
>>>
>>> Craig
>>>
>>>
>>> Frank-Rainer Grahl wrote:
>>>> Not sure if this already applies to 2.49.1.
>>>>
>>>> Set signon.autofillForms.http to true and see what goes.
>>>>
>>>> But I think FB should be https or?
>>>>
>>>> FRG
>>>>
>>>>
>>>> David E. Ross wrote:
>>>>> On 11/13/2017 4:32 PM, Hawker wrote:
>>>>>> As the subject says, I just installed 2.49.1. In Facebook it still auto
>>>>>> completes the user name but not password. After entering it still does
>>>>>> not do it the next time.
>>>>>> On some other sites it neither auto enters the user name or password.
>>>>>> How can I put it back like it was?
>>>>>>
>>>>>
>>>>> Windows 7 Ultimate SP1 (x64)
>>>>> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
>>>>> ����SeaMonkey/2.49.1
>>>>>
>>>>> I have not seen this problem with saved logins.� There are some sites,
>>>>> however, that construct their login forms in a manner that defeats the
>>>>> saving of passwords and even defeats the use of existing saved
>>>>> passwords.� That is a problem with the site and not with SeaMonkey.
>>>>>
>>>
> 
0
Frank
11/14/2017 4:12:13 PM
Thank you. So basically the mothership doesn't care much about us, and isn't 
communicating changes well or perhaps at all.

Craig


Frank-Rainer Grahl wrote:
> autocomplete was refactored in Gecko 51 (2.48) and then again in 52 (2.49). Including 
> changing some defaults when it comes to non-secure sites. Was not fun to play 
> catchup. There might still linger other problems.
> 
> FRG
> 
> cmcadams wrote:
>> Bingo, that fixed my modem screens login problem. But...SM was happily enough 
>> filling most forms even with signon.autofillForms.http set to false. And there were 
>> never problems with 1.48 with the (presumed) same about:config settings. I'll 
>> confess I don't get it.
>>
>> Craig
>>
>>
>> Frank-Rainer Grahl wrote:
>>> Not sure if this already applies to 2.49.1.
>>>
>>> Set signon.autofillForms.http to true and see what goes.
>>>
>>> But I think FB should be https or?
>>>
>>> FRG
>>>
>>>
>>> David E. Ross wrote:
>>>> On 11/13/2017 4:32 PM, Hawker wrote:
>>>>> As the subject says, I just installed 2.49.1. In Facebook it still auto
>>>>> completes the user name but not password. After entering it still does
>>>>> not do it the next time.
>>>>> On some other sites it neither auto enters the user name or password.
>>>>> How can I put it back like it was?
>>>>>
>>>>
>>>> Windows 7 Ultimate SP1 (x64)
>>>> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
>>>> ����SeaMonkey/2.49.1
>>>>
>>>> I have not seen this problem with saved logins.� There are some sites,
>>>> however, that construct their login forms in a manner that defeats the
>>>> saving of passwords and even defeats the use of existing saved
>>>> passwords.� That is a problem with the site and not with SeaMonkey.
>>>>
>>

0
cmcadams
11/14/2017 5:02:59 PM
Can you tell me how to do that? How do I check the error console on 
start up?

And no I just went with official releases so from 2.48 to 2.49.1
This is really annoying - thinking I might have to revert back to 2.48. 
Especially the password manager lock up on opening bug that was 
introduced in 2.48 or 2.46 (I forget which) has not been fixed.

On 11/14/2017 11:12 AM, Frank-Rainer Grahl wrote:
> Had recently seen this with a friends Firefox. Was caused by light 
> profile corruption and an incompatible add-on.
> 
> Please check the Error console if you see any errors during startup or 
> when opening the webpage where the passwords are not working.
> 
> Did you use a beta or alpha version higher than 2.49 before with your 
> current profile?
> 
> FRG
> 
> Hawker wrote:
>> hmm.
>> I wonder what else might need to be changed?
>> That fix didn't help me. Autocomplete of passwords is not working on 
>> any site I log into, Facebook, Google, AirB&B, my bank, other social 
>> networks, shopping places, etc.� It is a PITA for sure.
>> Might have something to do with my clearing cookies on close?
>>
>> It all worked fine in 2.48
>>
>> On 11/14/2017 8:05 AM, Frank-Rainer Grahl wrote:
>>> autocomplete was refactored in Gecko 51 (2.48) and then again in 52 
>>> (2.49). Including changing some defaults when it comes to non-secure 
>>> sites. Was not fun to play catchup. There might still linger other 
>>> problems.
>>>
>>> FRG
>>>
>>> cmcadams wrote:
>>>> Bingo, that fixed my modem screens login problem. But...SM was 
>>>> happily enough filling most forms even with 
>>>> signon.autofillForms.http set to false. And there were never 
>>>> problems with 1.48 with the (presumed) same about:config settings. 
>>>> I'll confess I don't get it.
>>>>
>>>> Craig
>>>>
>>>>
>>>> Frank-Rainer Grahl wrote:
>>>>> Not sure if this already applies to 2.49.1.
>>>>>
>>>>> Set signon.autofillForms.http to true and see what goes.
>>>>>
>>>>> But I think FB should be https or?
>>>>>
>>>>> FRG
>>>>>
>>>>>
>>>>> David E. Ross wrote:
>>>>>> On 11/13/2017 4:32 PM, Hawker wrote:
>>>>>>> As the subject says, I just installed 2.49.1. In Facebook it 
>>>>>>> still auto
>>>>>>> completes the user name but not password. After entering it still 
>>>>>>> does
>>>>>>> not do it the next time.
>>>>>>> On some other sites it neither auto enters the user name or 
>>>>>>> password.
>>>>>>> How can I put it back like it was?
>>>>>>>
>>>>>>
>>>>>> Windows 7 Ultimate SP1 (x64)
>>>>>> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
>>>>>> ����SeaMonkey/2.49.1
>>>>>>
>>>>>> I have not seen this problem with saved logins.� There are some 
>>>>>> sites,
>>>>>> however, that construct their login forms in a manner that defeats 
>>>>>> the
>>>>>> saving of passwords and even defeats the use of existing saved
>>>>>> passwords.� That is a problem with the site and not with SeaMonkey.
>>>>>>
>>>>
>>

0
Hawker
11/15/2017 2:30:56 PM
I am unable to reproduce this one too. This is likely backend storage 
corruption caused by who knows what.

Check https://bugzilla.mozilla.org/show_bug.cgi?id=1305624 for the 
workaround.

You can delete the  webappsstore.* files in your profile and it usually 
works again.

Open the Error Console under Tools->Web Development->Error Console after 
SeaMonkey has started and filter for errors. Then open the webpage where 
the passwords are not working. Look for errors. If you don't see any 
just filter for warnings or remove all filters and see if anything 
catches your eye.

FRG


Hawker wrote:
> Especially the password manager lock up on opening bug that was 
> introduced in 2.48 or 2.46 (I forget which) has not been fixed.

0
Frank
11/15/2017 3:20:09 PM
To the best of my knowledge things are not that simple.
Firefox has cast Thunderbird out into the wilderness, presumably before 
making those changes you are so keen on.  If - this is a guess - those 
changes would have broken Thunderbird, Firefox no longer cares.
Seamonkey does care - for obvious reasons.



cmcadams wrote:
> Thank you. So basically the mothership doesn't care much about us, and
> isn't communicating changes well or perhaps at all.
>
> Craig
>
>
> Frank-Rainer Grahl wrote:
>> autocomplete was refactored in Gecko 51 (2.48) and then again in 52
>> (2.49). Including changing some defaults when it comes to non-secure
>> sites. Was not fun to play catchup. There might still linger other
>> problems.
>>
>> FRG
>>
>> cmcadams wrote:
>>> Bingo, that fixed my modem screens login problem. But...SM was
>>> happily enough filling most forms even with signon.autofillForms.http
>>> set to false. And there were never problems with 1.48 with the
>>> (presumed) same about:config settings. I'll confess I don't get it.
>>>
>>> Craig
>>>
>>>
>>> Frank-Rainer Grahl wrote:
>>>> Not sure if this already applies to 2.49.1.
>>>>
>>>> Set signon.autofillForms.http to true and see what goes.
>>>>
>>>> But I think FB should be https or?
>>>>
>>>> FRG
>>>>
>>>>
>>>> David E. Ross wrote:
>>>>> On 11/13/2017 4:32 PM, Hawker wrote:
>>>>>> As the subject says, I just installed 2.49.1. In Facebook it still
>>>>>> auto
>>>>>> completes the user name but not password. After entering it still
>>>>>> does
>>>>>> not do it the next time.
>>>>>> On some other sites it neither auto enters the user name or password.
>>>>>> How can I put it back like it was?
>>>>>>
>>>>>
>>>>> Windows 7 Ultimate SP1 (x64)
>>>>> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
>>>>>     SeaMonkey/2.49.1
>>>>>
>>>>> I have not seen this problem with saved logins.  There are some sites,
>>>>> however, that construct their login forms in a manner that defeats the
>>>>> saving of passwords and even defeats the use of existing saved
>>>>> passwords.  That is a problem with the site and not with SeaMonkey.
>>>>>
>>>
>

0
A
11/15/2017 4:43:55 PM
Again thank you for your time.
Removing webappsstore.sqlite seems to have fixed the password manager 
lock up issue. No idea what I lost in so doing.

Can you help me debug the rest of this?
When first launching SM I get 4 errors: They are

Timestamp: 11/15/2017 11:58:22 AM
Error: NS_ERROR_FILE_CORRUPTED: Component returned failure code: 
0x8052000b (NS_ERROR_FILE_CORRUPTED) [mozIStorageStatement.finalize]
Source File: resource://gre/components/nsSuiteGlue.js
Line: 422


Timestamp: 11/15/2017 11:58:23 AM
Error: DEPRECATION WARNING: Search service falling back to synchronous 
initialization. This is generally the consequence of an add-on using a 
deprecated search service API.
You may find more details about this deprecation at: 
https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIBrowserSearchService#async_warning
resource://gre/components/nsSearchService.js 2702 
SRCH_SVC__ensureInitialized
resource://gre/components/nsSearchService.js 4185 get currentEngine
resource://gre/components/nsSearchService.js 4178 get defaultEngine
chrome://navigator/content/urlbarBindings.xml 487 updateEngines
chrome://navigator/content/urlbarBindings.xml 357 
autocomplete-result-popup_XBL_Constructor
chrome://global/content/bindings/toolbar.xml 276 set_currentSet
chrome://global/content/bindings/toolbar.xml 181 _init
chrome://global/content/bindings/toolbar.xml 144 toolbar_XBL_Constructor/<

Source File: resource://gre/modules/Deprecated.jsm
Line: 79


Timestamp: 11/15/2017 11:58:23 AM
Error: TypeError: browser[name] is undefined
Source File: resource://devtools/client/framework/gDevTools.jsm
Line: 160

Timestamp: 11/15/2017 11:58:24 AM
Error: TypeError: menu is null
Source File: resource://gre/modules/commonjs/toolkit/loader.js -> 
resource://devtools/client/framework/browser-menus.js
Line: 341


When I open Facebook I get
Timestamp: 11/15/2017 11:58:48 AM
Error: :
Source File: https://staticxx.facebook.com/common/referer_frame.php
Line: 1


I later get some errors related to Image Zoom. Maybe this old plug in is 
causing issues?  I use it constantly - would hate to loose it. Is there 
a way to boot with no extensions enabled?




On 11/15/2017 10:20 AM, Frank-Rainer Grahl wrote:
> I am unable to reproduce this one too. This is likely backend storage 
> corruption caused by who knows what.
> 
> Check https://bugzilla.mozilla.org/show_bug.cgi?id=1305624 for the 
> workaround.
> 
> You can delete the� webappsstore.* files in your profile and it usually 
> works again.
> 
> Open the Error Console under Tools->Web Development->Error Console after 
> SeaMonkey has started and filter for errors. Then open the webpage where 
> the passwords are not working. Look for errors. If you don't see any 
> just filter for warnings or remove all filters and see if anything 
> catches your eye.
> 
> FRG
> 
> 
> Hawker wrote:
>> Especially the password manager lock up on opening bug that was 
>> introduced in 2.48 or 2.46 (I forget which) has not been fixed.
> 

0
Hawker
11/15/2017 5:04:23 PM
It all depends on who does the change. Some don't care and some do. The 
first round was announced. The second not. But there were some side 
effects with authentication breaking in non browser windows which took a 
little too long for my liking to get fixed.

FRG

A Williams wrote:
> To the best of my knowledge things are not that simple.
> Firefox has cast Thunderbird out into the wilderness, presumably before 
> making those changes you are so keen on.� If - this is a guess - those 
> changes would have broken Thunderbird, Firefox no longer cares.
> Seamonkey does care - for obvious reasons.
> 
> 
> 
> cmcadams wrote:
>> Thank you. So basically the mothership doesn't care much about us, and
>> isn't communicating changes well or perhaps at all.
>>
>> Craig
>>
>>
>> Frank-Rainer Grahl wrote:
>>> autocomplete was refactored in Gecko 51 (2.48) and then again in 52
>>> (2.49). Including changing some defaults when it comes to non-secure
>>> sites. Was not fun to play catchup. There might still linger other
>>> problems.
>>>
>>> FRG
>>>
>>> cmcadams wrote:
>>>> Bingo, that fixed my modem screens login problem. But...SM was
>>>> happily enough filling most forms even with signon.autofillForms.http
>>>> set to false. And there were never problems with 1.48 with the
>>>> (presumed) same about:config settings. I'll confess I don't get it.
>>>>
>>>> Craig
>>>>
>>>>
>>>> Frank-Rainer Grahl wrote:
>>>>> Not sure if this already applies to 2.49.1.
>>>>>
>>>>> Set signon.autofillForms.http to true and see what goes.
>>>>>
>>>>> But I think FB should be https or?
>>>>>
>>>>> FRG
>>>>>
>>>>>
>>>>> David E. Ross wrote:
>>>>>> On 11/13/2017 4:32 PM, Hawker wrote:
>>>>>>> As the subject says, I just installed 2.49.1. In Facebook it still
>>>>>>> auto
>>>>>>> completes the user name but not password. After entering it still
>>>>>>> does
>>>>>>> not do it the next time.
>>>>>>> On some other sites it neither auto enters the user name or 
>>>>>>> password.
>>>>>>> How can I put it back like it was?
>>>>>>>
>>>>>>
>>>>>> Windows 7 Ultimate SP1 (x64)
>>>>>> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
>>>>>> ��� SeaMonkey/2.49.1
>>>>>>
>>>>>> I have not seen this problem with saved logins.� There are some 
>>>>>> sites,
>>>>>> however, that construct their login forms in a manner that defeats 
>>>>>> the
>>>>>> saving of passwords and even defeats the use of existing saved
>>>>>> passwords.� That is a problem with the site and not with SeaMonkey.
>>>>>>
>>>>
>>
> 

0
Frank
11/15/2017 5:04:23 PM
On 11/14/2017 12:55 AM, David E. Ross wrote:
> On 11/13/2017 4:32 PM, Hawker wrote:
> 
> I have not seen this problem with saved logins.  There are some sites,
> however, that construct their login forms in a manner that defeats the
> saving of passwords and even defeats the use of existing saved
> passwords.  That is a problem with the site and not with SeaMonkey.
> 

For months now, after Capital One revamped their website, neither 
Seamonkey nor Firefox has been able to autofill the userid or password 
fields.  When I click on the ID field, nothing happens.  When I click on 
the password field, it wants to fill it with the ID.

However, through this entire time, Chrome has had no issues whatsoever 
in filling in both the ID and the password.

-- 
Jaime A. Cruz
President
Nassau Wings Motorcycle Club
http://www.nassauwings.org/

AMA District 34
http://www.AMADistrict34.com/
Freddy's Run
http://www.freddysrun.org/
0
Cruz
11/15/2017 5:41:41 PM
 > Timestamp: 11/15/2017 11:58:22 AM
 > Error: NS_ERROR_FILE_CORRUPTED: Component returned failure code:
 > 0x8052000b (NS_ERROR_FILE_CORRUPTED) [mozIStorageStatement.finalize]
 > Source File: resource://gre/components/nsSuiteGlue.js
 > Line: 422

Your permissions.sqlite file seems to be corrupt. It now holds the 
permissions for logins too since 2.48 so this would explain why you are 
unable to autologon. But any problems should already have surfaced in 2.48.

I would make a backup of the profile and just remove this one file and 
see if it works.
You will loose all site specific settings for cookies, image and other 
permissions but they can usually be recreated.

The other errors are normal/common during startup. Ok, they should not 
happen but will eventually be fixed and are harmless for now.

If removing the file does not work you can start into safe mode with 
Help -> Restart with Add-Ons Disabled.

FRG

Hawker wrote:
> Again thank you for your time.
> Removing webappsstore.sqlite seems to have fixed the password manager 
> lock up issue. No idea what I lost in so doing.
> 
> Can you help me debug the rest of this?
> When first launching SM I get 4 errors: They are
> 
> Timestamp: 11/15/2017 11:58:22 AM
> Error: NS_ERROR_FILE_CORRUPTED: Component returned failure code: 
> 0x8052000b (NS_ERROR_FILE_CORRUPTED) [mozIStorageStatement.finalize]
> Source File: resource://gre/components/nsSuiteGlue.js
> Line: 422
> 
> 
> Timestamp: 11/15/2017 11:58:23 AM
> Error: DEPRECATION WARNING: Search service falling back to synchronous 
> initialization. This is generally the consequence of an add-on using a 
> deprecated search service API.
> You may find more details about this deprecation at: 
> https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIBrowserSearchService#async_warning 
> 
> resource://gre/components/nsSearchService.js 2702 
> SRCH_SVC__ensureInitialized
> resource://gre/components/nsSearchService.js 4185 get currentEngine
> resource://gre/components/nsSearchService.js 4178 get defaultEngine
> chrome://navigator/content/urlbarBindings.xml 487 updateEngines
> chrome://navigator/content/urlbarBindings.xml 357 
> autocomplete-result-popup_XBL_Constructor
> chrome://global/content/bindings/toolbar.xml 276 set_currentSet
> chrome://global/content/bindings/toolbar.xml 181 _init
> chrome://global/content/bindings/toolbar.xml 144 toolbar_XBL_Constructor/<
> 
> Source File: resource://gre/modules/Deprecated.jsm
> Line: 79
> 
> 
> Timestamp: 11/15/2017 11:58:23 AM
> Error: TypeError: browser[name] is undefined
> Source File: resource://devtools/client/framework/gDevTools.jsm
> Line: 160
> 
> Timestamp: 11/15/2017 11:58:24 AM
> Error: TypeError: menu is null
> Source File: resource://gre/modules/commonjs/toolkit/loader.js -> 
> resource://devtools/client/framework/browser-menus.js
> Line: 341
> 
> 
> When I open Facebook I get
> Timestamp: 11/15/2017 11:58:48 AM
> Error: :
> Source File: https://staticxx.facebook.com/common/referer_frame.php
> Line: 1
> 
> 
> I later get some errors related to Image Zoom. Maybe this old plug in is 
> causing issues?� I use it constantly - would hate to loose it. Is there 
> a way to boot with no extensions enabled?
> 
> 
> 
> 
> On 11/15/2017 10:20 AM, Frank-Rainer Grahl wrote:
>> I am unable to reproduce this one too. This is likely backend storage 
>> corruption caused by who knows what.
>>
>> Check https://bugzilla.mozilla.org/show_bug.cgi?id=1305624 for the 
>> workaround.
>>
>> You can delete the� webappsstore.* files in your profile and it 
>> usually works again.
>>
>> Open the Error Console under Tools->Web Development->Error Console 
>> after SeaMonkey has started and filter for errors. Then open the 
>> webpage where the passwords are not working. Look for errors. If you 
>> don't see any just filter for warnings or remove all filters and see 
>> if anything catches your eye.
>>
>> FRG
>>
>>
>> Hawker wrote:
>>> Especially the password manager lock up on opening bug that was 
>>> introduced in 2.48 or 2.46 (I forget which) has not been fixed.
>>
> 

0
Frank
11/15/2017 5:44:05 PM
On 11/15/2017 9:41 AM, Cruz, Jaime wrote:
> On 11/14/2017 12:55 AM, David E. Ross wrote:
>> On 11/13/2017 4:32 PM, Hawker wrote:
>>
>> I have not seen this problem with saved logins.  There are some sites,
>> however, that construct their login forms in a manner that defeats the
>> saving of passwords and even defeats the use of existing saved
>> passwords.  That is a problem with the site and not with SeaMonkey.
>>
> 
> For months now, after Capital One revamped their website, neither 
> Seamonkey nor Firefox has been able to autofill the userid or password 
> fields.  When I click on the ID field, nothing happens.  When I click on 
> the password field, it wants to fill it with the ID.
> 
> However, through this entire time, Chrome has had no issues whatsoever 
> in filling in both the ID and the password.
> 

When I see this (which is rarely), I use SeaMonkey's Password Manager to
delete the user ID and password for the particular login.  I then
terminate and relaunch SeaMonkey.  Having a complete list (encrypted via
PGP) of IDs and passwords, I am then able to login to the site, entering
and saving the ID and password anew.

-- 
David E. Ross
<http://www.rossde.com/>

Am I the only one who noticed the following?
*  President Trump issued executive orders
   that increase health-care costs.
*  The Republicans in Congress propose to
   eliminate itemized deductions for
   health-care costs.
0
David
11/15/2017 6:37:01 PM
On 11/15/17 11:43 AM, A Williams wrote:
> To the best of my knowledge things are not that simple.
> Firefox has cast Thunderbird out into the wilderness, presumably before 
> making those changes you are so keen on.  If - this is a guess - those 
> changes would have broken Thunderbird, Firefox no longer cares.
> Seamonkey does care - for obvious reasons.
> 

Firefox is a product of the Mozilla Corporation. Not a company.

Mozilla has made some changes regarding Thunderbird and they are 
receiving some changes Firefox gets.

They also have landed in a new home at the Mozilla Foundation and are in 
progress of acquiring their own infrastructure. AIUI.

<https://blog.mozilla.org/thunderbird/2017/05/thunderbirds-future-home/>

> 
> cmcadams wrote:
>> Thank you. So basically the mothership doesn't care much about us, and
>> isn't communicating changes well or perhaps at all.


-- 
Less than three months until Valentine's Day
Coexist <https://www.coexist.org/>
National Popular Vote <http://www.nationalpopularvote.com/>
Ubuntu 16.04LTS - Unity Desktop
0
WaltS48
11/15/2017 7:53:30 PM
Thank you thank you thank you!
Deleting permissions.sqlite fixed my password issue!
Your other recommendation fixed my data manager issue.

I'm not sure what all I lost so I am a tad concerned that I may have 
lost an important setting.  I also wish I knew how you got that file 
form the error.

So very thankful for your help here!

On 11/15/2017 12:44 PM, Frank-Rainer Grahl wrote:
>  > Timestamp: 11/15/2017 11:58:22 AM
>  > Error: NS_ERROR_FILE_CORRUPTED: Component returned failure code:
>  > 0x8052000b (NS_ERROR_FILE_CORRUPTED) [mozIStorageStatement.finalize]
>  > Source File: resource://gre/components/nsSuiteGlue.js
>  > Line: 422
> 
> Your permissions.sqlite file seems to be corrupt. It now holds the 
> permissions for logins too since 2.48 so this would explain why you are 
> unable to autologon. But any problems should already have surfaced in 2.48.
> 
> I would make a backup of the profile and just remove this one file and 
> see if it works.
> You will loose all site specific settings for cookies, image and other 
> permissions but they can usually be recreated.
> 
> The other errors are normal/common during startup. Ok, they should not 
> happen but will eventually be fixed and are harmless for now.
> 
> If removing the file does not work you can start into safe mode with 
> Help -> Restart with Add-Ons Disabled.
> 
> FRG
> 
> Hawker wrote:
>> Again thank you for your time.
>> Removing webappsstore.sqlite seems to have fixed the password manager 
>> lock up issue. No idea what I lost in so doing.
>>
>> Can you help me debug the rest of this?
>> When first launching SM I get 4 errors: They are
>>
>> Timestamp: 11/15/2017 11:58:22 AM
>> Error: NS_ERROR_FILE_CORRUPTED: Component returned failure code: 
>> 0x8052000b (NS_ERROR_FILE_CORRUPTED) [mozIStorageStatement.finalize]
>> Source File: resource://gre/components/nsSuiteGlue.js
>> Line: 422
>>
>>
>> Timestamp: 11/15/2017 11:58:23 AM
>> Error: DEPRECATION WARNING: Search service falling back to synchronous 
>> initialization. This is generally the consequence of an add-on using a 
>> deprecated search service API.
>> You may find more details about this deprecation at: 
>> https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIBrowserSearchService#async_warning 
>>
>> resource://gre/components/nsSearchService.js 2702 
>> SRCH_SVC__ensureInitialized
>> resource://gre/components/nsSearchService.js 4185 get currentEngine
>> resource://gre/components/nsSearchService.js 4178 get defaultEngine
>> chrome://navigator/content/urlbarBindings.xml 487 updateEngines
>> chrome://navigator/content/urlbarBindings.xml 357 
>> autocomplete-result-popup_XBL_Constructor
>> chrome://global/content/bindings/toolbar.xml 276 set_currentSet
>> chrome://global/content/bindings/toolbar.xml 181 _init
>> chrome://global/content/bindings/toolbar.xml 144 
>> toolbar_XBL_Constructor/<
>>
>> Source File: resource://gre/modules/Deprecated.jsm
>> Line: 79
>>
>>
>> Timestamp: 11/15/2017 11:58:23 AM
>> Error: TypeError: browser[name] is undefined
>> Source File: resource://devtools/client/framework/gDevTools.jsm
>> Line: 160
>>
>> Timestamp: 11/15/2017 11:58:24 AM
>> Error: TypeError: menu is null
>> Source File: resource://gre/modules/commonjs/toolkit/loader.js -> 
>> resource://devtools/client/framework/browser-menus.js
>> Line: 341
>>
>>
>> When I open Facebook I get
>> Timestamp: 11/15/2017 11:58:48 AM
>> Error: :
>> Source File: https://staticxx.facebook.com/common/referer_frame.php
>> Line: 1
>>
>>
>> I later get some errors related to Image Zoom. Maybe this old plug in 
>> is causing issues?� I use it constantly - would hate to loose it. Is 
>> there a way to boot with no extensions enabled?
>>
>>
>>
>>
>> On 11/15/2017 10:20 AM, Frank-Rainer Grahl wrote:
>>> I am unable to reproduce this one too. This is likely backend storage 
>>> corruption caused by who knows what.
>>>
>>> Check https://bugzilla.mozilla.org/show_bug.cgi?id=1305624 for the 
>>> workaround.
>>>
>>> You can delete the� webappsstore.* files in your profile and it 
>>> usually works again.
>>>
>>> Open the Error Console under Tools->Web Development->Error Console 
>>> after SeaMonkey has started and filter for errors. Then open the 
>>> webpage where the passwords are not working. Look for errors. If you 
>>> don't see any just filter for warnings or remove all filters and see 
>>> if anything catches your eye.
>>>
>>> FRG
>>>
>>>
>>> Hawker wrote:
>>>> Especially the password manager lock up on opening bug that was 
>>>> introduced in 2.48 or 2.46 (I forget which) has not been fixed.
>>>
>>
> 

0
Hawker
11/15/2017 8:20:52 PM
A Williams wrote:
> To the best of my knowledge things are not that simple.
> Firefox has cast Thunderbird out into the wilderness, presumably before making those 
> changes you are so keen on.� If - this is a guess - those changes would have broken 
> Thunderbird, Firefox no longer cares.

I fail to see where I was "keen on" any changes. I was confirming and commenting on a 
broken function in the latest SM.

> Seamonkey does care - for obvious reasons.

My comment was not aimed at Seamonkey. Seamonkey Project appears to be more sinned 
against than sinner in this.

Craig


> 
> 
> cmcadams wrote:
>> Thank you. So basically the mothership doesn't care much about us, and
>> isn't communicating changes well or perhaps at all.
>>
>> Craig
>>
>>
>> Frank-Rainer Grahl wrote:
>>> autocomplete was refactored in Gecko 51 (2.48) and then again in 52
>>> (2.49). Including changing some defaults when it comes to non-secure
>>> sites. Was not fun to play catchup. There might still linger other
>>> problems.
>>>
>>> FRG
>>>
>>> cmcadams wrote:
>>>> Bingo, that fixed my modem screens login problem. But...SM was
>>>> happily enough filling most forms even with signon.autofillForms.http
>>>> set to false. And there were never problems with 1.48 with the
>>>> (presumed) same about:config settings. I'll confess I don't get it.
>>>>
>>>> Craig
>>>>
>>>>
>>>> Frank-Rainer Grahl wrote:
>>>>> Not sure if this already applies to 2.49.1.
>>>>>
>>>>> Set signon.autofillForms.http to true and see what goes.
>>>>>
>>>>> But I think FB should be https or?
>>>>>
>>>>> FRG
>>>>>
>>>>>
>>>>> David E. Ross wrote:
>>>>>> On 11/13/2017 4:32 PM, Hawker wrote:
>>>>>>> As the subject says, I just installed 2.49.1. In Facebook it still
>>>>>>> auto
>>>>>>> completes the user name but not password. After entering it still
>>>>>>> does
>>>>>>> not do it the next time.
>>>>>>> On some other sites it neither auto enters the user name or password.
>>>>>>> How can I put it back like it was?
>>>>>>>
>>>>>>
>>>>>> Windows 7 Ultimate SP1 (x64)
>>>>>> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
>>>>>> ��� SeaMonkey/2.49.1
>>>>>>
>>>>>> I have not seen this problem with saved logins.� There are some sites,
>>>>>> however, that construct their login forms in a manner that defeats the
>>>>>> saving of passwords and even defeats the use of existing saved
>>>>>> passwords.� That is a problem with the site and not with SeaMonkey.
>>>>>>
>>>>
>>
> 

0
cmcadams
11/15/2017 10:50:41 PM
On 11/15/2017 10:37 AM, David E. Ross wrote:
> On 11/15/2017 9:41 AM, Cruz, Jaime wrote:
>> On 11/14/2017 12:55 AM, David E. Ross wrote:
>>> On 11/13/2017 4:32 PM, Hawker wrote:
>>>
>>> I have not seen this problem with saved logins.  There are some sites,
>>> however, that construct their login forms in a manner that defeats the
>>> saving of passwords and even defeats the use of existing saved
>>> passwords.  That is a problem with the site and not with SeaMonkey.
>>>
>>
>> For months now, after Capital One revamped their website, neither 
>> Seamonkey nor Firefox has been able to autofill the userid or password 
>> fields.  When I click on the ID field, nothing happens.  When I click on 
>> the password field, it wants to fill it with the ID.
>>
>> However, through this entire time, Chrome has had no issues whatsoever 
>> in filling in both the ID and the password.
>>
> 
> When I see this (which is rarely), I use SeaMonkey's Password Manager to
> delete the user ID and password for the particular login.  I then
> terminate and relaunch SeaMonkey.  Having a complete list (encrypted via
> PGP) of IDs and passwords, I am then able to login to the site, entering
> and saving the ID and password anew.
> 

My procedure (quoted above) is very effective when a Web site changes
its login Web page in a way that prevents the use of saved passwords.
Too often, such a change involves a change in the domain name for the
login page.  Password Manager keys off the domain, which is why a saved
password might no longer work.

-- 
David E. Ross
<http://www.rossde.com/>

Am I the only one who noticed the following?
*  President Trump issued executive orders
   that increase health-care costs.
*  The Republicans in Congress propose to
   eliminate itemized deductions for
   health-care costs.
0
David
11/15/2017 11:40:27 PM
 > I'm not sure what all I lost so I am a tad concerned that I may have
 > lost an important setting.

Usually nothing which can't be recreated. Might be different in the 
future where extensions use the storage. Now it is usually just junk.

If it is and old profile the permissions.sqlite might have also 
contained a lot of junk too. I nuked my profile after 2.39 because the 
migration routines did a bad job then.

 > I also wish I knew how you got that file
 > form the error.

Directly from the source. The routine tries to migrate some mail image 
permissions in 2.48 to a new format for 2.49.1 and needs direct access 
to the database.

FRG


 > Hawker wrote:
> Thank you thank you thank you!
> Deleting permissions.sqlite fixed my password issue!
> Your other recommendation fixed my data manager issue.
> 
> I'm not sure what all I lost so I am a tad concerned that I may have 
> lost an important setting.� I also wish I knew how you got that file 
> form the error.
> 
> So very thankful for your help here!
> 
> On 11/15/2017 12:44 PM, Frank-Rainer Grahl wrote:
>> �> Timestamp: 11/15/2017 11:58:22 AM
>> �> Error: NS_ERROR_FILE_CORRUPTED: Component returned failure code:
>> �> 0x8052000b (NS_ERROR_FILE_CORRUPTED) [mozIStorageStatement.finalize]
>> �> Source File: resource://gre/components/nsSuiteGlue.js
>> �> Line: 422
>>
>> Your permissions.sqlite file seems to be corrupt. It now holds the 
>> permissions for logins too since 2.48 so this would explain why you 
>> are unable to autologon. But any problems should already have surfaced 
>> in 2.48.
>>
>> I would make a backup of the profile and just remove this one file and 
>> see if it works.
>> You will loose all site specific settings for cookies, image and other 
>> permissions but they can usually be recreated.
>>
>> The other errors are normal/common during startup. Ok, they should not 
>> happen but will eventually be fixed and are harmless for now.
>>
>> If removing the file does not work you can start into safe mode with 
>> Help -> Restart with Add-Ons Disabled.
>>
>> FRG
>>
>> Hawker wrote:
>>> Again thank you for your time.
>>> Removing webappsstore.sqlite seems to have fixed the password manager 
>>> lock up issue. No idea what I lost in so doing.
>>>
>>> Can you help me debug the rest of this?
>>> When first launching SM I get 4 errors: They are
>>>
>>> Timestamp: 11/15/2017 11:58:22 AM
>>> Error: NS_ERROR_FILE_CORRUPTED: Component returned failure code: 
>>> 0x8052000b (NS_ERROR_FILE_CORRUPTED) [mozIStorageStatement.finalize]
>>> Source File: resource://gre/components/nsSuiteGlue.js
>>> Line: 422
>>>
>>>
>>> Timestamp: 11/15/2017 11:58:23 AM
>>> Error: DEPRECATION WARNING: Search service falling back to 
>>> synchronous initialization. This is generally the consequence of an 
>>> add-on using a deprecated search service API.
>>> You may find more details about this deprecation at: 
>>> https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIBrowserSearchService#async_warning 
>>>
>>> resource://gre/components/nsSearchService.js 2702 
>>> SRCH_SVC__ensureInitialized
>>> resource://gre/components/nsSearchService.js 4185 get currentEngine
>>> resource://gre/components/nsSearchService.js 4178 get defaultEngine
>>> chrome://navigator/content/urlbarBindings.xml 487 updateEngines
>>> chrome://navigator/content/urlbarBindings.xml 357 
>>> autocomplete-result-popup_XBL_Constructor
>>> chrome://global/content/bindings/toolbar.xml 276 set_currentSet
>>> chrome://global/content/bindings/toolbar.xml 181 _init
>>> chrome://global/content/bindings/toolbar.xml 144 
>>> toolbar_XBL_Constructor/<
>>>
>>> Source File: resource://gre/modules/Deprecated.jsm
>>> Line: 79
>>>
>>>
>>> Timestamp: 11/15/2017 11:58:23 AM
>>> Error: TypeError: browser[name] is undefined
>>> Source File: resource://devtools/client/framework/gDevTools.jsm
>>> Line: 160
>>>
>>> Timestamp: 11/15/2017 11:58:24 AM
>>> Error: TypeError: menu is null
>>> Source File: resource://gre/modules/commonjs/toolkit/loader.js -> 
>>> resource://devtools/client/framework/browser-menus.js
>>> Line: 341
>>>
>>>
>>> When I open Facebook I get
>>> Timestamp: 11/15/2017 11:58:48 AM
>>> Error: :
>>> Source File: https://staticxx.facebook.com/common/referer_frame.php
>>> Line: 1
>>>
>>>
>>> I later get some errors related to Image Zoom. Maybe this old plug in 
>>> is causing issues?� I use it constantly - would hate to loose it. Is 
>>> there a way to boot with no extensions enabled?
>>>
>>>
>>>
>>>
>>> On 11/15/2017 10:20 AM, Frank-Rainer Grahl wrote:
>>>> I am unable to reproduce this one too. This is likely backend 
>>>> storage corruption caused by who knows what.
>>>>
>>>> Check https://bugzilla.mozilla.org/show_bug.cgi?id=1305624 for the 
>>>> workaround.
>>>>
>>>> You can delete the� webappsstore.* files in your profile and it 
>>>> usually works again.
>>>>
>>>> Open the Error Console under Tools->Web Development->Error Console 
>>>> after SeaMonkey has started and filter for errors. Then open the 
>>>> webpage where the passwords are not working. Look for errors. If you 
>>>> don't see any just filter for warnings or remove all filters and see 
>>>> if anything catches your eye.
>>>>
>>>> FRG
>>>>
>>>>
>>>> Hawker wrote:
>>>>> Especially the password manager lock up on opening bug that was 
>>>>> introduced in 2.48 or 2.46 (I forget which) has not been fixed.
>>>>
>>>
>>
> 

0
Frank
11/16/2017 8:08:44 AM
David E. Ross wrote:
> On 11/15/2017 10:37 AM, David E. Ross wrote:
>> On 11/15/2017 9:41 AM, Cruz, Jaime wrote:
>>> On 11/14/2017 12:55 AM, David E. Ross wrote:
>>>
>>> For months now, after Capital One revamped their website, neither
>>> Seamonkey nor Firefox has been able to autofill the userid or password
>>> fields.  When I click on the ID field, nothing happens.  When I click on
>>> the password field, it wants to fill it with the ID.
>>>
>>> However, through this entire time, Chrome has had no issues whatsoever
>>> in filling in both the ID and the password.
>>>
>>
>> When I see this (which is rarely), I use SeaMonkey's Password Manager to
>> delete the user ID and password for the particular login.  I then
>> terminate and relaunch SeaMonkey.  Having a complete list (encrypted via
>> PGP) of IDs and passwords, I am then able to login to the site, entering
>> and saving the ID and password anew.
>>
>
> My procedure (quoted above) is very effective when a Web site changes
> its login Web page in a way that prevents the use of saved passwords.
> Too often, such a change involves a change in the domain name for the
> login page.  Password Manager keys off the domain, which is why a saved
> password might no longer work.
>

But when a site changes its domain, and you reenter your userid and 
password it is usually "remembered" for the new domain and you now have 
two entries for (what you believe) is the same site.  This isn't the 
case.  No matter how many times you enter your ID and password on the 
Capital One login page, it is NEVER remembered.

-- 
Jaime A. Cruz
President
Nassau Wings Motorcycle Club
http://www.nassauwings.org/

AMA District 34
http://www.AMADistrict34.com/
Freddy's Run
http://www.freddysrun.org/
0
Cruz
11/16/2017 1:10:47 PM
On 11/16/2017 5:10 AM, Cruz, Jaime wrote:
> David E. Ross wrote:
>> On 11/15/2017 10:37 AM, David E. Ross wrote:
>>> On 11/15/2017 9:41 AM, Cruz, Jaime wrote:
>>>> On 11/14/2017 12:55 AM, David E. Ross wrote:
>>>>
>>>> For months now, after Capital One revamped their website, neither
>>>> Seamonkey nor Firefox has been able to autofill the userid or password
>>>> fields.  When I click on the ID field, nothing happens.  When I click on
>>>> the password field, it wants to fill it with the ID.
>>>>
>>>> However, through this entire time, Chrome has had no issues whatsoever
>>>> in filling in both the ID and the password.
>>>>
>>>
>>> When I see this (which is rarely), I use SeaMonkey's Password Manager to
>>> delete the user ID and password for the particular login.  I then
>>> terminate and relaunch SeaMonkey.  Having a complete list (encrypted via
>>> PGP) of IDs and passwords, I am then able to login to the site, entering
>>> and saving the ID and password anew.
>>>
>>
>> My procedure (quoted above) is very effective when a Web site changes
>> its login Web page in a way that prevents the use of saved passwords.
>> Too often, such a change involves a change in the domain name for the
>> login page.  Password Manager keys off the domain, which is why a saved
>> password might no longer work.
>>
> 
> But when a site changes its domain, and you reenter your userid and 
> password it is usually "remembered" for the new domain and you now have 
> two entries for (what you believe) is the same site.  This isn't the 
> case.  No matter how many times you enter your ID and password on the 
> Capital One login page, it is NEVER remembered.
> 

Then obviously the problem is with Capital One and not with SeaMonkey.

-- 
David E. Ross
<http://www.rossde.com/>

Am I the only one who noticed the following?
*  President Trump issued executive orders
   that increase health-care costs.
*  The Republicans in Congress propose to
   eliminate itemized deductions for
   health-care costs.
0
David
11/16/2017 3:37:43 PM
David E. Ross wrote on 11/16/2017 10:37 AM:
> On 11/16/2017 5:10 AM, Cruz, Jaime wrote:
>> David E. Ross wrote:
>>> On 11/15/2017 10:37 AM, David E. Ross wrote:
>>>> On 11/15/2017 9:41 AM, Cruz, Jaime wrote:
>>>>> On 11/14/2017 12:55 AM, David E. Ross wrote:
>>>>>
>>>>> For months now, after Capital One revamped their website, neither
>>>>> Seamonkey nor Firefox has been able to autofill the userid or password
>>>>> fields.  When I click on the ID field, nothing happens.  When I click on
>>>>> the password field, it wants to fill it with the ID.
>>>>>
>>>>> However, through this entire time, Chrome has had no issues whatsoever
>>>>> in filling in both the ID and the password.
>>>>>
>>>>
>>>> When I see this (which is rarely), I use SeaMonkey's Password Manager to
>>>> delete the user ID and password for the particular login.  I then
>>>> terminate and relaunch SeaMonkey.  Having a complete list (encrypted via
>>>> PGP) of IDs and passwords, I am then able to login to the site, entering
>>>> and saving the ID and password anew.
>>>>
>>>
>>> My procedure (quoted above) is very effective when a Web site changes
>>> its login Web page in a way that prevents the use of saved passwords.
>>> Too often, such a change involves a change in the domain name for the
>>> login page.  Password Manager keys off the domain, which is why a saved
>>> password might no longer work.
>>>
>>
>> But when a site changes its domain, and you reenter your userid and
>> password it is usually "remembered" for the new domain and you now have
>> two entries for (what you believe) is the same site.  This isn't the
>> case.  No matter how many times you enter your ID and password on the
>> Capital One login page, it is NEVER remembered.
>>
>
> Then obviously the problem is with Capital One and not with SeaMonkey.

My Capital One credit card user name and password are filled in using 
Firefox but not Seamonkey 2.46

-- 

Rick C
0
rickman
11/16/2017 4:26:37 PM
David E. Ross wrote:
> On 11/16/2017 5:10 AM, Cruz, Jaime wrote:
>> David E. Ross wrote:
>>> On 11/15/2017 10:37 AM, David E. Ross wrote:
>>>> On 11/15/2017 9:41 AM, Cruz, Jaime wrote:
>>>>> On 11/14/2017 12:55 AM, David E. Ross wrote:
>>>>>
>>>>> For months now, after Capital One revamped their website, neither
>>>>> Seamonkey nor Firefox has been able to autofill the userid or password
>>>>> fields.  When I click on the ID field, nothing happens.  When I click on
>>>>> the password field, it wants to fill it with the ID.
>>>>>
>>>>> However, through this entire time, Chrome has had no issues whatsoever
>>>>> in filling in both the ID and the password.
>>>>>
>>>>
>>>> When I see this (which is rarely), I use SeaMonkey's Password Manager to
>>>> delete the user ID and password for the particular login.  I then
>>>> terminate and relaunch SeaMonkey.  Having a complete list (encrypted via
>>>> PGP) of IDs and passwords, I am then able to login to the site, entering
>>>> and saving the ID and password anew.
>>>>
>>>
>>> My procedure (quoted above) is very effective when a Web site changes
>>> its login Web page in a way that prevents the use of saved passwords.
>>> Too often, such a change involves a change in the domain name for the
>>> login page.  Password Manager keys off the domain, which is why a saved
>>> password might no longer work.
>>>
>>
>> But when a site changes its domain, and you reenter your userid and
>> password it is usually "remembered" for the new domain and you now have
>> two entries for (what you believe) is the same site.  This isn't the
>> case.  No matter how many times you enter your ID and password on the
>> Capital One login page, it is NEVER remembered.
>>
>
> Then obviously the problem is with Capital One and not with SeaMonkey.
>

Then why does it work with Chrome??

-- 
Jaime A. Cruz
President
Nassau Wings Motorcycle Club
http://www.nassauwings.org/

AMA District 34
http://www.AMADistrict34.com/
Freddy's Run
http://www.freddysrun.org/
0
Cruz
11/17/2017 1:22:54 AM
rickman wrote:
> David E. Ross wrote on 11/16/2017 10:37 AM:
>> On 11/16/2017 5:10 AM, Cruz, Jaime wrote:
>>> David E. Ross wrote:
>>>> On 11/15/2017 10:37 AM, David E. Ross wrote:
>>>>> On 11/15/2017 9:41 AM, Cruz, Jaime wrote:
>>>>>> On 11/14/2017 12:55 AM, David E. Ross wrote:
>>>>>>
>>>>>> For months now, after Capital One revamped their website, neither
>>>>>> Seamonkey nor Firefox has been able to autofill the userid or
>>>>>> password
>>>>>> fields.  When I click on the ID field, nothing happens.  When I
>>>>>> click on
>>>>>> the password field, it wants to fill it with the ID.
>>>>>>
>>>>>> However, through this entire time, Chrome has had no issues
>>>>>> whatsoever
>>>>>> in filling in both the ID and the password.
>>>>>>
>>>>>
>>>>> When I see this (which is rarely), I use SeaMonkey's Password
>>>>> Manager to
>>>>> delete the user ID and password for the particular login.  I then
>>>>> terminate and relaunch SeaMonkey.  Having a complete list
>>>>> (encrypted via
>>>>> PGP) of IDs and passwords, I am then able to login to the site,
>>>>> entering
>>>>> and saving the ID and password anew.
>>>>>
>>>>
>>>> My procedure (quoted above) is very effective when a Web site changes
>>>> its login Web page in a way that prevents the use of saved passwords.
>>>> Too often, such a change involves a change in the domain name for the
>>>> login page.  Password Manager keys off the domain, which is why a saved
>>>> password might no longer work.
>>>>
>>>
>>> But when a site changes its domain, and you reenter your userid and
>>> password it is usually "remembered" for the new domain and you now have
>>> two entries for (what you believe) is the same site.  This isn't the
>>> case.  No matter how many times you enter your ID and password on the
>>> Capital One login page, it is NEVER remembered.
>>>
>>
>> Then obviously the problem is with Capital One and not with SeaMonkey.
>
> My Capital One credit card user name and password are filled in using
> Firefox but not Seamonkey 2.46
>

Which version of Firefox?  It doesn't work with the current ESR version.

-- 
Jaime A. Cruz
President
Nassau Wings Motorcycle Club
http://www.nassauwings.org/

AMA District 34
http://www.AMADistrict34.com/
Freddy's Run
http://www.freddysrun.org/
0
Cruz
11/17/2017 1:23:32 AM
On 11/16/17 8:22 PM, Cruz, Jaime wrote:
> David E. Ross wrote:
>> On 11/16/2017 5:10 AM, Cruz, Jaime wrote:
>>> David E. Ross wrote:
>>>> On 11/15/2017 10:37 AM, David E. Ross wrote:
>>>>> On 11/15/2017 9:41 AM, Cruz, Jaime wrote:
>>>>>> On 11/14/2017 12:55 AM, David E. Ross wrote:
>>>>>>
>>>>>> For months now, after Capital One revamped their website, neither
>>>>>> Seamonkey nor Firefox has been able to autofill the userid or 
>>>>>> password
>>>>>> fields.  When I click on the ID field, nothing happens.  When I 
>>>>>> click on
>>>>>> the password field, it wants to fill it with the ID.
>>>>>>
>>>>>> However, through this entire time, Chrome has had no issues 
>>>>>> whatsoever
>>>>>> in filling in both the ID and the password.
>>>>>>
>>>>>
>>>>> When I see this (which is rarely), I use SeaMonkey's Password 
>>>>> Manager to
>>>>> delete the user ID and password for the particular login.  I then
>>>>> terminate and relaunch SeaMonkey.  Having a complete list 
>>>>> (encrypted via
>>>>> PGP) of IDs and passwords, I am then able to login to the site, 
>>>>> entering
>>>>> and saving the ID and password anew.
>>>>>
>>>>
>>>> My procedure (quoted above) is very effective when a Web site changes
>>>> its login Web page in a way that prevents the use of saved passwords.
>>>> Too often, such a change involves a change in the domain name for the
>>>> login page.  Password Manager keys off the domain, which is why a saved
>>>> password might no longer work.
>>>>
>>>
>>> But when a site changes its domain, and you reenter your userid and
>>> password it is usually "remembered" for the new domain and you now have
>>> two entries for (what you believe) is the same site.  This isn't the
>>> case.  No matter how many times you enter your ID and password on the
>>> Capital One login page, it is NEVER remembered.
>>>
>>
>> Then obviously the problem is with Capital One and not with SeaMonkey.
>>
> 
> Then why does it work with Chrome??
> 


Because Capital One recognizes Chrome as a Major browser.

-- 
Less than three months until Valentine's Day
Coexist <https://www.coexist.org/>
National Popular Vote <http://www.nationalpopularvote.com/>
Ubuntu 16.04LTS - Unity Desktop
0
WaltS48
11/17/2017 1:34:55 AM
Cruz, Jaime wrote on 11/16/2017 8:23 PM:
> rickman wrote:
>> David E. Ross wrote on 11/16/2017 10:37 AM:
>>> On 11/16/2017 5:10 AM, Cruz, Jaime wrote:
>>>> David E. Ross wrote:
>>>>> On 11/15/2017 10:37 AM, David E. Ross wrote:
>>>>>> On 11/15/2017 9:41 AM, Cruz, Jaime wrote:
>>>>>>> On 11/14/2017 12:55 AM, David E. Ross wrote:
>>>>>>>
>>>>>>> For months now, after Capital One revamped their website, neither
>>>>>>> Seamonkey nor Firefox has been able to autofill the userid or
>>>>>>> password
>>>>>>> fields.  When I click on the ID field, nothing happens.  When I
>>>>>>> click on
>>>>>>> the password field, it wants to fill it with the ID.
>>>>>>>
>>>>>>> However, through this entire time, Chrome has had no issues
>>>>>>> whatsoever
>>>>>>> in filling in both the ID and the password.
>>>>>>>
>>>>>>
>>>>>> When I see this (which is rarely), I use SeaMonkey's Password
>>>>>> Manager to
>>>>>> delete the user ID and password for the particular login.  I then
>>>>>> terminate and relaunch SeaMonkey.  Having a complete list
>>>>>> (encrypted via
>>>>>> PGP) of IDs and passwords, I am then able to login to the site,
>>>>>> entering
>>>>>> and saving the ID and password anew.
>>>>>>
>>>>>
>>>>> My procedure (quoted above) is very effective when a Web site changes
>>>>> its login Web page in a way that prevents the use of saved passwords.
>>>>> Too often, such a change involves a change in the domain name for the
>>>>> login page.  Password Manager keys off the domain, which is why a saved
>>>>> password might no longer work.
>>>>>
>>>>
>>>> But when a site changes its domain, and you reenter your userid and
>>>> password it is usually "remembered" for the new domain and you now have
>>>> two entries for (what you believe) is the same site.  This isn't the
>>>> case.  No matter how many times you enter your ID and password on the
>>>> Capital One login page, it is NEVER remembered.
>>>>
>>>
>>> Then obviously the problem is with Capital One and not with SeaMonkey.
>>
>> My Capital One credit card user name and password are filled in using
>> Firefox but not Seamonkey 2.46
>>
>
> Which version of Firefox?  It doesn't work with the current ESR version.

Firefox auto-updates.  56.0.2 and it is asking me to update to 57.0

-- 

Rick C
0
rickman
11/17/2017 2:12:11 AM
Reply: