With the patches in bug 835518 applied, I found the following regression. I suspect it is timing-dependent so I'm not sure if it'll be reproducible on other machines. Steps to reproduce: 1. Rebuild Metro Firefox by running make in the $OBJDIR/browser/metro directory. 2. Launch Metro Firefox. 3. Click the Settings charm, and choose either "Options" or "About" Expected results: The selected flyout sidebar appears. Actual results: Nothing happens until you perform some other user input (e.g. an edge swipe, or choosing one of the settings charm commands again), at which point the sidebar appears. I logged to make sure the flyoutpanel constructors are called at startup and the "show" method is called at the right time and throws no exceptions. The code thinks that the sidebar is visible (e.g. getBoundingClientRect returns the correct layout), but it just isn't painted. I suspect something is wrong with our painting or event handling. I tried removing the dispatchEvent call in #flyoutpanel.show, and I also tried removing the -moz-transition in flyoupanel.css, but these changes had no effect.
Possibly related to bug 807691
I meant to say bug 817641
By the way, I'm also seeing this intermittently in other situations (i.e. not during the first run of a new build). It seems to happen more often if a page is loading when I show the flyout.
Is this still happening for you?
Yes, still seeing this intermittently.
By the way, I still see this most often first thing after starting a new build; closing and re-launching the browser generally makes it go away.
I could never reproduce this but I think it is fixed by bug 817641.