There is some bug in the Windows Firefox implementation where if I don't manually force a reflow (triggering the browser to synchronously recalculate the style and layout) of the styles for the embedded browser XUL element when the top level browser window is resized (ex: maximized, full screen), the intro panel doesn't render and the panel is blank.
More specifically, in Windows OS only, if the window resizes (via the "sizemodechange" event), the computed dimensions of the embedded browser from intro-panel.js (via the "resizeBrowser" method) are wildly off for some reason (width: 0px, height: 507.1px) when it should be more like (width: 270px, height: 317px). When I force the script to update the value of the "style" attribute on the embedded browser XUL element so that it is slightly different each time, it correctly displays the intro panel. If, however, the value is unchanged between embedded browser loads, the panel is blank.
There is some bug in the Windows Firefox implementation where if I don't manually force a reflow (triggering the browser to synchronously recalculate the style and layout) of the styles for the embedded browser XUL element when the top level browser window is resized (ex: maximized, full screen), the intro panel doesn't render and the panel is blank.
More specifically, in Windows OS only, if the window resizes (via the "sizemodechange" event), the computed dimensions of the embedded browser from intro-panel.js (via the "resizeBrowser" method) are wildly off for some reason (width: 0px, height: 507.1px) when it should be more like (width: 270px, height: 317px). When I force the script to update the value of the "style" attribute on the embedded browser XUL element so that it is slightly different each time, it correctly displays the intro panel. If, however, the value is unchanged between embedded browser loads, the panel is blank.