forked from mirrors/gecko-dev
We've tried to give `nsFileControlFrame` its own frame type "FileControl", but it caused a crash and we revert its frame type back to "Block" in Bug 1825623. That prevents the crash, but the frame tree is not correct since `nsFileControlFrame` will have `nsBlockFrame` as its next-in-flow. The proper way to fix the crash is disallowing the form control frame to split, similar to what we did for `nsTextControlFrame` in https://searchfox.org/mozilla-central/rev/fc76676f61ee37b4c5420649cad6677164a29405/layout/forms/nsTextControlFrame.cpp#670 This patch doesn't mean to promote frame type usage, but it might help the broader frame type audit in the future once we switch frame type to QueryFrame in bug 1555477. Note this patch might have potential behavior changes since calling `IsBlockFrame()` on `nsFileControlFrame` now returns `false` instead of `true`. However, we have other concrete frames such as `nsMathMLmathBlockFrame`, `nsSelectsAreaFrame`, etc. which have frame type "Block", and callers who need to check `nsBlockFrame` and its subclasses are probably already using `IsBlockFrameOrSubclass()`. Differential Revision: https://phabricator.services.mozilla.com/D212188 |
||
|---|---|---|
| .. | ||
| base | ||
| build | ||
| docs | ||
| forms | ||
| generic | ||
| inspector | ||
| ipc | ||
| mathml | ||
| painting | ||
| printing | ||
| reftests | ||
| style | ||
| svg | ||
| tables | ||
| tools | ||
| xul | ||
| moz.build | ||