Closed Bug 604841 Opened 15 years ago Closed 12 years ago

"ABORT: who sent the notification then" with QI to imgIDecoderObserver

Categories

(Core :: SVG, defect)

x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- -

People

(Reporter: jruderman, Assigned: ehsan.akhgari)

References

Details

(Keywords: assertion, testcase, Whiteboard: [softblocker][depends on 605271][post-2.0])

Attachments

(1 file)

Attached image testcase
###!!! ABORT: who sent the notification then?: 'aContainer', file content/svg/content/src/nsSVGFilters.cpp, line 5644 The assertion is in nsSVGFEImageElement::OnStartContainer.
I thought we disallowed QI to non-classinfo interfaces from untrusted script for DOM objects... Or did we just disallow implicit conversion to/from those interfaces through XPConnect?
Bah! In that case, we need to either move this interface off this node (onto a helper object) or add some sanity-checking to the impl.....
blocking2.0: --- → ?
I really think we should consider stopping this madness for FF4. We're just gonna play whack'a'mole otherwise. jst and I discussed a couple of alternatives, and peterv might even have a patch. It would be a risky change this late in the game, but it might be less risky than the whack'a'mole...
After my fuzzer got lucky and found bug 604262, I taught it to take an object and try QI'ing it to every interface. It then quickly found bug 604556, bug 604807, and this bug (bug 604841).
So what's the plan here? Comment #4 sounds like there is a plan...
blocking2.0: ? → final+
Whiteboard: [depends on 605271]
Whiteboard: [depends on 605271] → [depends on 605271][softblocker]
Assignee: khuey → ehsan
Whiteboard: [depends on 605271][softblocker] → [softblocker][depends on 605271]
I think fixing this without bug 605271 will be too hackish and risky this late in the game...
Whiteboard: [softblocker][depends on 605271] → [softblocker][depends on 605271][post-2.0]
I'd actually like to fix this one by just noscripting imgIDecoderObserver. Some of the imglib xpcshell tests use it, but no product code does. Post 2.0 though, for sure.
(In reply to comment #9) > I'd actually like to fix this one by just noscripting imgIDecoderObserver. > Some of the imglib xpcshell tests use it, but no product code does. > > Post 2.0 though, for sure. You mean doing that post 2.0?
OK, renoming to see if we still need to block on this.
blocking2.0: final+ → ?
Depends on: post2.0
blocking2.0: ? → -
No longer depends on: post2.0
Fixed with WebIDL bindings.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: