nsDeckFrame::RemoveFrame() can get confused perhaps because selectedIndex is set before the child frames are constructed
Categories
(Core :: XUL, enhancement, P5)
Tracking
()
People
(Reporter: timdream, Unassigned)
References
Details
In bug 1520350 I got a patch where the markup of the <deck> is inserted at the same tick main.js calls into aboutDialog-appUpdater.js.
In the test toolkit/mozapps/update/tests/browser/browser_aboutPrefs_fc_check_otherInstance.js, the later script correctly deduces the state of the updater and set the selectedIndex to 9 (via MozDeck).
However, the attribute value gets magically changed to 7 when the test assertion tries to access it.
There is nowhere in JS that could have set the attribute value. The only offender seems to be in nsDeckFrame::RemoveFrame(). I can't create a Windows build to verify this claim though.
I will workaround this in bug 1520350 but we really shouldn't mutate DOM states from layout ...
|
Reporter | |
Comment 1•2 years ago
|
||
I don't understand layout enough to tell why nsDeckFrame::RemoveFrame() can be called during document load. The <hbox>es are not moved nor set to display: none or whatnot. I will need to leave it to someone with a Windows build...
|
||
Comment 2•2 years ago
|
||
It'd be really nice if we could remove nsDeckFrame though...
It seems to me it could be replaced with a 1x1 CSS Grid with
all children placed in the same grid area, and then put
visibility:hidden on all except the selected one.
|
||
Updated•2 years ago
|
Description
•