STR: - Open a new tab with the '+' button (let's call it TAB B). - Enter customize mode. - Exit customize mode. Expected: - I'm at TAB B again. Actual: - TAB B gets closed. Note: this doesn't happen if the current tab is a "normal" page, but it does happen with the newtab page. To me this behavior is unexpected.

I think it makes more sense for Customize to always open a new tab for itself, as happens with opening Add-ons or other "in-content UI." Then when you close the customization mode, you're back where you were before, even if that was a new as-yet-unused tab. This makes the behaviour consistent across (a) All our in-content UI (b) Opening customize when the current tab is about:newtab or anything else

So, it seems that it's agreed that entering and exiting customize mode should not alter the tabs which the user had before entering customize, even if it was entered while at the newtab page. Suggested above is to always use an extra tab for customize, which I also think is the correct approach with the current "customize mode in a tab" paradigm. This also made me think of the entire "customize mode in a tab" paradigm. I suggested some alternatives at bug 961823.

Minusing due to Addons Manager already working this way!

(In reply to Justin Dolske [:Dolske] from comment #3) > Minusing due to Addons Manager already working this way! Does this mean wontfix? the bug has been open and agreed by design that it's not behaving correctly for 4 months now. FWIW, I don't think it's exactly the same case as the addon manager due to the unique way in which customize mode appears in a tab. Addons manager clearly occupies the current tab and that's it, and you can exit it only by closing the tab. Customize, OTOH, is more like a mode or even kind of dialog (in how it feels and behaves), where pressing escape gets out of this mode, and the mode itself, with the whole browser animating etc, isn't conceptually associated with a tab IMO. So changing the tabs on escape is more apparent and feels more wrong, at least to me, than the addon manager case. Also, the addon manager behaved like this for years. Customize is new and behaves incorrectly, so regardless if other parts behave, customize should behave correctly. And it's bit the same case as the addons manager.

(In reply to Avi Halachmi (:avih) from comment #5) > (In reply to Justin Dolske [:Dolske] from comment #3) > .. And it's bit the same case as the addons manager. s/bit/not/

For clarification, "minusing" meant that fixing this bug was deprioritized in the backlog of all other Australis work. It's not an effective wontfix, as we would take a patch for it if one came by. But at the same time it would probably be good to fix the AOM to behave the same way.

I get priorities, they're yours to make, and we never have enough resources to do everything we'd like. I only disagreed with the specific given reasoning, not with the fact that you don't have resources to handle it now (though maybe with different reasoning it could end up a bit higher on the priorities list).

The code is here: http://hg.mozilla.org/mozilla-central/annotate/b5b35ec88db8/browser/base/content/browser.js#l6915 It sounds like you want the first if-branch removed and always take the second route.

(In reply to Dão Gottwald [:dao] from comment #9) > The code is here: > http://hg.mozilla.org/mozilla-central/annotate/b5b35ec88db8/browser/base/ > content/browser.js#l6915 > > It sounds like you want the first if-branch removed and always take the > second route. Agreed, thanks. Though from comment 3 and comment 7, I'm not sure it would be accepted without also modifying the addons page, but IMO modifying addons is not necessarily required, and therefore more controversial. But sure, if you'd take modifying the customize behavior without touching the addons, It'd cover my concerns.