Closed Bug 591997 Opened 14 years ago Closed 14 years ago

nsIChannel will have changed between beta4 and beta5

Categories

(Core :: Networking, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- beta5+

People

(Reporter: benjamin, Assigned: dwitte)

References

Details

nsIChannel changed IID and impl between beta4 and beta5 with bug 589292 and bug 536324. While I agree that these are virtuous changes, I don't think we should be changing the IIDs of base interfaces so late in the beta cycle. It's going to be very difficult to distinguish between crashes caused by third-party extensions which were compiled against beta4, and crashes caused by issues within our own code. 

Unless these changes were absolutely necessary for e10s (and it doesn't look to me as if they were), I think these should be backed out and postponed until after branching.
blocking2.0: --- → beta5+
I commented over in bug 536324 comment 29. I could investigate things a bit further over there, figure out what the risk is if we back it out, and then we can make an informed decision. (If there are issues with that, one thing we could do is try to inform extension authors as best we can about why they should avoid it, which sounds like it's a better proposition than informing them of the need to recompile.)
Avoid what, nsIChannel? nsIChannel is not really an avoidable interface for many of the people building binary components, I'll wager. Doing low-level network operations (filtering/childproofing/etc) is one of those places where binary components are most useful.
I meant avoiding the contentLength hash property... but as you suggested over in that bug, we could specialcase it as an easy fix.
dwitte's on it
Assignee: nobody → dwitte
Backed out on e10s; once everything cycles green I'll merge to m-c.
Done.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.