split off from bug 27946. the issue is that clicking on the down button of a combobox causes reflows because padding values are changed. copied from troy's last comment on bug 27946: ------- Additional Comments From firstname.lastname@example.org 2000-02-17 10:01 ------- There were two separate proposals: 1. the "nothing changed" optimization. We don't really need that optimization anymore, because that was working around how table cell incremental reflow used to be a three-step reflow process, where step one was to process the incremental reflow command, step two was to do an unconstrained reflow and update the maxium width, and step three reflowed the cell back to its cell width. Now that we can incrementally update the cell's maximum width it's just one step and reasonably efficient 2. was having the style system get the frame involved when things like padding changed in a zero sum way, e.g., padding added to one edge and removed from another edge. I think we all agreed this was necessary, but I don't remember where it currently stands Pierre, do you remember?
Sorry for not answering Troy's question 2 weeks ago. I did not forget the problem. It stayed on my list because of a lack of time and also (I think) because a temporary change in the way the dropdown lists were displayed that made the problem not as accute as it used to be during a little while. The solution I wanted to implement would have allowed the frames that support a particular interface to be involved in the CalcDifference() process all the time. If it appears to be too time-consuming, we can do as Troy suggested and get the frames involved only when CalcDifference() detects a case that may be handled more efficiently by the frames. Closing as dup of 15155. *** This bug has been marked as a duplicate of 15155 ***
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
Marking verified dup of 15155.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.