###!!! ASSERTION: frame state bit was set but frame has no view: 'value != 0', file /home/chb/mozilla/layout/html/base/src/nsFrame.cpp, line 2262 Break: at file /home/chb/mozilla/layout/html/base/src/nsFrame.cpp, line 2262 got that assertion ten times, when viewing source on http://www.mozilla.org/projects/l10n/mlp_status.html#contrib (clicked "view page source" in context-menu) this is on linux with cvs build from 1.5 hours ago, with gtk2 w/o xft, in case that matters. can provide complete .mozconfig on request.
15 years ago
I've been seeing these for a bit for all context menus and tooltips as they come up.... This is at least 4-5 days old, unfortunately. :(
I've got bug 176754 open about the context menus and tooltips. I ended up just axing the assertion out of my tree in frustration so I can't tell if this is the same issue.
I'd sort of like to question futuring this, since it makes debugging next to impossible...
so... this is firing because the NS_FRAME_HAS_VIEW bit is set on an ancestor of the MenuPopupFrame, but that ancestor has no view... It's not clear to me how that bit can get set without having a view, and that's worrisome.
Please retriage this! This makes it very hard to spot other important assertions. Either it's important enough to have the assertion and it should be fixed or the assertion should go.
For the record, I spent a few hours on this. I completely fail to see how that bit can get set without a view being set. So the assertion is indeed quite valid and should be there and I think we have a _major_ problem (like writing on memory we should not be writing on) somewhere.
This happens on my Win32 build as well... OS=All What is the timeframe for when this started? post-1.2 branch, correct?
probably.... let me see if I can pull an older build and test....
I originally fingered hyatt's checking for bug 172276 as causing this but by this point I've totally forgotten why.
Thanks! I just backed out that checkin and the problem disappeared...
Comment on attachment 108562 [details] [diff] [review] Oh, man.... OK. Well, I was theorizing that the assert was due to the frame manager's property table being corrupt or something... but we're just using the wrong frame manager (via wrong prescontext). We should really get one from the same doc as the frame we're dealing with.
taking. Here's hoping for quick reviews and maybe even approval... ;)
Comment on attachment 108562 [details] [diff] [review] Oh, man.... superb catch! sr=roc+moz
Comment on attachment 108562 [details] [diff] [review] Oh, man.... Could this please be approved for 1.3a? Small change, very safe, makes debugging much less painful, probably makes the "context menu on menupopup" feature actually work...
Comment on attachment 108562 [details] [diff] [review] Oh, man.... Yes, good catch -- any more like those? email@example.com for 1.3a, please check in today (Monday). /be
Sorry to say, but I think this fix resulted in bug 185107, where context menus for <iframe>s are positioned incorrectly.