The failure mode in the attached crashtest is an inconsistency in the flattened
tree. Specifically, we null out mVideoControls in an nsVideoFrame, but defer
the UnbindFromTree call on that NAC element, which measn that its mParent still
points to the nsVideoFrame's mContent. Because all this stuff runs off of script
runners, and the anonymous content destroyer is not guaranteed to run before
other potential script runners, we end up running arbitrary script while the
tree mismatch exists. This script calls back into ProcessPendingRestyles, which
causes trouble.
We could build a separate deferral mechanism, but it's not clear that we actually
need to defer the unbind anymore. The deferred unbind was added in bug 489008,
which predated a lot of simplifications in layout/dom interaction.
MozReview-Commit-ID: 1JYAhiXKVJC
This removes about 2/3 of the occurrences of nsXPIDLString in the tree. The
places where nsXPIDLStrings are null-checked are replaced with |rv| checks.
The patch also removes a couple of unused declarations from
nsIStringBundle.idl.
Note that nsStringBundle::GetStringFromNameHelper() was merged into
GetStringFromName(), because they both would have had the same signature.
--HG--
extra : rebase_source : ac40bc31c2a4997f2db0bd5069cc008757a2df6d
In case of removing summary element, we need to check details *frame* children
instead of details *element* children since the summary element has been
already removed from details element children list.
MozReview-Commit-ID: GEzDId9CYf9
--HG--
extra : rebase_source : 50834606413b916a3c0d6074a7a52e8bdbe845a0
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 avoids conflicts with mozilla::dom::FrameType.
MozReview-Commit-ID: 7aEMbHRaTFk
--HG--
extra : rebase_source : 2d01321f5ce0ec8c0e3f70984674f82678034b3c
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
Bobby Holley
Nicholas Nethercote
Hiroyuki Ikezoe
Mats Palmgren
Emilio Cobos Álvarez
Ting-Yu Lin