ToDo: diffs FF114-FF115 #1689
Comments
some bugzilla tickets
|
|
any linux users want to comment on I know default is currently false, but I'm happy to add it now so I don't have to chase it up later /* 2612: disable middle click on new tab button opening URLs or searches using clipboard [FF115+] [LINUX]
* When true, on Linux, middle clicks on the new tab button will open the xclipboard contents in a new tab. If the
* xclipboard content is an URL, that URL is opened, and any other text is opened with your default search provider. */
user_pref("browser.tabs.searchclipboardfor.middleclick", false); // [DEFAULT: false]cc @rusty-snake |
|
It's default // Does middleclick paste of clipboard to new tab button
#ifdef UNIX_BUT_NOT_MAC
pref("browser.tabs.searchclipboardfor.middleclick", true);
#else
pref("browser.tabs.searchclipboardfor.middleclick", false);
#endifhttps://searchfox.org/mozilla-central/source/browser/app/profile/firefox.js#865 It relates to |
|
I'm not 100% sure what sort of comment you are requesting, but what I can tell you after 5 minutes of playing around with this is:
For reference, my setup is Firefox 115 (with AF) on Fedora Workstation 38 |
I know what you're getting at, so I'm going to flip this on it's head. The new tab button is specifically designed to be CLICKED .. it's a click magnet ... with multiple results - e.g. right click = containers menu, left click = newtab, and now middle-click (on linux). So it's VERY likely to be magnitudes of order greater as an accidental wrong click-type vs say, some page content. So to answer your question ... YES :)
We do set that (but I'm sure lots of people override that, trusting their search engine) in which case they trust their search engine - so in the case of a non-URL, this would only be fallback, or yet another pref to flip (assuming they want to use the middle click new behavior) So the question then becomes about not leaking URLs from clipboard. More to follow |
|
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40783#note_2854455
@rusty-snake is it really default false in Linux - if so we can remove it from the user.js |
Yes. |
actually, not sure when the default changed on linux, except pierov said it was in ESR102, so ... yup, we can remove it |
|
https://bugzilla.mozilla.org/show_bug.cgi?id=1828939 // Handing URLs to external apps via the "Share URL" menu item could allow a proxy bypass
#ifdef MOZ_PROXY_BYPASS_PROTECTION
pref("browser.menu.share_url.allow", false);
#endif |
AFAICT this is only true in a new 115 profile created offline. When I checked this string immediately after upgrading to 115, the actual value is The string will also repopulate itself after a restart (if you have emptied it manually) and FF will actually force itself to re-download RemoteSettings configs. If anyone wanted to disable it would probably be best to just use the |
|
^ yup, it's populated via remote services |
|
@mik0l thanks The WebShare API is only enabled on mobile (and windows if not stable release), it is behind the pref dom.webshare.enabled
|
|
it's not just linux .. flip the pref to true and try it in windows :) |
|
Please STOP force pref 0377c14 where mozilla decides where extensions should work - "mozilla remote access"
|
|
we already discussed this at length elsewhere and it was carefully considered, it is enforced to the default as the rest of the other security features in section |
Do you recall where this discussion took place? I didn't see it in the recent open or closed issues, but I may have overlooked it. |
FF115 is scheduled for release July 4th
FF115 release notes
FF115 for developers
FF115 security advisories
123 diffs ( 49 new, 55 gone, 19 different )
new in v115.0:
removed, renamed or hidden in v115.0:
7001pref("browser.cache.offline.enable", true); - 1677718changed in v115.0:
lvl2PBMremovedignore
click me for details
==NEW
==REMOVED, RENAMED or HIDDEN
==CHANGED
The text was updated successfully, but these errors were encountered: