STR (1) Make sure calculator app is closed (2) Tap calculator icon to launch it There seems to be a delay before it's launched, but that might be my imagination. However, if we *are* waiting for the "nextpaint" delay for newly opened frames, we shouldn't be; that only hurts startup time.

You are right -- openWindow() currently opens window without finding out if the frame is just created or not. It should not wait for 100ms if |unpaint| state is set on the frame.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #1) > It should not wait for 100ms if |unpaint| state is set on the frame. You're talking about the setTimeout(, kTransitionWait), right? We shouldn't need this when showing a newly created frame. Also, why do we wait 100ms when opening a frame at all? Bug 808231 is only about app -> homescreen transitions, isn't it?

This will be fixed by bug 808231.

(In reply to Tim Taubert [:ttaubert] from comment #2) > (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #1) > > It should not wait for 100ms if |unpaint| state is set on the frame. > > You're talking about the setTimeout(, kTransitionWait), right? We shouldn't > need this when showing a newly created frame. Yes. > Also, why do we wait 100ms when opening a frame at all? Bug 808231 is only > about app -> homescreen transitions, isn't it? When a frame is being put to background, we will call |setVisible(false)| on the mozbrowser iframe. The video buffer of the OOP iframe will be cleaned up, resulting an white/transparent iframe. Every time we make the iframe visible again we will need to wait for 100ms after calling |setVisible(true)| so the user will not see the white iframe. This apply to both app -> homescreen and homescreen -> app transitions, since hidden homescreen and the closed iframe will be |setVisible(false)|'d when it's ... not visible. cjones will have better idea to explain this.

100ms is the current "timeout" for awaiting the repaint. The "nextpaint" event is the "real fix" for waiting for the repaint, *but* ... we still need a timeout, because we can't wait arbitrarily long on apps before starting the UI transition. However, with "nextpaint", the timeout can be higher. We had hoped the timeout would work well enough, but based on experience and the bugs that are being filed, it appears we want "nextpaint" after all.

Thank you both for clarifying. That's exactly how I'm currently implementing it.

Chris, I don't think bug 814771 has anything to do with this one. This one is about the homescreen -> newly launched app transition, and that one was about app -> homescreen.

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

Fixed by bug 808231.