1246185 - Nightly collapsed <details> tag if disabled dom.details_element.enabled = false

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Alice0775 White]

Steps To Reproduce:
1. dom.details_element.enabled = false by default until Bug 1241750 fixed
2. Open URL


Actual Results:
<detail> is collapsed

Expected Results:
For backward compatibility, 
I think <detail> should be expanded if disabled dom.details_element.enabled = false;

Comment 1

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Attachment: MozReview Request: Bug 1246185 - Do not collapsed <details> when preference off. r=bz

To retain backward compatibility, <details> tags should not collapse its
children when dom.details_element.enabled = false.

Review commit: https://reviewboard.mozilla.org/r/34135/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/34135/

Comment 2

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8717321 [details]
MozReview Request: Bug 1246185 - Do not collapsed <details> when preference off. r=bz

https://reviewboard.mozilla.org/r/34135/#review30863

Sorry I missed this... r=me

Comment 3

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

bz, it was my fault. Thank you for the review!

https://treeherder.mozilla.org/#/jobs?repo=try&revision=411628cbd595

Comment 4

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/600942ae9823

Comment 5

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

The root cause of this bug is that I didn't realize HTMLDetailsElement::FromContentOrNull(parent) isn't a type-safe conversion as I thought. It only checks whether the parent has the tag name "nsGkAtoms::details". So when the preference is off, FromContentOrNull still down cast a HTMLUnknownElement with "details" tag into HTMLDetailsElement.

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/600942ae9823