Last Comment Bug 268483 - Lock icon appears even though http connection failed.
: Lock icon appears even though http connection failed.
Status: VERIFIED FIXED
[sg:fix]
: fixed-aviary1.0.1, fixed1.7.6
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: Trunk
: All All
: -- critical (vote)
: mozilla1.8beta1
Assigned To: Darin Fisher
:
Mentors:
https://calmail.berkeley.edu:993/
: 270676 280461 (view as bug list)
Depends on:
Blocks: lockicon 248511 sg-ff101 sg-moz176
  Show dependency treegraph
 
Reported: 2004-11-08 15:33 PST by Doug Turner (:dougt)
Modified: 2006-03-12 18:08 PST (History)
8 users (show)
dveditz: blocking1.7.6+
dveditz: blocking‑aviary1.0.1+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
v1 patch - remove offending block of code (2.26 KB, patch)
2004-12-28 12:06 PST, Darin Fisher
cbiesinger: review+
Details | Diff | Review
v2 patch (2.34 KB, patch)
2004-12-28 14:21 PST, Darin Fisher
cbiesinger: review+
bzbarsky: superreview+
dveditz: approval‑aviary1.0.1+
dveditz: approval1.7.6+
Details | Diff | Review
patch for 1.4 branch (2.35 KB, patch)
2005-06-28 23:40 PDT, Nian Liu(n/a in a long time)
cbiesinger: review+
bzbarsky: superreview+
Details | Diff | Review

Description Doug Turner (:dougt) 2004-11-08 15:33:52 PST
steps to reproduce:

1.  Go to http://mozilla.org
2.  Go to a https server that doesn't speak https.  For example, a https imap
server.

expected result:

an error dialog and the content of the page shouldn't change.  most importantly,
the security of the page should remain the same -- lock icon unlocked.

actual result:

i see an error dialog, but then the lock icon is locked and the details in the
page security dialog suggest that www.mozilla.org has been verified.

marking security sensitive per conversation with darin
Comment 1 Daniel Veditz [:dveditz] 2004-11-18 14:11:25 PST
*** Bug 270676 has been marked as a duplicate of this bug. ***
Comment 2 Darin Fisher 2004-12-28 11:26:56 PST
I found a public secure IMAP server that can be used to demonstrate this bug:
https://calmail.berkeley.edu:993/

Load that link, and then press the STOP button.  You should see the address bar
change to the locked state for the calmail server even though the page content
hasn't changed.  The choice of the STOP button is not special... any error
condition would likely yield the same result.
Comment 3 Darin Fisher 2004-12-28 12:05:56 PST
I believe this bug is a result of the patch for bug 148981.  I think it may be
wrong to synthesize a STATE_TRANSFERRING event when the status of the request is
a failure code and when it has not already transferred some data (the only case
where we would be synthesizing STATE_TRANSFERRING).

That patch was added in 2002 by rpotts, and I later added a further condition
that we skip that block of code when the status code is
NS_ERROR_BINDING_RETARGETED to fix security bug 257308.  Now, I think we should
just remove that block of code.

Patch coming up...
Comment 4 Darin Fisher 2004-12-28 12:06:46 PST
Created attachment 169740 [details] [diff] [review]
v1 patch - remove offending block of code
Comment 5 Darin Fisher 2004-12-28 12:10:46 PST
BTW, the reason why "httpChannel->GetResponseStatus(...)" was succeeding was
because we treated the text from the IMAP server as a HTTP/0.9 response (i.e., a
HTTP response with no status line or response headers).
Comment 6 Darin Fisher 2004-12-28 13:17:08 PST
biesi raised an interesting point over irc:

It seems that this patch works because the HTTP channel's direct listener is not
the URI loader but rather an unknown content decoder.  It suppresses the ODA
because it is trying to figure out what sort of content the stream contains.

Perhaps it would make more sense to check if the request has been targeted or
not in place of the block of code I removed.  Only a targeted request (one with
the nsIChannel::LOAD_TARGETED load flag set) should trigger STATE_TRANSFERRING
(I think).  I might give that a try instead...
Comment 7 Darin Fisher 2004-12-28 14:21:21 PST
Created attachment 169752 [details] [diff] [review]
v2 patch

alternate patch.
Comment 8 Christian :Biesinger (don't email me, ping me on IRC) 2004-12-28 14:55:29 PST
Comment on attachment 169752 [details] [diff] [review]
v2 patch

yeah... I think this is a better approach. I still wonder why the data just
disappears, though...

anyway, r=biesi.
Comment 9 Darin Fisher 2004-12-28 15:11:45 PST
it doesn't dissappear... instead it is stuck inside the unknown decoder's
internal buffer.  the decoder is waiting for the next ODA, but instead it gets
an OnStopRequest w/ status=NS_BINDING_ABORTED.  thus, the data is never pushed
to the final stream listener.
Comment 10 Boris Zbarsky [:bz] (Out June 25-July 6) 2004-12-29 15:22:35 PST
Comment on attachment 169752 [details] [diff] [review]
v2 patch

sr=bzbarsky
Comment 11 Darin Fisher 2004-12-30 10:14:13 PST
fixed-on-trunk

dougt, is there any way you can verify the fix?
Comment 12 Daniel Veditz [:dveditz] 2005-01-24 14:02:51 PST
Shouldn't this be ported back to the branches?
Comment 13 Daniel Veditz [:dveditz] 2005-02-08 16:36:02 PST
Comment on attachment 169752 [details] [diff] [review]
v2 patch

a=dveditz
Comment 14 Darin Fisher 2005-02-08 18:17:58 PST
*** Bug 280461 has been marked as a duplicate of this bug. ***
Comment 15 Jay Patel [:jay] 2005-02-18 14:33:46 PST
Verified Fixed.  Test case with https://calmail.berkeley.edu:993/ no longer
displays yellow background and lock icon when the page load is stopped.

M18b1/Trunk: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217

Aviary 1.0.1 Branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20050218 Firefox/1.0

M176 Branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050217

Based on my testing, it looks like this has been fixed everywhere.
Comment 16 Nian Liu(n/a in a long time) 2005-06-28 23:40:05 PDT
Created attachment 187613 [details] [diff] [review]
patch for 1.4 branch

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