Open Bug 379803 Opened 18 years ago Updated 2 years ago

Give content policies information about user initiated action

Categories

(Core :: DOM: Security, defect, P5)

defect

Tracking

()

UNCONFIRMED

People

(Reporter: sicking, Unassigned)

References

Details

(Whiteboard: [domsecurity-backlog])

It would be great if contentpolicy implementations got information on if the load was initiated by a user or not. One use for this is to block external protocol handlers for page loads if the load was not initiated by the user. We should be able to reuse the popup blocking code for this.
We'd need to expose the current popup blocking state on some service, then (which I think we should do). Some of the content policy checks are done from JS, which can't get at the popup blocking state. That would incidentally allow embeddors access to the popup blocking state too, which I think is a good idea.
Necko doesn't do content policy stuff.
Assignee: nobody → general
Component: Networking → DOM
QA Contact: networking → ian
Blocks: 167475
Assignee: general → nobody
QA Contact: ian → general
Whiteboard: [fingerprinting]
Chris, Do we still need to fix this bug? Should we close it?
Component: DOM → DOM: Security
Flags: needinfo?(ckerschb)
Whiteboard: [fingerprinting] → [fingerprinting] [fp-triaged]
(In reply to Ethan Tseng [:ethan] - 57 Regression Engineering Support from comment #3) > Chris, > Do we still need to fix this bug? Should we close it? In theory that still sounds interesting to me, but I guess it has to go in the backlog.
Status: NEW → UNCONFIRMED
Ever confirmed: false
Flags: needinfo?(ckerschb)
Priority: -- → P5
Whiteboard: [fingerprinting] [fp-triaged] → [fingerprinting] [fp-triaged][domsecurity-backlog]
Whiteboard: [fingerprinting] [fp-triaged][domsecurity-backlog] → [fingerprinting][domsecurity-backlog]
Whiteboard: [fingerprinting][domsecurity-backlog] → [domsecurity-backlog]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.