Open Bug 1523453 Opened 8 months ago Updated 5 months ago

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

Categories

(Core :: XUL, enhancement, P5)

enhancement

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.

https://searchfox.org/mozilla-central/rev/5c8ea961d04767db723a0a15e3a8f7fbca154129/layout/xul/nsDeckFrame.cpp#156

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

See Also: → 1132449

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.