Change the logic that moves the main summary to the front from operating
on generated frames in DetailsFrame::SetInitialChildList() to operating
on frame construction item list in AddFrameConstructionItemsInternal()
so that it will be correct when cooperating with ::first-line.
The root cause of the bug reported is because when specifying
::first-line on details element, the first frame of summary element,
which is generated due to ib-split, will be wrapped in nsFirstLineFrame.
The original code fails to find the summary frame in the wrapper frame
and triggers assertion because of the second ib-split summary frame. To
fix that, we need to descend into the child list of wrapper frames when
checking the main summary.
Add original test case as a crashtest as well as reftests to clearly
reproduce the issue.
Note that in the reftest, the blue color in ::first-line is applied
incorrectly to the second line in the summary due to bug 520605.
MozReview-Commit-ID: Bv4Vcvxp6pY
nsCSSFrameConstructor::ConstructNonScrollableBlock() has logic to
determine whether to create a block formatting context for a block
frame. I refactor the function to make it reusable by
nsCSSFrameConstructor::ConstructDetailsFrame().
Also, make NS_NewBlockFrame() accept two arguments as other frame
factory functions so that it could be pointed by BlockFrameCreationFunc.
NS_NewBlockFormattingContext is changed accordingly.
The construction for a scrollable DetailsFrame will be further revised
in Part 3.
MozReview-Commit-ID: 8TwG9YMyGva
--HG--
extra : rebase_source : fffdd974df81a809a607491d2534aa8dd2d13ab1
We can use nsBlockFrame to render summary elements.
This change undoes "Bug 591737 - Add SummaryFrame" and remove
summaryFrame usage in DetailsFrame and nsCSSFrameConstructor.
MozReview-Commit-ID: 4aJvHVPfsBb
--HG--
extra : rebase_source : 8e197fa61cfcbaf066a8a510aef7c92adddd30f2
If the main summary element has 'display: none' style, it won't
generates a summary frame as the first child of the details.
However, if a details element have two summaries and the first summary
has 'display: none', the second summary still generates a SummaryFrame
event if it isn't the main summary. So instead of checking on the
SummaryFrame as before, I check the content tree for the main summary by
using the idea in bug 1245424 comment 8. Another reason might be the
potential removal of SummaryFrame in bug 1258657.
MozReview-Commit-ID: H0evZ17zj5k
--HG--
extra : rebase_source : 1aad3ad1d31dc277771013f92eace5cefa7d6112
If a <details> lacks a direct <summary> child, we need to construct a
default one.
--HG--
extra : commitid : ApnP20Mrr33
extra : rebase_source : 4b059f4e7fa32bac665487aa8a266ba58597b184
Ting-Yu Lin