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
•