Use of nsIMIMEService in content process is deprecated. StartupInitializer.js:273:16Use of nsIFile in content process is deprecated. loader.js:247:15mozilla::storage::Statement::BindInt32Parameter is deprecated and will be removed soon. (ismeretlen)unsafe/forbidden CPOW usage RemoteAddonsParent.jsm:902:2unsafe/forbidden CPOW usage bootstrap.js:2801unsafe/forbidden CPOW usage RemoteAddonsParent.jsm:902:2

WFM. The errors you posted don't appear for me and seem to be unrelated to stayopen. "bootstrap.js" is add-on related, but stayopen's bootstrap.js doesn't have 2801 lines.I just tested (on fx57):disable stayopenre-enable stayopenmiddle-click an item in location bar dropdownitem opens new tab and dropdown menu stays open

Those on release channels who won't update to fx57 really should move to ESR. There are a lot of add-ons that get broken in fx55 & fx56, so just staying on 56 is not really a good option. As I mentioned in a previous post, I have no idea what's causing the need to disable/re-enable, and that's a major issue. It's not something I can quickly fix, sorry.

WFM. The errors you posted don't appear for me and seem to be unrelated to stayopen. "bootstrap.js" is add-on related, but stayopen's bootstrap.js doesn't have 2801 lines.I just tested (on fx57):disable stayopenre-enable stayopenmiddle-click an item in location bar dropdownitem opens new tab and dropdown menu stays open

Those on release channels who won't update to fx57 really should move to ESR. There are a lot of add-ons that get broken in fx55 & fx56, so just staying on 56 is not really a good option. As I mentioned in a previous post, I have no idea what's causing the need to disable/re-enable, and that's a major issue. It's not something I can quickly fix, sorry.

Since you test on a different version than I did it's not surprising your results are different. The addon won't even be able to function on 57. (I didn't try 57, I see no point.)

Anyway, I did more testing. It looks like disabling/enabling the addon never helps, only changing a setting in the SOM menu does. (Not that any of them is practical)

I checked the error console with my test profile. (Which I didn't think of the first time ) I didn't get any errors.

Update:I did more testing, by changing extensions.{3541c267-2580-4144-854e-2e05c8670121}.* values. Only "extensions.{3541c267-2580-4144-854e-2e05c8670121}.fMenus" had any effect. (naturally, only when I changed it something when the urlbar is enabled:0,2,4,6)

PS:Come to think of it, some options are less than clear. What does the "Any other supported menus" include? What other menus are there? I have no idea what exactly the "Redisplay menu after Properties dialog closes" options is supposed to do. What menu after what options dialog?

Anyway, it looks like I found an ugly workaround, using another broken addon. I loaded my profile in FF55 and using Custom Buttons (which has an unofficial update that works up to FF55, but in FF56 button editing amongst other things is broken even with this) I edited the initialization code of one of my buttons to include code to flip the relevant setting:

avada wrote:Anyway, it looks like I found an ugly workaround, using another broken addon. I loaded my profile in FF55 and using Custom Buttons (which has an unofficial update that works up to FF55, but in FF56 button editing amongst other things is broken even with this) I edited the initialization code of one of my buttons to include code to flip the relevant setting:

There's no such thing, nor did I say so. Try re-reading my comment. It's all about the workaround for the buggyness of SOM. Otherwise you need override compatibility checks as usual: extensions.checkCompatibility.56.0;false

@custom.firefox.ladyI noticed another bug. (verified it on FF55 too) It seems like the auto close feature is always active not just after clicking on an item, as it should. So any time you move your mouse on and of the results it closes. Furthermore it closes just by moving the mouse if the results happen to move under the mouse cursor and away. It happens when the results become less than the limit as you type, and the cursors near the limit of the location bar results.

avada wrote:There's no such thing, nor did I say so. Try re-reading my comment. It's all about the workaround for the buggyness of SOM. Otherwise you need override compatibility checks as usual: extensions.checkCompatibility.56.0;false

GHM113 wrote:Bug 260611 - "leave bookmarks menu open when I middle click or ctrl click a bookmark" has landed. Thank you very much, custom.firefox.lady! I can now very conveniently open multiple bookmarks at once

Sadly it's for the bookmark menu which 100% don't use (not even for the history menu? which I also don't use). (I have both of them hidden via CSS, I see no point in using them when the sidebar is available, and which always stayed open. Even when middle-clicking folders)To me only urlbar, panels and button-menus (context menus?) are of interest.

avada wrote:Anyway, I did more testing. It looks like disabling/enabling the addon never helps, only changing a setting in the SOM menu does. (Not that any of them is practical)

shellye5 first reported the disable/enable workaround and it WFM. Obviously not practical (on every restart); that's why it's marked Incompatible with Firefox 56.

avada wrote:Come to think of it, some options are less than clear. What does the "Any other supported menus" include? What other menus are there? I have no idea what exactly the "Redisplay menu after Properties dialog closes" options is supposed to do. What menu after what options dialog?

Any other supported menus is a catchall for various stayopen enhancements to other extensions (TMP, Context Search, Stylish). Redisplay menu refers to context menu > Properties (edit bookmark, dismiss dialog, stayopen reopens the bookmarks menu to where you were).

avada wrote:@custom.firefox.ladyI noticed another bug. (verified it on FF55 too) It seems like the auto close feature is always active not just after clicking on an item, as it should. So any time you move your mouse on and of the results it closes. Furthermore it closes just by moving the mouse if the results happen to move under the mouse cursor and away. It happens when the results become less than the limit as you type, and the cursors near the limit of the location bar results.

Confirmed, thanks for the info, might be useful knowledge even though stayopen is now otherwise incompatible.

Expecting some confusion (reading the bug's > 100 comments not practical either); here are the details:

The new pref works (with Ctrl-click or middle-click) on:Bookmarks menu (on the menubar)items in folders on the Bookmarks Toolbaritems in the Bookmarks Menu Button (no longer on toolbar by default, but still available via Customize)And w/o modifier on:'Open in a new tab' context menu item of a bookmark in one of the above locations

It does not work with:History Menus (requires special handling to avoid bug resulting in wrong item being opened)Location Bar dropdown (Bug 1364415- requires modifying totally different fx code)Folders (originally this was to prevent hiding the tabs confirm dialog "opening [way too many] tabs will slow down fx"; in my testing the menu would be closed by the dialog anyway - but uncertain whether that's OS specific)Recent Bookmarks in the Library Button (Bug 1398992 - requires modifying different fx code which was a moving target)Ctrl-Enter keyboard support (Bug 1398990 - devs didn't like my implementation and I can't think of a better method)