зеркало из https://github.com/mozilla/gecko-dev.git
275707a51b
It's unused on mozilla-central, and Thunderbird can just use the canvas frame as regular (X)HTML documents, so just use a canvas frame instead of an nsRootBoxFrame for XUL as well. nsRootBoxFrame was needed because of various XUL-specific things like tooltips and so on lived there. But with the move away from XUL, that functionality has been added to nsCanvasFrame already, behind a principal check instead. This also allows simplifying our background propagation setup, which was only half-working for XUL documents (this bug is a consequence of that). With this, most of the callers of nsCSSRendering::IsCanvasFrame can go. They're only two of the frames that would return true for that that actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the codepaths in display list building and painting can just check frame->IsCanvasFrame() instead. The remaining caller to that function is nsContainerFrame::SyncWindowProperties, and the change is also legit, in the sense that the only thing SyncWindowProperties() really cares about is propagating the max/min-width constraints from the root element's style to the view/widget, and the only frame that would return true from IsCanvasFrame and have a view is the viewport frame which is the root of the frame tree. Differential Revision: https://phabricator.services.mozilla.com/D90846 |
||
|---|---|---|
| .. | ||
| base | ||
| build | ||
| docs | ||
| forms | ||
| generic | ||
| inspector | ||
| ipc | ||
| mathml | ||
| media | ||
| painting | ||
| printing | ||
| reftests | ||
| style | ||
| svg | ||
| tables | ||
| tools | ||
| xul | ||
| moz.build | ||