When exiting customization mode, the location bar briefly shows its placeholder text ("Search or enter address") before showing the address of the tab. This contributes to the transition looking wonky on OS X.

Okay, let's see how people like this. (Based on an idea by mconley.)

Note: This should also fix bug 964279.

Comment on attachment 8385343 [details] [diff] [review] Close the tab before flipping the deck away from the customize pane. Review of attachment 8385343 [details] [diff] [review]: ----------------------------------------------------------------- I'm good with this, but we should watch the CART numbers for the exit times.

Comment on attachment 8385343 [details] [diff] [review] Close the tab before flipping the deck away from the customize pane. >+ browser.parentNode.selectedPanel = browser; What is that? This doesn't seem to make any sense.

The parent of the element with id="browser" is the content-deck, which is a XUL deck that has two child elements - the browser, and the customization container. browser.parentNode.selectedPanel = browser sets the deck back to the browser from the customization container.

Ah, I thought this was some sort of actual browser or tabbrowser, but it's really something like a "tabbrowserContainer".

remote: https://hg.mozilla.org/integration/fx-team/rev/092b3b1a185c

Comment on attachment 8385343 [details] [diff] [review] Close the tab before flipping the deck away from the customize pane. [Approval Request Comment] Bug caused by (feature/regressing bug #): Australis! User impact if declined: A distracting white flash when exiting customize mode. Testing completed (on m-c, etc.): Lots of testing on mozilla-central. Risk to taking this patch (and alternatives if risky): Very low. String or IDL/UUID changes made by this patch: None.

This issue is back in the current Nightly, along with some other (minor) polish issues in the customization transition.

Hm - this might have to do with some of the recent work on cleaning up the back / forward buttons... can you find the first Nightly that this got introduced, phlsa?

Please only reopen bugs when the patch was either backed out or already ineffective at the time it landed. If an issue reappears weeks later, please file a new bug. Makes it much easier to keep track of when and why things regressed and what patches landed when.

(In reply to Mike Conley (:mconley) from comment #12) > Hm - this might have to do with some of the recent work on cleaning up the > back / forward buttons... can you find the first Nightly that this got > introduced, phlsa? Hm, this is strange. I tried to narrow down the range using mozregression, and I couldn't find a single release where it worked (I looked all the way back to early March). This can mean two things: - I suck at mozregression - It was never actually fixed completely (In reply to Dão Gottwald [:dao] from comment #13) > Please only reopen bugs when the patch was either backed out or already > ineffective at the time it landed. If an issue reappears weeks later, please > file a new bug. Makes it much easier to keep track of when and why things > regressed and what patches landed when. Alright, thanks for the clarification! So I'll just keep the discussion here until we're sure this was actually fixed at some point.