User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100513 Minefield/3.7a5pre ID:20100513040229 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100513 Minefield/3.7a5pre ID:20100513040229 The Add-ons Manager is opened in new window when I click "Manage Add-ons…" button in Options dialog. It should be opened in new tab of the existing browser window. In addition to the above, it is better to implement that If I clicked the button with Shift Key then it should be opened in new window. Reproducible: Always Steps to Reproduce: 1. Start Minefield with "NEW profile" 2. Tools > Options... > General > Click "Manage Add-ons…" button Actual Results: The Add-ons Manager is opened in new window. Expected Results: It should be opened in new tab of the existing browser window.

I forgot mention in comment #0 If I set browser.preferences.instantApply to true, or use linux build.

See also bug 558290. The question here is, should we close the preferences dialog when the user clicks the button? On some systems the dialog is modal which stops us from open it in a new tab without closing the preferences dialog first. I request feedback from UX.

Bug 565686 was a temporary fix for this. The situation is going to change once the preferences are redesigned - hopefully in a way that makes this bug invalid. The trouble in just closing the prefs dialog is that some OSes have instant-apply and some don't (and even then, its changeable via a hidden pref, as in comment 1) - which makes the solution a lot more complicated (and time consuming). So, IMO, there's not much point in taking time to fix this until we know whats happening with the preferences redesign.

So, for 4.0, the preferences are staying as-is (ie, NOT in-content). Which means this bug needs sorted out before final.

And another case to throw into the mix is if the tab is already open.

(In reply to comment #2) > On some systems the dialog is modal > which stops us from open it in a new tab without closing the preferences dialog > first. It doesn't stop us, but the user would have to close the dialog before he could use the page. This seems worse than keeping the current behavior.

The Preferences window should ideally stay open when the user clicks Manage Add-ons. It should open in a new tab of the current window (if a window is open). The reason for not closing the Preferences window is because no other current option within Preferences closes the window. This design encourages users to try out options, looking at what Preferences are available without the risk of losing the window. By adding only one option that dismisses the window, we'd both be inconsistent within Preferences and potentially surprise the user. It's true that one in-content page isn't itself "consistent," but this makes it more likely that the user is not expecting it and thus isn't expecting Preferences to close. (In reply to comment #2) > See also bug 558290. The question here is, should we close the preferences > dialog when the user clicks the button? On some systems the dialog is modal > which stops us from open it in a new tab without closing the preferences dialog > first. Yikes - Preferences should never be modal. Which systems are currently like this, Henrik?

(In reply to comment #9) > The Preferences window should ideally stay open when the user clicks Manage > Add-ons. It should open in a new tab of the current window (if a window is > open). Do we bring the browser window that opened the add-ons manager to the front (probably hiding the options window)? > (In reply to comment #2) > > See also bug 558290. The question here is, should we close the preferences > > dialog when the user clicks the button? On some systems the dialog is modal > > which stops us from open it in a new tab without closing the preferences dialog > > first. > > Yikes - Preferences should never be modal. Which systems are currently like > this, Henrik? Windows.

(In reply to comment #10) > (In reply to comment #9) > > The Preferences window should ideally stay open when the user clicks Manage > > Add-ons. It should open in a new tab of the current window (if a window is > > open). > > Do we bring the browser window that opened the add-ons manager to the front > (probably hiding the options window)? Yes. It sucks, but so does everything else. > > (In reply to comment #2) > > > See also bug 558290. The question here is, should we close the preferences > > > dialog when the user clicks the button? On some systems the dialog is modal > > > which stops us from open it in a new tab without closing the preferences dialog > > > first. > > > > Yikes - Preferences should never be modal. Which systems are currently like > > this, Henrik? > > Windows. If there's no way to make the Preferences window non-modal, then yes, we should just the Preferences window in that case.

> > > (In reply to comment #2) > > > > See also bug 558290. The question here is, should we close the preferences > > > > dialog when the user clicks the button? On some systems the dialog is modal > > > > which stops us from open it in a new tab without closing the preferences dialog > > > > first. > > > > > > Yikes - Preferences should never be modal. Which systems are currently like > > > this, Henrik? > > > > Windows. > > If there's no way to make the Preferences window non-modal, then yes, we should > just the Preferences window in that case. It is very easy to make the preferences window non-modal for Windows, the question is if that is what UX want?

Can't really do anything here until bug 593687 is resolved one way or another I think

The erroneous and unwanted opening of the new window can easily lead to a complete loss of session if the users closes the browser windows in the wrong order.

The "Manage Add-ons…" button doesn't exist anymore (bug 513164).