Open Bug 1523453 Opened 2 years ago Updated 2 years ago

nsDeckFrame::RemoveFrame() can get confused perhaps because selectedIndex is set before the child frames are constructed


(Core :: XUL, enhancement, P5)





(Reporter: timdream, Unassigned)



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 ...

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...

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.

Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.