the wizzard binding changes insertion points for wizardpage elements and all other elements (stringbundle, script). Should I proceed with @slot mechanism and put @slot="wizardpage" attribute on each wizardpage element? or is there nicer approach?
(In reply to alexander :surkov (:asurkov) from comment #1) > the wizzard binding changes insertion points for wizardpage elements and all > other elements (stringbundle, script). Should I proceed with @slot mechanism > and put @slot="wizardpage" attribute on each wizardpage element? or is there > nicer approach? It would be nice if there was a way to have the SD be in charge of what gets slotted in, instead of the page having to request it, but that's not part of the spec. I'm not sure why it was specced to flip it so that decision is made by the calling code instead of the shadow host. If we wanted to simulate this, I could imagine writing some code in which the CE sets the [slot] attribute automatically on all child wizardpage's in connectedCallback, and then sets up a MutationObserver to detect when new ones are added and sets the attribute on them as well. From what I hear the MO doesn't have too much overhead, so that could be viable (esp if we aren't watching subtree and just direct children on the CE). Setting the slot attribute in the calling markup seems OK to me as well.
Or more simply, we can make the wizardpage Custom Element set the correct slot attribute in its constructor.
(In reply to Brian Grinstead [:bgrins] from comment #3) > Or more simply, we can make the wizardpage Custom Element set the correct > slot attribute in its constructor. yeah, that one should work (I hope it can't cause some kind of re-insertions and thus lead to intermittents).
Ran into a problem of nsXULCommandDispatcher::AdvanceFocusIntoSubtree, which hangs when called for a slotted wizardpage. It appears it falls into infinite recursion in nsFocusManager::GetNextTabIndex .  https://searchfox.org/mozilla-central/source/dom/base/nsFocusManager.cpp#3991 Olli, do you have ideas how to approach it? Is anyone familiar with this code?
Assignee: nobody → surkov.alexander
testcase please for the hang? But won't be able to look at it before end of this month.
(In reply to Olli Pettay [:smaug] from comment #7) > testcase please for the hang? No tests but steps to reproduce with the patch applied: Bookmarks -> Show all bookmarks -> Import data from another browser -> Continue > But won't be able to look at it before end of > this month. Thank you. It feels a sort of stopper for slotting into shadow DOM though, it doesn't feel specific for wizard CE. If you can think of anyone who could take a look before you, please cc :)
Attachment #9035849 - Attachment description: alexande's patch rebased → alexander's patch rebased
You need to log in before you can comment on or make changes to this bug.