It seems better to convert this before adding a new flag (in bug
1547759) and risking replacing the wrong 0 with a flag.
Differential Revision: https://phabricator.services.mozilla.com/D40562
It was made pointless by the previous patch.
This replaces callers that had a frame type for another reason with the
frame type check that IsTableCell did, and callers that needed to call
Type() with an IsTableCellFrame call.
Differential Revision: https://phabricator.services.mozilla.com/D40561
There are two existing callers of IsTableCellFrame that both appear to want to
include BCTableCell frames, but don't. A patch in bug 1547759 will add a
third that wants the same.
The existing users of frame types all have to work around it being a distinct
type, and none appear to want the distinction. This removes that complexity.
If any callers want to make the distinction, they could implement QueryFrame
for BCTableCellFrame and use it. (It's not implemented now, though!)
In a little more detail, prior to this patch (in my debug build, at least):
* nsQueryFrame::ClassID::nsMathMLmtdFrame_id was 46
* nsQueryFrame::ClassID::nsTableCellFrame_id was 47
* nsQueryFrame::ClassID::nsBCTableCellFrame_id was 65
and entries 46 and 47 in sLayoutFrameTypes were
mozilla::LayoutFrameType::TableCell while entry 65 was
mozilla::LayoutFrameType::BCTableCell.
With this patch:
* nsQueryFrame::ClassID::nsBCTableCellFrame_id is 40
* nsQueryFrame::ClassID::nsMathMLmtdFrame_id is 41
* nsQueryFrame::ClassID::nsTableCellFrame_id is 42
and entries 40 through 42 in sLayoutFrameTypes are
mozilla::LayoutFrameType::TableCell.
Differential Revision: https://phabricator.services.mozilla.com/D40560
This helps for the next patch, since some of the table backgrounds items want to compute this without position:relative taken into account.
Differential Revision: https://phabricator.services.mozilla.com/D29279
Most of the code in DisplayGenericTablePart was all within a per-class if statement, so it doesn't add much value, and makes the control flow harder to understand.
Differential Revision: https://phabricator.services.mozilla.com/D29273
This patch moves some `enum` in `nsIPresShell` which are in public scope into
`mozilla` namespace and change them as `enum class`es.
Unfortunately, only "where to scroll" enum is just defines constants of
percentages of scroll destination. Therefore, this patch makes only them
as `static const`.
Differential Revision: https://phabricator.services.mozilla.com/D28606
Additionally, this patch makes `nsFrame.h` stop including `nsIPresShell.h`
and makes each users include `mozilla/PresShell.h` instead. So, this improves
rebuild performance of `nsIPresShell.h` (and `mozilla/PresShell.h` in the
future).
Note that due to `nsIFrame::PresShell()`, `mozilla::` prefix is necessary for
`PresShell` in a lot of classes which are derived from `nsIFrame` even in
`.cpp` files.
Differential Revision: https://phabricator.services.mozilla.com/D27476
Except retrieving from weak reference, `nsIFrame` should treat
`mozilla::PresShell` directly rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D26388
Really sorry for the size of the patch :(
Only intentional behavior change is in the uses of HasLengthAndPercentage(),
where it's easier to do the right thing. The checks that used to check for
(IsCalcUnit() && CalcHasPercentage()) are wrong since bug 957915.
Differential Revision: https://phabricator.services.mozilla.com/D19553
This patch makes us handle calc with percentages when we can convert to
percentages the same way we handle plain percentages in table layout.
We still treat length + percentage as auto (this matches Blink / WebKit as
well). There's one case we differ with Blink / WebKit, which is calc(% + 0px),
which they'd treat as auto instead of a percentage.
I think this is a bug on them (or at least worth some spec clarification). I
filed https://github.com/w3c/csswg-drafts/issues/3482 for that.
In practice what that'd means for us if the WG decides that Blink / WebKit is
right in that case is that we'd need to keep track of whether the calc()
specifies lengths, and return false from ConvertsToPercent if so.
In any case, nothing that would massively change this patch, and I think enough
of an edge case that is not worth blocking on the CSSWG decision here. Though I
could be convinced otherwise of course.
Differential Revision: https://phabricator.services.mozilla.com/D15719
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
-Wmissing-prototypes is a new optional warning available in clang ToT. It warns about global functions that have no previous function declaration (e.g. from an #included header file). These functions can probably be made static (allowing the compiler to better optimize them) or they may be unused.
Confusingly, clang's -Wmissing-prototypes is equivalent to gcc's -Wmissing-declarations, not gcc's -Wmissing-prototypes. A function prototype is a function declaration that specifies the function's argument types. C++ requires that all function declarations specify their argument types, but C does not. As such, gcc's -Wmissing-prototypes is a C-only warning about C functions that have no previous function *prototypes* (with argument types), even if a previous function *declaration* (without argument types) was seen.
MozReview-Commit-ID: FGKVLzeQ2oK
nsReflowStatus::IsEmpty() assertions are added after DISPLAY_REFLOW in the
beginning of the Reflow().
A few Reflow() implementations have Reset() calls at the end which are left
in place by this patch (with an explanatory comment added to each). These
ending Reset()s are only needed for cases where a non-splittable frame
passes its own nsReflowStatus to a child's reflow method. Just in case the
child leaves a "not fully complete" value in the nsReflowStatus, the
non-splittable parent frame must clear out the nsReflowStatus before
returning, so that its own parent doesn't then try to split it.
MozReview-Commit-ID: 6Jj3jfMAqj4
For the most part, I tried to make less *manual* table invalidations
for non-border-collapse tables and relied the table invalidations on
the comparison of the display items. By doing so, we can avoid the
over-painting issue.
MozReview-Commit-ID: 4w1DUKHXIFO
nsIFrame::mClass is of type enum class nsQueryFrame::ClassID which is
a strict subset of the nsQueryFrame::FrameIID values. For a concrete
frame class, its FrameIID is the same numeric value as its ClassID.
MozReview-Commit-ID: 1N0AkCGo1ol
This patch do following things:
1. Create nsDisplayTableBorderCollapse that draws all collapse border of
table.
2. Don't use nsDisplayTableBorderBackground.
3. Let column and column group frame generate display items.
4. When traversing the table, also traverse the column and column group
frames.
5. For each type of table frame (col group, col, row group, row and
cell), draw their own background.
MozReview-Commit-ID: 1s2VLv6G8xi
This patch do following things:
1. Create nsDisplayTableBorderCollapse that draws all collapse border of
table.
2. Don't use nsDisplayTableBorderBackground.
3. Let column and column group frame generate display items.
4. When traversing the table, also traverse the column and column group
frames.
5. For each type of table frame (col group, col, row group, row and
cell), draw their own background.
MozReview-Commit-ID: 1s2VLv6G8xi
