Confirmed on Win98 as well, with a 1.5b build.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
please FIX this bug, its open since 93 and my page relies on this. There is NO WORKAROUND this bug, so its important. Joe Robe
Seems like NO ONE takes care of this ! I am developing a web application with the look and feel of an windows application . Works AWESOME, but I have to lock out all my users of Mozilla and force them to use IE due to this MAJOR BUG !! If no one takes care, I would like to be assigned to it so it gets finally fixed. Joe
The problem is that when we do ReResolveStyleContext on the table-outer-frame, CalcStyleDifference returns 0 in CaptureChange, because 'compare' is 0 (the old and new style contexts have the same rule node). We do have two different style contexts, though. I don't understand enough about the style system to know why the rule nodes are the same or what should be done about it. Boris probably knows.
The basic problem, I bet, has to do with the relationship between the inner and outer frame... The inner frame is a child of the outer, but the style context of the outer is a child of that of the _inner_. Now when we do this style context reresolution game, we essentially assume that if a parent has a certain hint we don't need to bother with that hint for child frames. That's why we assign the return value of CaptureChange to aMinChange. The optimization in CalcStyleDifference is the same idea -- since our rulenode didn't change, the styles applying to us did not change, so the only things that will change about us are things we inherit. But if we inherit them, then they must have changed on some ancestor and that ancestor will deal with it. In this case, we end up with a sync hint for the inner table frame and no hint at all for the outer frame, since this code assumes that the inner frame (which is the parent in the style context tree) will handle things. So we can either hack ReResolveStyleContext to know about this special relationship (like we hack out the reflow hint when reresolving out-of-flows) or we can change the ApplyRenderingChangeToTree code to handle this situation.
Created attachment 172307 [details] [diff] [review] fix
Comment on attachment 172307 [details] [diff] [review] fix >Index: layout/base/nsFrameManager.cpp >+ nsChangeHint aAssumeChange) Maybe "aChangeToAssume"? >+ return aMinChange; Want to file a followup bug on making this return something useful?
> Maybe "aChangeToAssume"? OK > Want to file a followup bug on making this return something useful? It is useful, isn't it? It's the change we applied (or predicted will apply by frame inheritance) to the frame.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Oh, right. I forgot that we change aMinChange within the function.
You need to log in before you can comment on or make changes to this bug.