The default bug view has changed. See this FAQ.

Call ShouldProcess in all cases for <object>

RESOLVED FIXED in mozilla17

Status

()

Core
DOM
RESOLVED FIXED
12 years ago
5 years ago

People

(Reporter: Biesinger, Assigned: johns)

Tracking

({sec-want})

Trunk
mozilla17
sec-want
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:want P5])

<object> (and <embed>, <applet>) should call nsIContentPolicy::ShouldProcess.
needs sorting out whether it should call that itself or whether
LoadImageWithChannel etc should do that.

Comment 1

10 years ago
This is needed in order for NoScript to soundly block particular plugins, isn't it?  The mime type guess passed to ShouldLoad could be application/x-shockwave-flash for something that isn't ultimately treated as Flash, and vice versa.
Whiteboard: [sg:want P4]

Comment 2

10 years ago
NoScript contains a hack to work around the lack of a shouldProcess call:

<mao> I use a webprogress listener and brutally block the loading in particular circumnstances (i.e. when shouldLoad() and shouldProcess() may be fooled)

It would be better if NoScript didn't need that hack, of course.
Whiteboard: [sg:want P4] → [sg:want P5]
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+

Updated

10 years ago
Flags: blocking1.9+ → blocking1.9-
Whiteboard: [sg:want P5] → [sg:want P5][wanted-1.9]
Note that I'm adding such a call in bug 393503.  It doesn't get called for all the various plugin cases, however....
Depends on: 393503
Flags: wanted1.9+
Whiteboard: [sg:want P5][wanted-1.9] → [sg:want P5]
QA Contact: ian → general

Updated

7 years ago
Flags: blocking1.9.0.19?

Comment 4

7 years ago
add to Keywords: privacy
Flags: blocking1.9.0.19?

Comment 5

6 years ago
The Tor Project / Electronic Frontier Foundation is paying to have this bug
fixed.

"If you know C++ and/or Firefox internals, we should be able to pay you for
your time to address these issues and shepherd the relevant patches through
Mozilla's review process."

Source:
https://blog.torproject.org/blog/web-developers-and-firefox-hackers-help-us-firefox-4

Updated

6 years ago
tracking-firefox5: --- → ?
tracking-firefox6: --- → ?

Updated

6 years ago
Flags: blocking1.9-
Clearing the noms - old bug nominated for tracking without justification. Please be careful with flags.
tracking-firefox5: ? → ---
tracking-firefox6: ? → ---
Keywords: sec-want
(Assignee)

Comment 7

5 years ago
bug 781126 should fix this

After that lands the behavior is
1) [if using channel] Call shouldLoad() with the best-guess type prior to opening channel
2) Call shouldLoad() again with final type
3) Call shouldProcess() with final type

#2 wouldn't be necessary except for bug 380556
Assignee: cbiesinger → jschoenick
Status: NEW → ASSIGNED
Depends on: 781126
No longer depends on: 393503
(Assignee)

Comment 8

5 years ago
Actually I lied. The behavior is

1) [if using channel] Call shouldLoad() up to three times with all possibly-supported types (document/image/object) to see if there's any type that would be allowed from the channel
2) Call shouldLoad again with final type
3) Call shouldProcess with final type

Additionally, for plugins without URIs, we call shouldLoad() and shouldProcess() using the document's URI and TYPE_OBJECT

#1 Might be simplified by using TYPE_REFRESH or something similar, but that is not fully implemented
#2 wouldn't be necessary except for bug 380556

However, overall, it should be much simpler for implementers of content policy to handle this - just returning the right thing in shouldLoad() and shouldProcess() should work as expected
(Assignee)

Comment 9

5 years ago
Bug 781126 ended up landing with a much more proper fix, so ignore the above comments.

- We call shouldLoad(TYPE_OBJECT) before opening a channel
- We call shouldProcess(ACTUAL_TYPE) before instantiating a plugin/image/subdocument. If there is no channel, only shouldProcess gets called.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.