Closed Bug 119969 Opened 23 years ago Closed 16 years ago

Confusing lock icon behavior when downloading a crl over ssl.

Categories

(Core Graveyard :: Security: UI, defect, P2)

x86
Windows 2000
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME
mozilla1.9alpha1

People

(Reporter: ssaux, Assigned: KaiE)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [kerh-coa])

Attachments

(1 obsolete file)

To reproduce:

1) load an insecure page (say bugzilla.mozilla.org). Lock icon is open.
2) copy and paste
https://www.thawte.com/cgi/lifecycle/getcrl.crl?skeyid=sd%84%e6m%7blI%bds%3d%5d%e0%d9%19%84%12Ip%a2
(or just clicking might also trigger the bug, I'm not sure).
3) you get a lock icon, even though the page displayed remains the old one.

enter a bug number and submit the form, you get the "leaving secure site" dialog
box.

What should the proper behavior be?  Is this even a bug?
The lock icon agrees with the URL box, but it's faulty to assume that the page
content displayed is secure.
Ok so if you click on the link (rather than copy and paste it in the url box),
the lock icon disagrees with both the content displayed and the url.

Priority: -- → P2
Target Milestone: --- → 2.2
see also bug 118328.
Blocks: lockicon
Keywords: nsbeta1
-> me
Assignee: rangansen → kaie
Keywords: nsbeta1nsbeta1+
Target Milestone: 2.2 → 2.4
The special case we have here is a URL that produces a document that will not be
shown in the content area, but will be handled by a separate content handler.

When I tested this special case, I saw we received notifications with the
additional flag 
  LOAD_RETARGETED_DOCUMENT_URI


I understand that a START + LOAD_DOCUMENT_URI notification will be sent, before
it is known that retargeting will happen.

However, is it safe to assume, 
- START + LOAD_DOCUMENT_URI
- no notifications for any sub content prior to:
- LOAD_RETARGETED_DOCUMENT_URI
- now notifications for sub content could arrive
  (although I'd ideally assume, they won't arrive in our window at all)

If we can assume the above, fixing this bug would be simple.
After having received the
  LOAD_RETARGETED_DOCUMENT_URI
we would simply ignore any events, until we see
  STOP + LOAD_DOCUMENT_URI

Well, at least we will have to ignore them for setting the lock icon.
We will however, still require to show some security state transition warnings,
if enabled.

However, if we are going to show security transition warnings, those warnings
must be treated as being "isolated" from the shown content (previous content of
the window), since the new URL doesn't replace it, and since we are not updating
the shown lock icon.

That is, while we show a warning, the next event that will happen in the
unchanged document window, will behave as if the CRL would have never been
loaded. The check, whether a transition is being made, will be based on the
security shown window content and the shown lock icon.
Kai, I'm not really up on the progress notifications angle of things yet... what
you describe sounds reasonable, but Darin or Adam should know more about it...
While working on a related issues, I today had a chat with bz, and I learned
there is a much simpler approach to fixing this bug.

Please correct me, but I think the following is true:
- whenever a "toplevel" document gets loaded, 
  that causes different content to be shown in the content
  area, nsIWebProgressListener::OnLocationChange
  gets called

- the call to OnLocationChange will happen early in the process
  of loading the document, before the final STOP notifications
  are sent out to nsIWebProgressListener::OnStateChange

- when downloading a CRL (or a zip) that does get shown in the content
  are, OnLocationChange does not get called! (that's good)

With this new knowledge, I'm suggesting the following approach, which seems to
work for me (patch coming up):

- the lock icon tracking code already recognizes when a load starts
- whenever a new load starts, set a flag which says
  "we do not yet know whether the load will change the location of the
   shown document"
- when we received OnLocationChange,
  set that flag to "we now know this load will change the location"
- continue to track all security states
- when it is time to check for updating the lock icon,
  only change the lock icon and the state,
  if we know the location changes


Before we check this patch in, we should do careful testing.
Status: NEW → ASSIGNED
Attached patch Patch v1 (obsolete) — Splinter Review
Comment on attachment 119460 [details] [diff] [review]
Patch v1

Sorry, this patch is too simple.

This patch would cause bug 154240 to appear again...
Attachment #119460 - Attachment is obsolete: true
Attachment #119460 - Flags: review-
Keywords: nsbeta1+nsbeta1
Product: PSM → Core
This is now WORKSFORME (with Mozilla trunk).
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Oops, sorry, reopening!

Here is a new test case: (I copied a CRL from Thawte to my server to make it downlaodable using https)

https://kuix.de/misc/test49/BTClass1Individual.crl
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
However, the latest patch in bug 62178 fixes this bug, I just tested.
Depends on: 62178
Whiteboard: [kerh-coa]
Target Milestone: psm2.4 → mozilla1.9alpha
QA Contact: junruh → ui
Version: psm2.2 → 1.0 Branch
Version: 1.0 Branch → Trunk
This is WORKSFORME.

- go to a plain text site
- go to https://kuix.de/misc/test49/BTClass1Individual.crl
- cancel the crl import

The initial page still is still shown as a plain page.

I remember this got fixed a while ago.
Status: REOPENED → RESOLVED
Closed: 19 years ago16 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: