If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Secure Link Appears to "Break" During Session



Core Graveyard
Security: UI
16 years ago
a year ago


(Reporter: dan.m, Assigned: kaie)


1.0 Branch
Mac OS X

Firefox Tracking Flags

(Not tracked)





16 years ago
I can't give you access to my secure pages for obvious reasons, but you may want
to verify with the web master that they are using the correct flavor of SSL and
other complimentary technologies, because this is serious sh*t if something
isn't working right....

Here's what happens to me using build 2002052918

1. Go to NF web site, choose the login prompt
2. Secure login page loads
3. I type in my name and pass, and then sumbit them
4. Browser stays in secure status (Golden Locket), while it processes this
5. Eventually get a listing of accounts, with viewing options (still secure)
6. As soon as I click the "Transfer" option in the sidebar, and select one of my
accounts, I get a Red Locket with a crack in it. This doesn't go away as I move
to other pages....

This does NOT happen with IE 5.1x, so I'm thinking it's Mozilla rather than the
site itself.

Comment 1

16 years ago
dmoughamian, when you access that page, what does the Page Info/Security
information look like?

Comment 2

16 years ago
After re-attempting this, I think I know what's causing the locket to "break". I
notice that while loading secure pages with a lot of data, the throbber
continues to animate indefinitely even after the page is in memory. If you click
stop during this time, the locket "breaks". 

What happens is, I wait until everything is loaded on screen (knowing that each
page takes roughly the same amount of time to load), then wait another 20
seconds or so to be sure, then click "Stop".

I think this may have been what happened to me earlier. I'm so used to hitting
the stop button on certain sites (Amazon, banking stuff, etc.) that I don't even
register it as a "step" in my thinking / reporting. Maybe this bug has more to
do with the stop function than any security related issues, but it's worth
looking into.

Also, not sure if it could have an effect but I have Pipelining enabled as well.

I still see no reason why hitting stop would cause a broken locket on a secure
site (assuming you wait for everything to load). Doing so under IE does not
cause its locket to break. 

As for the Security Info panel, I didn't see any error messages, just a basic
description of the fact that I had loaded a secure page....

Comment 3

16 years ago
dmoughamian, builds of that vintage had an SSL bug (bug 147979) that you might
be encountering. Try a more recent nightly.
I think this has been fixed, reassigning to PSM for confirmation.
Assignee: mstoltz → ssaux
Component: Security: General → Client Library
Product: Browser → PSM
QA Contact: bsharma → junruh
Version: other → 2.3

Comment 5

15 years ago
kai for investigation.
Assignee: ssaux → kaie

Comment 6

15 years ago
dmoughamian@earthlink.net, can you reproduce this with pipelining disabled?

Comment 7

15 years ago

No. On 1.1b, this does not seem to occur with pipelining disabled. That is,
clicking stop during a page load doesn't kill the locket.

Comment 8

15 years ago
dmoughamian: I believe what you see is bug 140836. Although bug 140836 says
"clicking early" this triggers the same kind of interruption that happens when
you click stop.

Bug 140836 has been fixed on both the 1.0 branch and the trunk from 6/25. Please
try out a more recent build, your build is more than 2 months old.

The bug should not occur in 1.1b, regardless of the pipelining setting.

I'm marking this as a duplicate. Please re-open if you can reproduce with a
build newer than 2002-06-25. Thanks!

*** This bug has been marked as a duplicate of 140836 ***
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 9

15 years ago
Verified dupe.


13 years ago
Component: Security: UI → Security: UI
Product: PSM → Core


9 years ago
Version: psm2.3 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.