Assignee: nobody → general
Component: Security → DOM: Mozilla Extensions
Product: Firefox → Core
QA Contact: firefox → ian
Version: unspecified → 1.7 Branch
I'm not sure how our lock icon works... I think any time an insecure request is added to the loadgroup, the icon should change to mixed/unencrypted.
(In reply to comment #1) > I'm not sure how our lock icon works... I think any time an insecure request is > added to the loadgroup, the icon should change to mixed/unencrypted. The UI should definitely change to mixed in this case.
Status: UNCONFIRMED → NEW
Component: DOM: Mozilla Extensions → Web Services
Ever confirmed: true
Is this a matter of us not changing the lock icon after onload has fired? I seem to recall something like that, but maybe I'm wrong?
We update the lock icon whenever we see a STATE_TRANSFERRING WPL event. I think WPL events are suppressed for LOAD_BACKGROUND content, so we should make sure that LOAD_BACKGROUND isn't the culprit. Reporter: can you post a sample page that demonstrates the problem? Or, can you provide further details on how you've managed to work around the lock icon?
Could you please provide a testcase?
Keeping this bug hidden doesn't protect users, so I'm making it public.
Ah, for XMLHttpRequest we certainly use LOAD_BACKGROUND... We also use it for background images. Does that mean that insecure background images won't trigger the broken lock icon?
Yes, see bug 305284.
12 years ago
Depends on: 305284
Summary: AJAX pages can load insecure content without user noticing → AJAX pages can load insecure content without user noticing (avoiding mixed content warning)
Assignee: general → nobody
Component: Web Services → DOM
QA Contact: ian → general
Version: 1.7 Branch → unspecified
Assigning to me, to track this bug.
Assignee: nobody → honzab.moz
it sounds like the work involved is probably in security ui (the wpl) and not dom (since it presumably does add the requests to the loadgroup, albeit w/ LOAD_BACKGROUND).
Component: DOM → Security: UI
QA Contact: general → ui
The point is that necko sends no notifications to _anyone_ about LOAD_BACKGROUND loads. So the security UI can't really do much about them.
I have plans to change the way we collect (in)security state of all requests inside a load group. So, it's gonna work also for background requests, while those are added to the same load group.
Releasing this, but still on my radar. I would like to get this later back again.
Assignee: honzab.moz → nobody
Tanvi, didn't you just fix this with nsMixedContentBlocker?
(In reply to Brian Smith (:bsmith) from comment #16) > Tanvi, didn't you just fix this with nsMixedContentBlocker? Yes, this should be fixed by the patches in bug 822367 and bug 782654.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.