From bug 285755 comment 8: the ensuing assertions are due to a bug in the patch for bug 287446. An early return that should be there got lost. :( We should probably file a separate bug on that and fix it on the 1.8 branches... :(
12 years ago
What negative effects come from this? The testcase URL is WFM for bsmedberg. Need a baked patch to consider for 126.96.36.199
Created attachment 207771 [details] [diff] [review] Patch This is dead-simple. Should have been in the original checkin. If we ever hit this code without this patch, we'll probably end up with a security hole (since the right jscontext won't be on the stack). There's zero risk here; I really think we should take this for 188.8.131.52.
Renominating for 184.108.40.206. I really think we should take this on branch... possibly even if it means an extra day in the cycle to give this more bake time if drivers want more bake time. See comment 2 for details.
Comment on attachment 207771 [details] [diff] [review] Patch sr=me, jst would agree. /be
<brendan> bz: you didn't answer dveditz in the bug about how people hit this > brendan: it's an error condition > brendan: they generally don't <brendan> someone did <brendan> bad luck? > brendan: that was because of another bug that broke QI > brendan: but frankly, I don't think we want people to be exploitable because some dumb extension breaks editor
Fixed on trunk.
Comment on attachment 207771 [details] [diff] [review] Patch a=dveditz for drivers
*** Committing to MOZILLA_1_8_BRANCH... /cvsroot/mozilla/layout/forms/nsTextControlFrame.cpp,v <-- nsTextControlFrame.cpp new revision: 220.127.116.11; previous revision: 18.104.22.168 *** Committing layout/forms/nsTextControlFrame.cpp on MOZILLA_1_8_0_BRANCH... /cvsroot/mozilla/layout/forms/nsTextControlFrame.cpp,v <-- nsTextControlFrame.cpp new revision: 22.214.171.124.2.1; previous revision: 126.96.36.199