User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

Follow-up to Bug 1690030, which made it so that the "View image" button in the context menu when right-clicking on an image is replaced by a "View image in new tab" button.

Actual results:

There is no longer a way to open an image in the same tab.

Expected results:

There should be some way to still open an image in the same tab. In his comment at https://bugzilla.mozilla.org/show_bug.cgi?id=1690030#c8, Neil suggested re-utilizing the common CTRL+click/middle mouse shortcut on the button to open the image in the same tab, but since those keys are almost universally regarded as a new window/new tab shortcut, I believe this would be somewhat unintuitive.

I would prefer a new about:config preference that switches the default behaviour for the "View image" button in the context menu. Personally, I have been using the middle mouse on the "View image" button to open an image in a new tab for so long that I'd prefer not having to retrain my muscle memory.

Reproduced on the latest versions of Firefox Nightly 88.0a1 (2021-03-18) and beta 87.0.

Setting flags and assigning it a Severity of S4.

(In reply to Andrei Purice from comment #1)

Reproduced on the latest versions of Firefox Nightly 88.0a1 (2021-03-18) and beta 87.0.

Setting flags and assigning it a Severity of S4.

I don't understand, bug 1690030 only landed in 88 less than a week ago (2 weeks after 87 branched) and wasn't uplifted, so it's not possible that you reproduced this in 87...

I don't think there's a clear way forward here. As comment #0 implies, inverting the middle-click behaviour will likely break more people's workflow than it fixes, and it's not clear to me why opening in the same tab is beneficial, and/or that it's worth trying to come up with a way of making opening the image in the same tab easier than "open image in a new tab, close other tab". The context menu's behaviour is now also more compatible with other browsers, and AFAIK they don't have a way to open the image in the same tab, either. I'll check in with UX in case they have good suggestions on what to do here, but I suspect this is just something we'll have to accept as a consequence of the changes here.

OK, after a conversation with a number of engineering, product and UX folks, we considered a few options:

1. Add a second menuitem to open the image in the same tab.
2. Revert the change
3. Use the modifier/ctrl-click behaviour to make the "open in new tab" functionality open in the current tab instead

Unfortunately, all of these have serious downsides. The first one makes the menu longer (and especially for images wrapped in links it's already pretty long...), and duplicates functionality, which also introduces user doubt (which of these 2 items do I want?).

(2) would mean that the image functionality doesn't do what most people want by default (everyone I've heard, even people on this bug and bug 1690030 who suggest they want to be able to open the item in the current tab, suggests they have muscle memory to open things in new tabs using modifiers!), and doesn't match what people expect when coming from other browsers, which is annoying for most users.

(3) would mean that we'd break people's muscle memory worse than we do now, again for the option that most people want. Although muscle memory can be retrained, it would be permanently inconsistent with how other items in the same menu behave. We have other inconsistencies like that but we try to minimize them where possible.

So none of these look like a good solution here, and we concluded we won't be making further changes.

Of course, for people who have workflows where this kind of item is a necessity, it would be straightforward to create an add-on that does exactly this (ie that adds a context menu item that appears for images, which then navigates the current tab to the image URL).

would mean that the image functionality doesn't do what most people want by default (everyone I've heard, even people on this bug and bug 1690030 who suggest they want to be able to open the item in the current tab, suggests they have muscle memory to open things in new tabs using modifiers!),

This is weird. Most of the time I use this to escape from broken image viewers on pages. For example imgur where I cannot view the image in full dimensions. For example when I browse reddit, open imgur link in new tab, image it too small, so I then open image directly. I will not like to open yet another tab with image only and then bother to close two tabs instead of only one.

it's not clear to me why opening in the same tab is beneficial, and/or that it's worth trying to come up with a way of making opening the image in the same tab easier than "open image in a new tab, close other tab".

Mostly because it's one fewer click. "Open image in (foreground) tab" is actually the option I use the least of the three (open in current tab, open in foreground tab, open in background tab), because either I don't need the current page anymore (so I just open the image in the current tab) or I do still plan to use it (and I generally open it in the background to look at it later, likely after opening some more images from the current page).

(everyone I've heard, even people on this bug and bug 1690030 who suggest they want to be able to open the item in the current tab, suggests they have muscle memory to open things in new tabs using modifiers!)

Correct. I do have muscle memory for that, because I regularly use both options. Same for ctrl-shift-click to open the image in a background tab (which still works). Using the new feature doesn't mean that losing the old one isn't a regression.

and doesn't match what people expect when coming from other browsers

Proton actually still doesn't match Chromium (which is the only other browser I have installed on this machine). Chromium opens the image in a background tab by default, while the new menu entry opens the image in a new tab and switches to it.

it would be straightforward to create an add-on that does exactly this (ie that adds a context menu item that appears for images, which then navigates the current tab to the image URL).

This is true, but it suffers from the same problem as (1), while being even worse. The "View image" context menu entry wouldn't be grouped with the other image-related options.

FWIW: my personal preference is (2), because it is in the muscle memory of Firefox users and not some hypothetical users that may come from other browsers, because it's consistent with other interface items (e.g. opening bookmarks, clicking a link) and because it's the most versatile, as all options are easily reachable using a keyboard modifier.

(In reply to :Gijs (he/him) from comment #4)

(2) would mean that the image functionality doesn't do what most people want by default (everyone I've heard, even people on this bug and bug 1690030 who suggest they want to be able to open the item in the current tab, suggests they have muscle memory to open things in new tabs using modifiers!), and doesn't match what people expect when coming from other browsers, which is annoying for most users.

The old implementation allowed for the both the old and new functionality (with modifiers as you say), but those modifiers are standardized across this browser and others (left click = "open in same tab", middle click or ctrl + click = "open in new tab"), these modifiers are common to Firefox, Chrome, Edge, and Internet Explorer, and have been standard in brower UX for a very long time now.

The new implementation takes away functionality and doesn't replace it, there is no modifier (standard or otherwise) to "open in same tab"

(3) would mean that we'd break people's muscle memory worse than we do now, again for the option that most people want. Although muscle memory can be retrained, it would be permanently inconsistent with how other items in the same menu behave. We have other inconsistencies like that but we try to minimize them where possible.

I agree that implementing backwards functionality for previously standardized modifiers is probably a terrible idea, though at the very least it would allow for all previous functionality to be available.

Of course, for people who have workflows where this kind of item is a necessity, it would be straightforward to create an add-on that does exactly this (ie that adds a context menu item that appears for images, which then navigates the current tab to the image URL).

Asking users to re-implement previously existing functionality appears to be a very user-unfriendly decision. I can understand minimizing user confusion if your telemetry says people generally prefer to open images in new tabs, but you ought to at least allow users to pick the functionality that works best for them, particularly if you are deleting previously existing functionality. At least an about:config option for power users that would go that far.

If length of context menus is a major concern (and I can understand and get behind that decision), at least give people the option (maybe again in about:config") to enable and disable context menu options. As has been mentioned in other threads on this topic, I only ever click "Email Image..." as an accident and used "View Image" (in the same tab) quite frequently, as seems common with other developers and tinkerers. I would very happily disable "Email Image..." and "Open Image in New Tab" and re-enable "View Image". If that were an option, both default users and power users could then get their preferred functionality, and at least in users like my case, they would have an even shorter context menu than default.

I've actually looked into this in the past, and the current option of manually editing user chrome appears to be almost entirely un-supported, rather difficult to do, and has a good potential of breaking or being reverted in later official updates. An officially sanctioned means to do this would be very useful.

As for user preference and expectations, I know for a fact that Firefox is dealing with the issue of users dropping Firefox for Chrome. Providing less reason for users to switch away and/or reducing resistance to adopting Firefox as a new browser is a good and laudable motivation behind making UX changes, but personally the reason I (and many people I know) adamantly stick with Firefox and advocate for others to use it instead of Chrome is because it better allows users to customize and tune their user experience, and (had been at least) less likely than other products to intentionally "dumb the interface down" as is a common development trend lately.

If Firefox chooses to reverse course on that design philosophy and instead plans to make their product match Chrome entirely because that's what mainstream users expect, I would predict that not only would you not regain the users that are used to and currently use Chrome today, but you'll additionally lose power users and those who prefer customization like me, because there will no longer be that reason to stay. The browser market really needs greater diversity and choice than less, at least IMHO.

The best solution here is really to add an about:config option that can revert to the old behaviour. This way new users can get more used to the Firefox UI and familiar users do not lose any functionality.
I know of a few reasons when I use view image instead of a new tab and making this change is really damaging my user experience.
If it would have to be of any of the 3 options given above then I would also choose number 2, as it does not limit functionality and is better for users who already use Firefox, which should be first priority.

I very much agree with the statement from jknoxiii

I'd just like to voice that I would also like an option to be able to re-enable to option to open images in the same tab. I used this very frequently and have found working around the issue by opening in new tabs to be annoying, if I may be so blunt.

I'll leave aside my gripes on why I think removing basic image menu options like this is an odd move, to say the least. I'll simply request that some method is implemented in order for this to be re-enabled.

I still maintain that this ought to be re-implemented as at least an about:config option, particularly so since it seems "View Image Info" is getting that treatment in bug 1702013. However, as to to :Gijs' comment above though:

(In reply to :Gijs (he/him) from comment #4)

Of course, for people who have workflows where this kind of item is a necessity, it would be straightforward to create an add-on that does exactly this (ie that adds a context menu item that appears for images, which then navigates the current tab to the image URL).

It appears someone has taken that on, and built an extension a few days ago: https://addons.mozilla.org/en-US/firefox/addon/view-image-context-menu-item/ . I'm not the developer and don't know them, but it appears to work pretty well (aside from some potential issues with errors for sites that use hotlink protection), and the code is dead simple (only a couple dozen lines altogether), so it's pretty easy to verify as safe despite not yet being well established.

I'd still like some version of this to be officially built in, even if hidden, but for the folks following this thread, this might be a good enough stopgap / replacement solution.

I'd like to have an about:config option for this as well. Changing behavior that was there for well over a decade isn't amazing. And "middle click = new tab" should be well known to users, since it's what they do on websites as well. So why not keep it here?

Using an extension for this is NOT a good option IMHO - it's at the end of the list, so the muscle memory from all those years is useless... It also takes up more space since it cannot replace the existing menu item (hey, remember when Firefox was more customizable and allowed replacing native UI elements? :))

(In reply to :Gijs (he/him) from comment #3)

more compatible with other browsers

Why does that matter? I use Firefox because it isn't "other browsers," you making it more like them does nothing for actual users.

This is a bad decision and should be reversed.

Suggesting that users install a third-part extension for us to get functionality that has existed in Firefox for many years is frankly stupid.

(In reply to jknoxiii from comment #7)

The old implementation allowed for the both the old and new functionality (with modifiers as you say), but those modifiers are standardized across this browser and others (left click = "open in same tab", middle click or ctrl + click = "open in new tab"), these modifiers are common to Firefox, Chrome, Edge, and Internet Explorer, and have been standard in brower UX for a very long time now.

(In reply to Adrian from comment #11)

"middle click = new tab" should be well known to users, since it's what they do on websites as well.

You appear to think this is well-known, but there is no discoverability for this, and I expect over 90% of our users have no idea about any of these modifiers - and even if they did, it would still be no substitute for sensible defaults.

Asking users to re-implement previously existing functionality appears to be a very user-unfriendly decision.

It's not so much asking them to do it as trying to be helpful in suggesting that it is possible to do this, if for some reason the previous implementation is a hard requirement for them (because, I dunno, their job involves opening images this way all day, or something).

you ought to at least allow users to pick the functionality that works best for them, particularly if you are deleting previously existing functionality.

I'm sorry but no, we do not "ought" to do that. This argument devolves to "all functionality you ever ship ought to be supported forever", which is not a tenable position for any software project.

Of course, you mean "no, not all of them, just this one" - but the data does not support making that decision here. I understand that that is frustrating and doesn't help you, but that's the reality of the situation.

because it better allows users to customize and tune their user experience

We haven't ever supported UI-based (not userChrome.css-based) customizable menus and this change hasn't altered that, so this isn't really an argument to revert or keep this change. And even if we did support such customization, all the options for items would still need to be implemented and supported by the Firefox engineering team (and/or add-ons) so there would still be cases where we'd add/remove/change items and not support them indefinitely, so I am not sure it would fundamentally address the unhappiness that occurs whenever we make any changes...

(In reply to Timvde from comment #6)

and doesn't match what people expect when coming from other browsers

Proton actually still doesn't match Chromium (which is the only other browser I have installed on this machine). Chromium opens the image in a background tab by default, while the new menu entry opens the image in a new tab and switches to it.

Can you file a separate bug for this? It would be useful to understand how we differ here. I expect it depends on the loadInBackground prefs, and I don't know if we'll need yet another one of those or what, but either way it feels like we should be deliberate about any mismatch here.

(In reply to :Gijs (he/him) from comment #13)

You appear to think this is well-known, but there is no discoverability for this, and I expect over 90% of our users have no idea about any of these modifiers - and even if they did, it would still be no substitute for sensible defaults.

I might just be a product of age and circumstance then, as I can't say 100% how I learned the modifiers except that they became second nature to me. I know i used Ctrl + click to open in a new tab (new window at the time) since I was an IE user (god almost 20 years ago at this point), probably because that was the behavior in Windows Explorer for opening folders in new instances. I used it all the time because living in the middle of nowhere with 56k dialup was aggravatingly slow if you didn't queue things up to load as you browsed. That behavior switched to new tabs once tabs became a thing when I switched to Firefox, and that was a big step up. Soon after, I learned middle click did the same thing, which was much more convenient. I imagine the other users that dislike the change in behavior here and mention the modifiers were similarly acclimated to those them and internalized them as a standard design paradigm (because I definitely would use them with "view image" if and when I did indeed want to see them in a new tab. I'm not sure how those modifiers could be "more discoverable" if that's a necessity to keeping them, but I know I'd be very upset if they disappeared entirely because I use them constantly as useful shortcuts, not only in Firefox, but elsewhere.

you ought to at least allow users to pick the functionality that works best for them, particularly if you are deleting previously existing functionality.

I'm sorry but no, we do not "ought" to do that. This argument devolves to "all functionality you ever ship ought to be supported forever", which is not a tenable position for any software project.

Of course, you mean "no, not all of them, just this one" - but the data does not support making that decision here. I understand that that is frustrating and doesn't help you, but that's the reality of the situation.

because it better allows users to customize and tune their user experience

We haven't ever supported UI-based (not userChrome.css-based) customizable menus and this change hasn't altered that, so this isn't really an argument to revert or keep this change. And even if we did support such customization, all the options for items would still need to be implemented and supported by the Firefox engineering team (and/or add-ons) so there would still be cases where we'd add/remove/change items and not support them indefinitely, so I am not sure it would fundamentally address the unhappiness that occurs whenever we make any changes...

I actually hadn't gotten into the userChrome.css stuff (until taking a peek in the last week or so), but that's not something that I think should be supported in a strict sense, even though it's very nice that it sticks around (for the scope of flexibility it adds even if it seems like a pain to work with). I was more talking about having a fairly large degree of customization in preferences / extensions / even the hidden about:config options. That level of customization is the sort of thing that makes or breaks software for me, and is the reason I prefer Windows or Linux to Apple OSX, or Android to iOS because they provide greater access to adjust the UI and functionality in ways that work better for my individual use-cases and preferences. Up to this point (and still) Firefox has been very good on that front, and again is one of the reasons I very much prefer it to Chrome or Edge.

I'll admit that UX designers like the ones behind Apple's software may have great reasoning for their design decisions, but the "my way or the highway" or "one size fits all" approach feels very heavy-handed and rankles me greatly. Giving the user the power to have multiple ways of doing things and to configure as they like is a massive plus for software in my book. As you say, it's not fair or reasonable to expect every feature to be supported and implemented for all time, but there should be very good reasons to drop functionality. I'm not sure "lack of discoverability" or "Chrome does it differently" are good enough reasons in my mind to do so.

Microsoft has also shot themselves in the foot with this sometimes, but I appreciate that they have usually made an effort to keep old and established interface options in place. (e.g. "the double click a title bar in the upper left corner to close a window" functionality probably should have died with Windows 3.1, since the actual close button moved to the upper right with Windows 95 two and a half decades ago, and is a feature with zero discoverability unless someone reads about it or stumbles into it, but it's sort of nice that they kept it around even in Windows 10 as an alternative.

In any case I appreciate the dialogue here and hearing about the rational behind the design decisions. The extension route has worked well enough for me in the meantime in this case. I just hope that future design and interface decisions are made with users like I and the others in these threads and an attempt be made to retain flexibility for configuration in the future. I know it's against the grain to most development paradigms as of late, but it's really something that makes me hang on to and advocate for software that allows for it, and is one of the reasons I like Firefox as much as I do.

Just to voice my concern about my broken workflow. I work with images a lot and this change impacts me directly. The addon above does not work for me as the location of the menu item is not the same, it's away from the cursor.

I had to downgrade Firefox in the meantime and I have no idea what I'm going to do next.

I also have to say that on some pages the View Image function of the 2 addons that reintroduce this do not load the image, even though the url is the exact same as if you open it with the official supported way. I am unsure if this is a Firefox problem or an addon problem.

(In reply to :Gijs (he/him) from comment #13)

You appear to think this is well-known, but there is no discoverability for this, and I expect over 90% of our users have no idea about any of these modifiers - and even if they did, it would still be no substitute for sensible defaults.

I believe there are a lot more modifiers that many users have no idea about and they will still be supported because some people need those in their workflow (or because they match chrome). Also, who decides what a sensible default is? Because it is used by other browsers? Does that make it sensible? How about the people who need this workflow, or got used to it for several years.
Another disadvantage here is that this change results in more tabs having to be open at the same time. People who work with a lot of tabs will have even less overview and this can be damaging.

(In reply to :Gijs (he/him) from comment #13)

It's not so much asking them to do it as trying to be helpful in suggesting that it is possible to do this, if for some reason the previous implementation is a hard requirement for them (because, I dunno, their job involves opening images this way all day, or something).

Well at least as of now it does not seem to be possible, or has not been implemented correctly by the addon creators. The other problem is that it is in a completely different position and gets pushed down by the other context menu entries of the other addons, and depending on amount can be pushed down pretty far. I feel like an option to have more customizability in context menus is a missing feature that would make this a whole lot easier as well.
It also is not only about users needing this in their job all day. As stated there are a few reasons why the old option is more logical to use, especially because it has no real disadvantages. The middle click and left click on the mouse are very close to each other and as I stated before Firefox users should come before other users.

Basically a feature here has been removed, replaced for a function that was already possible via a modifier, which at the same time breaks the workflow of some people, simply because other browsers handle this differently. I personally really do not see the advantage here.
For me personally the reasoning for this change is not enough for the damage it causes.

(In reply to :Gijs (he/him) from comment #4)

OK, after a conversation with a number of engineering, product and UX folks, we considered a few options:

1. Add a second menuitem to open the image in the same tab.
2. Revert the change
3. Use the modifier/ctrl-click behaviour to make the "open in new tab" functionality open in the current tab instead

....

I seriously can't understand why this was closed, nor why a bunch of (presumably) smart people couldn't come up with:

4. Provide an option/setting that controls whether the view Image menuitem opens in the same tab or a new tab.

You could even default it to the new functionality of opening the image in a new tab if you wanted. That way whatever the reason for the change is, those people are happy. While those you prefer/need the old functionality for it's time saving nature and don't mind staying in the same tab don't lose functionality. The name of the menu item wouldn't even have to change. Though the setting could also control that if you prefer to make it clear which is being used.

Again and again changes to Firefox are breaking prior functionality because apparently some users want it a different way, but done at the expense of those of us who liked a given feature the way it was. Or worse, previous flexibility in how the UI worked is removed. Replaced by a fixed option that makes Firefox more and more like chrome, and in a bad way. Ie Inflexible, and user unfriendly. I honestly miss the ability to customize firefox to my tastes that is slowly being stripped away.

I get that some tech changes might require fundamental changes at times. I'm not talking about that. I'm saying that a lot of these kinds of changes such as this one where the ability to view an image in the same tab is removed, are unnecessary. You can easily modify the feature and still preserve the option of doing it the existing way, and as noted even make the new way the default.

(In reply to arigato from comment #17)

why a bunch of (presumably) smart people couldn't

You could have just made your point without being insulting. We have participation guidelines, please keep them in mind.

4. Provide an option/setting that controls whether the view Image menuitem opens in the same tab or a new tab.

You could even default it to the new functionality of opening the image in a new tab if you wanted. That way whatever the reason for the change is, those people are happy. While those you prefer/need the old functionality for it's time saving nature and don't mind staying in the same tab don't lose functionality.

They would, though - unlike e.g. bug 1702013 where adding an about:config pref is what we did (and we opted in devedition users), there's no obvious way to segment people who need the item to stay the way it was, and so there's no way to opt people in. So adding an about:config preference would mean we get to maintain 2 behaviours and labels forever (and make sure the access keys in the menu are unique no matter which option is shown, in all languages, and...), and only the dozen or so people CC'd on this bug and/or able to find the magic about:config pref via web search or whatever would get to keep the old behaviour. That would be good for my mental health because it would make everyone here happy, so I don't have to hear about how dumb I and my colleagues are anymore, but doesn't make for maintainable software.
Indeed, the second reason not to do this is that it doesn't scale. We made dozens of changes to context menus over the past few releases (hopefully some of the others also improved your workflow in other areas!), and if we introduced prefs for all of them that we then needed to support in perpetuity, it'd create even more of a mess next time we tried to change context menu code. about:config options aren't free.

(In reply to pasi123567 from comment #16)

I also have to say that on some pages the View Image function of the 2 addons that reintroduce this do not load the image, even though the url is the exact same as if you open it with the official supported way. I am unsure if this is a Firefox problem or an addon problem.

This is going to need more information and debugging, and this bug is not the right place to do that. I'd start by checking what the add-on is doing and reporting the problem to them, ideally with an example of a page where you're seeing this. If it turns out to be a Firefox problem, the add-on devs can file an appropriate bug report against the relevant webextension framework component.

Also, who decides what a sensible default is?

Our UX experts do, with help from the product team and the data provided by our users via telemetry. And sure, other browsers play a role in that (if everyone else is doing things X way, and you pick Y, you need a good reason that Y is better and doesn't confuse/disorient users) but so does their understanding of usability. In this case, it seems pretty straightforward that not replacing the contents of the tab reduces risk of dataloss (and/or time wasted waiting for the network if you have to go back in history to see the original page), more easily allows you to open other images from the same page in further tabs, etc.

(In reply to jknoxiii from comment #14)

I might just be a product of age and circumstance then, as I can't say 100% how I learned the modifiers except that they became second nature to me.

If it's any consolation, same thing here.

I just hope that future design and interface decisions are made with users like I and the others in these threads and an attempt be made to retain flexibility for configuration in the future.

I'll do my best to ensure that is the case.

I know it's against the grain to most development paradigms as of late, but it's really something that makes me hang on to and advocate for software that allows for it, and is one of the reasons I like Firefox as much as I do.

Thank you for your support.

(In reply to :Gijs (he/him) from comment #18)

there's no obvious way to segment people who need the item to stay the way it was, and so there's no way to opt people in. ....... and only the dozen or so people CC'd on this bug and/or able to find the magic about:config pref via web search or whatever would get to keep the old behaviour........about:config options aren't free.

After thinking about this I agree with it. No one would know about this about:config entry other than the people who used this until now. Which are a substainable amount of people but maintenance for it would be unpractical.

In this case, it seems pretty straightforward that not replacing the contents of the tab reduces risk of dataloss (and/or time wasted waiting for the network if you have to go back in history to see the original page), more easily allows you to open other images from the same page in further tabs, etc.

There are advantages for this change but more disadvantages. This change first of breaks some peoples workflows and removes a function. It creates for a need of more tabs open at the same time, can reduce browser performance. The problematic thing here is that the advantages that you have stated, have been possible already via modifiers but the advantages of the old functionality have been completely removed.

I do want to come back to one thing as an about:config option is not sustainable.

(In reply to :Gijs (he/him) from comment #4)

(3) would mean that we'd break people's muscle memory worse than we do now, again for the option that most people want. Although muscle memory can be retrained, it would be permanently inconsistent with how other items in the same menu behave. We have other inconsistencies like that but we try to minimize them where possible.

The first argument here is wrong. It would not break the muscle memory more. It breaks the muscle memory the same way with the only difference that the old functionality would still be accesable. I also don't see how this should be inconsistent with other context menu items. No other entry now has the option to open something or do something with the middle mouse as I believe. If we would add this option to open things in the same tab with middle click, then it would be consistent with many context menu entries, like "Open image in new tab", "Open video in new tab" and could be also used for "Open link in new tab".
Although usecase wise the option to reverse this change makes the most sense, as it would still have most of the advantages that have been stated.

So as a result of this change, "open image in new tab" takes half a click less (no ctrl instead of with ctrl, or left-click instead of middle-click), while "open image in same tab" takes infinity clicks more (it's impossible now. no, closing the old tab doesn't count).
How is that a fair exchange?

At the very least, it should respect the "When you open a link in a new tab, switch to it immediately" preference when using ctrl/middle mouse, that's what target="_blank" links do. Ctrl doing nothing at all (while shift continues to force a new window) seems like a missed opportunity, if not outright sloppy.
Also, maybe the opened image should get a copy of the tab's history (as if it was opened by way of "duplicate tab"). As the image view obviously can't contain any kind of on-page navigation elements, without a history you're pretty much stuck there if you close the originating tab. As you might if only having one tab was your goal.

(In the meantime, I'm copying the link into the address bar by way of a macro.)

Why would you do this?? I have autism and this change really triggers me. This is a feature I use everyday. WHy do you remove this and do this to me? I can't breathe right now. Please bring it back, I am literally physically hurting from this change right now!! I made an account just to beg you to please bring it back!! Why you break features people love and use???? This hurts so much I can't even right now this is giving me an anxiety attack!!

(In reply to dazel (she/them) from comment #22)

Why would you do this?? I have autism and this change really triggers me. This is a feature I use everyday. WHy do you remove this and do this to me? I can't breathe right now. Please bring it back, I am literally physically hurting from this change right now!! I made an account just to beg you to please bring it back!! Why you break features people love and use???? This hurts so much I can't even right now this is giving me an anxiety attack!!

I know that changes can be hurtful to user experiences, but you need to understand that the developers here have made these changes for reasons. May they be good or not. Thats why we can discuss this and talk about the disadvantages of changes, be serious about it and find solutions. Your comment sadly seems more like an attack, that the developers have to bring it back. This is not either useful information and the opposite of a serious discussion.
Please understand this, see the advantages and disadvantages of this change and dicuss them here.

Wow. Seeing the "wontfix" is what hurts the most.

It used to be up to me whether to open in current or new tab. I no longer have that choice.

Please consider making this configurable after all. You have discussed three possible approaches and I understand why you rejected them all. But there's always approach #0: an about:config option.

Here’s an add-on that restores the good “View Image” functionality:

https://addons.mozilla.org/en-US/firefox/addon/view-image-context-menu-item/versions/

Published within only 14 days of this bug being posted.

(In reply to :Gijs (he/him) from comment #4)

OK, after a conversation with a number of engineering, product and UX folks, we considered a few options:
2. Revert the change
(2) would mean that the image functionality doesn't do what most people want by default (everyone I've heard, even people on this bug and bug 1690030 who suggest they want to be able to open the item in the current tab, suggests they have muscle memory to open things in new tabs using modifiers!), and doesn't match what people expect when coming from other browsers, which is annoying for most users.
Was it actually annoying for people?
Are the records of people complaining and asking for this change?
Were there more people complaining about the old functionality then than there are complaining about the change now?
What exactly was stopping those people from using the middle mouse button or pressing Ctrl?

(In reply to Timwi from comment #28)

Here’s an add-on that restores the good “View Image” functionality:

https://addons.mozilla.org/en-US/firefox/addon/view-image-context-menu-item/versions/

Published within only 14 days of this bug being posted.

This addon is not the same. The button appears all the way down in the menu. The old view image was right under your cursor.

(In reply to notfood.dev from comment #33)

This addon is not the same. The button appears all the way down in the menu. The old view image was right under your cursor.

You can move the button to the top of the context menu with some userChrome.css customization. Sure, it's hacky and definitely not ideal, but it does work.

(In reply to :Gijs (he/him) from comment #18)

Also, who decides what a sensible default is?

Our UX experts do, with help from the product team and the data provided by our users via telemetry.

Well, speaking of users, the new functionality seems to be pretty unpopular judging by this reddit post and comments. Personally, I'm going to downgrade to FF87 or ESR unless/until the old functionality is restored.

And sure, other browsers play a role in that (if everyone else is doing things X way, and you pick Y, you need a good reason that Y is better and doesn't confuse/disorient users) but so does their understanding of usability.

FF does some things differently, which is its appeal to me. In particular, the "View Image" function was by far my most used context menu selection, and similar functionality does not exist in Chrome or Edge. Why prioritize usability for Chrome and Edge users versus existing FF users? I guess the intent is to lure others into using FF, but it also encourages people like me to switch to a different browser now that FF has lost its "competitive advantage."

In this case, it seems pretty straightforward that not replacing the contents of the tab reduces risk of dataloss (and/or time wasted waiting for the network if you have to go back in history to see the original page)

In 10+ years of using FF, I don't think I've ever been at risk of dataloss by viewing an image in the same tab versus a new tab. I'm struggling to think of a plausible situation where that would actually occur. And any inconvenience I've faced by going back and reloading a page has been negligible and not worth the cost of having another tab open.

more easily allows you to open other images from the same page in further tabs, etc.

It wasn't that hard to middle-click "View image" to open a new tab.

In this case, it seems pretty straightforward that not replacing the contents of the tab reduces risk of dataloss

A website where accidentally navigating away results in dataloss that's more significant than typing a few words again should be using onbeforeunload.

more easily allows you to open other images from the same page in further tabs, etc.

As these tabs are now opened in the foreground no matter what, doing this has arguably become harder.

(In reply to notfood.dev from comment #33)

(In reply to Timwi from comment #28)

Here’s an add-on that restores the good “View Image” functionality:

https://addons.mozilla.org/en-US/firefox/addon/view-image-context-menu-item/versions/

Published within only 14 days of this bug being posted.

This addon is not the same. The button appears all the way down in the menu. The old view image was right under your cursor.

Also:

• It doesn't work on websites that don't allow offsite linking. Results in a 403 error.
• I don't like the security risks of installing new add-ons just to restore functionality. Will I have to do this again next update?

(In reply to Timvde from comment #6)

Proton actually still doesn't match Chromium (which is the only other browser I have installed on this machine). Chromium opens the image in a background tab by default, while the new menu entry opens the image in a new tab and switches to it.

(In reply to paremo from comment #37)

As these tabs are now opened in the foreground no matter what, doing this has arguably become harder.

Based on these comments, I think #1706487 is relevant here, and implementing my suggestion there may make these changes less upsetting for users.

Namely, if this change is kept, it really should obey browser.tabs.loadInBackground, the same as opening links in new tabs does. This is especially true because this preference is also exposed as a checkbox in about:preferences.

Apart from it not following that setting (which it should), this change actually doesn't bother me personally too much, since I was middle-clicking or ctrl+shift+clicking 'view image' most of the time before, anyway.

(In reply to joetache4 from comment #38)

• It doesn't work on websites that don't allow offsite linking. Results in a 403 error.

I think that could be implemented by the extension developer; it's not inherently a limitation of WebExtensions. It'd require for the extension to ask for "webRequest" permissions, but webRequest.onBeforeSendHeaders() looks like a viable way to accomplish this.

I just came across bug 1689782 and I really like the idea there. To save you a click: the proposal is to let modifiers indicate what is going to happen. Applied to this bug: if you hold ctrl, change the text in the context menu to "Open Image in New Tab". If you hold ctrl and shift, change the text to "Open Image in Background Tab". Then the default can stay as it is now, the modifier keys are more accessible, and we teach our users how to more efficiently use the browser.

Well, another one who found this surprise today. My firefox updated just a few hours ago and I don't understand this change.

Like others have stated, I used firefox because it's different to the other browsers. I don't want a wannabe chromium browser, I want firefox and that's why I've been using it for years.

I had to uninstall firefox 88 and install firefox 78.10.0esr. But I don't know what I'll have to do when the ESR reaches the stable channel version...

This is not the first time I lose a function I have been using for a long time because some developers decided it was best to remove it. Sometimes I could use it again modifying the parameter in about:config but others I couldn't and had to deal with it. But this time, for me, its a major change that can't understand why it was made....

And about the extension, I think the same that has been said. It's slower to have the view image in the bottom rather than the top. I want the original functionallity, not a patch...

I just made my account to add impression to the list. While I'll keep using Firefox, it does break my user experience as it happens to many people in this thread and I'm sure it makes me enjoy the program way less than you'd expect.
One of the things I liked about this option was that it made Firefox more versatile and taking out a feature really feels like a bad move on Firefox in my opinion. I found the option on my own long ago hoping it would work just like it does with links so are you planning on taking away that option too?
I see there are 2 extensions that were created more than 3 years ago that offered the new behaviour and they had less than 6k users together... I bet in reality it was even smaller. Finding these extensions was as easy as a search in Google "firefox open images in new tab" (first two results). Next result in my search talks about the use of the middle click to achieve it as it is mentioned in other pages as well so it wasn't that difficult to find a workaround if you really wanted it. But now, we miss a feature, whit the only choice to add yet another extension to Firefox that makes you have two similar options whit the default one being way less powerful.
I truly believe the change is a bad choice, and the refusal to recover the missing option in any way feels even worse.
It's also been stated that less than 10% of people knew about this. Well, even if the number is a bit higher, I don't think the percentage of people knowing about DoH is too high (I can tell you no one in my family does for instance and I don't recall any friend or co-worker (I'm a programmer) talking about it). I bet there are other functionalities that many people don't know about but you don't take them away and I wouldn't lower that percentage. Actually I'm sure a lot of people doesn't even use that option most of the time so if you only take into account people that really care about it's behaviour, the percentage that knows about it would be higher...

I am massively disappointed by this change and consider it a regression, absolutely.

There is a thread on reddit's /r/firefox forum related to this topic which, at the time of writing, has over 800 upvotes and 300 comments, most of them critical of these UX changes in Firefox's recent release:
https://old.reddit.com/r/firefox/comments/mwhtas/dear_firefox_developers_stop_changing_shortcuts/

To me this clearly demonstrates that the Firefox userbase does not approve of these changes.

Indeed, why would they?

• The functionality was available previously through the use of a modifier key (Ctrl+click or middle-click).
• The functionality was also previously available through extensions.
• Removing or changing well-established shortcuts or UX options which have been present for years in a product is generally a terrible thing to do in any software.
• Not supplying users with the ability to "undo" or customise this change is an absolute insult and smacks of inconsiderate development at best (developers not considering the end user's well-established preferences) or lazy/arrogant development at worst ("developer knows best").

Personally, if these changes aren't reverted, I will be leaving Firefox.

Created an account specifically to comment on this "bug". Absolutely atrocious decision right here, literally just removing basic functionality with no way to replace it.

I use "View Image" constantly, almost always in the same tab (but very occasionally in a new one, which we could already do before) and I ALSO used "View Page Info" fairly often as well, which has similarly been removed. The menu isn't even very long, but if things really need to be removed (which should always be left optional to the user) then "Email Image" and "Set Image as Desktop Background" are both useless entries I'd LOVE to have removed from my list.

I guess we'll have to keep relying on the community to re-add basic features through add-ons...

Would also like to add how disappointed I am with this change and how it's been handled so far.

There is a very clear indication from the community that this is something we'd like to be reconsidered. A reasonable alternative has been suggested (that wasn't originally considered by the dev team) but the topic has already been marked as resolved with no fixes needed.

It seems the reasons against an about:config option are that it wouldn't be very visible (which would be fine for the new users you're going for and would fix the issue for your existing userbase) and that you can't implement it for every change. But we're not asking for every change to have a way to revert it - we're asking for this particular one to because it seems from our perspective that a misjudgement has been made over the importance of this functionality. Looking back at past updates, it seems rare that a change as seemingly small as this has caused such a stir.

The reason I valued Firefox so much was for the level of customisation offered. Users have historically been empowered to make their own decisions and this is the complete antithesis of what made Firefox great. It's so sad to see things that make browsers unique dissolve in this way, especially when the reason given seems to have more negatives than positives.

There are also issues with relying on the community to fix this through add-ons, including support being dropped and the inherent security risk. Right now, the add-on adds an extra context menu at the bottom of the list which isn't ideal and new tabs aren't opened in the background (despite loadInBackground prefs). It feels like a plaster on a gaping wound.

This feature was part of my workflow (I also picked up middle-clicking when I needed a new tab instead because it was intuitive enough to discover naturally) and as somebody that does a lot of design work this was something that was extremely valuable. I understand changing it to appeal to a new audience, but completely removing functionality just to change the default seems like a misstep. I'm not the first in this thread (see comment #15) and I'm sure there are a lot of people that work with images daily that will be hampered by the change.

Firefox has been my favourite browser for over a decade and I have a huge amount of respect for Mozilla's approach to freedom and advocacy.
I sincerely hope you'll continue to listen to the community and reconsider.

Long descriptions in a menu are bad.

Open Image in New Tab <- this is too long

View Image <- this is much better

A fun cross reference: https://bugzilla.mozilla.org/show_bug.cgi?id=24533
22 years ago there was a great idea: for "View Image" to open in the same window. This was a time before tabs and before mice with dedicated back buttons, but the reasoning was comparable. It's nice to have the session history connecting between the webpage and the image. It's convenient to go back compared to closing a page. It's more consistent with other functionality. And so it went like this, with "View Image" being a humble little feature that, for a collection of little reasons, opened the image in the same window. And when tabbed browsing came along, it opened it in the same tab.

I want to make an appeal that "View Image" is not just a humble little feature that the little menu item makes it out to be. To me it was a big part of what made Firefox feel like Firefox. Not because I thought it was idiosyncratic, but because of what it stood for: instead of adding more to my hectic web experience, it cut things away. This concept is at the core of many things that Firefox either introduced or made popular: reader view, tracking protection, a powerful add-on architecture that led the way for ad blocking extensions. These are the features that established Firefox's identity in the web browser space, as the one that put the user first and that would help implement the user's discretion. View Image/Video didn't get didn't get their own press releases, but I have always counted them among these other beloved features. The same-tab View Image is for images what reader view is for articles and what uBlock Origin is for pages.

I loved having a way to free up the resources it takes to run all the features of a modern webpage, the analytics watching my every move, the unrelated videos playing in the background, the live comments streaming in, the chat bots popping up in the corner of the page, the peer to peer CDNs knitting my network into themselves, the cryptominers making a buck off my battery, or whatever mildly annoying thing will come next on the web. We can have this with Open Image in New Tab if we close the original tab, but then we lose our tab history, which is kind of annoying.

(In reply to microrffr from comment #50)

A fun cross reference: https://bugzilla.mozilla.org/show_bug.cgi?id=24533
22 years ago there was a great idea: for "View Image" to open in the same window. This was a time before tabs and before mice with dedicated back buttons, but the reasoning was comparable. It's nice to have the session history connecting between the webpage and the image. It's convenient to go back compared to closing a page. It's more consistent with other functionality. And so it went like this, with "View Image" being a humble little feature that, for a collection of little reasons, opened the image in the same window. And when tabbed browsing came along, it opened it in the same tab.

Agree, when you open image in new tab, you lose the capability to "back" to page where the image displayed. When you search and open a dozens images you'll quickly run into problem when trying to get back to the page before.

So for me this is regression. If you really want add experiences like other browser, then make it a new feature, not remove the current feature. Make it an option where user can choose which experience fit for them.

I'm quite annoyed with the change. Not because of muscle memory but because it just breaks quite sane functionality (maintaining context for the image and being able to "go back").

I skimmed the thread but small comment about this:

(2) would mean that the image functionality doesn't do what most people want by default (everyone I've heard, even people on this bug and bug 1690030 who suggest they want to be able to open the item in the current tab, suggests they have muscle memory to open things in new tabs using modifiers!), and doesn't match what people expect when coming from other browsers, which is annoying for most users.

I'm sorry most users and coming from other browsers? Judging at the Fx usage it seems that said most users are actually going somewhere else. And changes like this doesn't help.

If I wanted to have limited functionality in the first place I would use Chrome. I'm using Fx because it is NOT chrome and has additional value...

sigh, I hope you will revert this even though you already marked it as "wontfix" :sadface:

I wonder if anyone from Mozilla even still reads comments on a month-old WONTFIX.

Please don't needinfo people with questions like that. Thanks.

OK, after a conversation with a number of engineering, product and UX folks, we considered a few options:

1. Add a second menuitem to open the image in the same tab.
2. Revert the change
3. Use the modifier/ctrl-click behaviour to make the "open in new tab" functionality open in the current tab instead

Unfortunately, all of these have serious downsides. The first one makes the menu longer (and especially for images wrapped in links it's already pretty long...), and duplicates functionality, which also introduces user doubt (which of these 2 items do I want?).

The first one makes the menu longer (and especially for images wrapped in links it's already pretty long...)

I totally agree that it's too long already but perhaps if this fact is acting as a deterrent for a potential fix to such an impassioned topic, maybe some of those other menu items should be looked at for removal instead, to make room for other more important entries .

Namely "Email Image" and "Set Image as Desktop Background". Neither of these strike me as being high-value or highly useful features. The latter of the two is also given it's own section of the menu meaning it adds with it another seperator and the extra space that consumes:

https://i.imgur.com/8Eh01yC.png

and duplicates functionality,

One could argue "Open Link in New Tab" and "Open Link in New Window" or are as much "duplicates" as having "View Image" and "View Image in New Tab" would be. This would seem to indicate there are situations where two menu options with similar, but distinct, functionality are warranted.

I know you guys mean well, but I genuinely think that this is just a power-user blind spot, especially as they are very likely to disable analytics. I updated Firefox today and quite quickly noticed the change (along with the view image info and view page info changes). These are features that are unique to Firefox and set it apart from its competitors. Please could you guys reconsider or provide an option to restore the view image functionality?

As a workaround for now, you can drag the image onto the tab.

(Sad that I need to pair that with the habit I built of triple-clicking in the address-bar because single-clicking doesn't populate the X11 selection.)

This change really has to be reconsidered for the reason that this does not just affect a few people as believed by Gijs and the Mozilla team. (and myself at the beginning) As of today the addon "View Image Context Menu Item" has officially gained more active users than the addon "View Image in New Tab" with 1.369 users currently using it. You need to consider that not everyone will download an addon for this, to get back the old functionality and there would be even more users affected. This is not a small amount of people and the pure fact that now more people use this addon, than the addon that previously added the functionality that is active now on default, should be more than enough reason to reconsider this change. Other than that on the Firefox subreddit, also as previously mentioned, there were multiple posts with hundreds of likes of people upset particularly because of this change, which in itself should normally for such a little change, never get this amount of attention.

There are multiple ways to either reimplement the open image in same tab feature or to undo it altogether and many reasons have been stated how and why this should happen.
I would love if Gijs or another team member could give another reply with his point of view on this problem. Clearly a decent amount of Firefox users are affected and not just a few as previously thought.

Hi vilim,

Would you please explain what those links represent.

(It seems to me that if we're not going to fix the bug, we should mark the status as wontfix so that we don't track a fix for 89/90. RelMan should feel free to mark them differently if they feel like it.)

No matter how you slice it, this is taking away functionality for no good reason.
This change wasn't even documented in the patch notes.

It's patently unreasonable to break user workflows unasked, making a breaking change with no option to return to normal, then expect them to rely on third-party addons - addons that require user-granted permissions to critical browser functions - to restore functionality that Firefox USED to have.

The argument seems to be that it "doesn't match what people expect when coming from other browsers"! If people wanted a Browser that works exactly like Chrome, they would be using Chrome. By progressively axing more and more Firefox-unique things that make people prefer this browser, we are giving them less and less reason to use it. This is how Firefox bleeds.

I realize I'm pretty late to the "party" (I noticed the behavior but was busy with other things). It's a bit upsetting that despite the apparent controversy nobody seems to care particularly to understand and fix the issue (looking towards Mozillians here). To be blunt, talking to a few people, realizing there are currently no good options (https://bugzilla.mozilla.org/show_bug.cgi?id=1699128#c4) and therefore simply deciding to do nothing sounds a lot like walking away from an issue instead of addressing it.

What bugs me most about this change is that it
a) destroys functionality, i.e. usage of modifiers
b) destroys consistency I worked hard to establish in https://bugzilla.mozilla.org/show_bug.cgi?id=360332

Personally I have two workflows.

1. Quickly view image at full size in current tab
2. Open image at full size in background tab.

Both were working before, both are broken now.

As I understand it might be desirable not to open an image in a new tab by default for many users here's a suggestion on how to address this at least partially (in a way that restores consistency and at least allows modifiers to be used):

• Use modifiers consistent with other menu entries (among others use whereToOpenLink() function [1]). By default that would mean left click = new foreground tab, middle click = new background tab).
• Revert the label change

We still need to figure out a way to open things in current tab. An idea could be to make even more consistent use of whereToOpenLink() function and add a preference eventually (so people can configure left click, middle click, etc. freely and to their liking). This is for a later point, though.

[1] https://searchfox.org/mozilla-central/source/browser/base/content/utilityOverlay.js#209

Hi, everyone -

We’ve reviewed all of the feedback about this change and discussed it at some length internally. Ultimately, we believe we're making the right decision for this feature, both on its own as as part of a larger effort to redesign and modernized the core experience of Firefox to be cleaner and more welcoming and easier to use for new and returning users. We recognize this change is frustrating for some of longtime users, and for whatever it's worth we aren't making it lightly.

We realize that some people want to view images in the same tab, in particular for efficiency reasons when using this action often, but available telemetry tells us users who use this entry more than once daily are very rare (less than 0.1% of our daily users, or 10% of users of the “View image” feature). And - while I concede, these aren't spectacular workarounds - drag and drop the image to the address bar, copy the image URL and paste it in the address bar, or use an add-on that provides this functionality.

The larger challenge we're addressing with this change - and several others like it - is at a higher level; one of the things our telemetry systems have shown us, unambiguously, is the number of people who've tried out Firefox, found some part of the product that behaves strangely (to them, based on their experience of other browsers) and decided it wasn't for them.

When that happens - and our research suggests it happens very early in a new users' experience of Firefox - these papercut bugs mean we've lost the opportunity to show that person anything else Firefox has to offer. And this happens to a shocking number of potential Firefox users.

None of them, of course, are in r/Firefox or Bugzilla to talk about it, but they're out there, and we'd like to hold their attention long enough to for them to see everything else Firefox has to offer.

So the line we need to thread with work like this is to make the first-contact experience with Firefox familiar and useful to people joining us from other browsers, while getting really specific about what makes Firefox different and how we can best express that. In some cases - like this one - that means we need to make changes that affect a lot of our long-time supporters, and it isn't because we've forgotten about you, or want to dismiss your concerns; it's because we want Firefox, Mozilla and the Open Web to be around for you to be a part of in ten or twenty years, and this is part of the work we're doing to get us all there.

Thank you for bearing with us through these changes; I know we don't always make it easy. But we're confident it's work worth doing, and the right work to be doing.

So what about allowing configuration? Modifier keys? Honouring, even conditionally, browser.tabs.loadInBackground - the eighth option in about:preferences? None of these have any effect on the experience of new users. With none of them so much as mentioned, it is hard to read this post as anything other than an outright dismissal.

The add-on
a. doesn't let you open images in a background tab
b. requires scrolling all the way to the bottom of the menu
c. introduces an outside developer

What your "solution" is adds a security risk and still makes the it so it takes much much longer if I want to open a bunch of images in background tabs.

There are already a ton of configs and I doubt the view image functionality gets changed much; what's so hard about having a boolean "open image in same tab" that by default is off and if it's on restores the old one?

(In reply to paremo from comment #79)

Modifier keys? Honouring, even conditionally, browser.tabs.loadInBackground - the eighth option in about:preferences?

As previously noted (but hey, lots of comments, easy to miss...), this is bug 1706487, and we intend to fix that bug soon. With that bug fixed, the "open image in new tab" entry will open in a background tab in the default configuration of Firefox. It won't directly fix the summary of this bug (opening in the current tab). Still, with the image opening in the background, hopefully that will alleviate some of the workflow concerns raised here, as the selected tab doesn't change.

Modifiers in general have continued to work through this change and will continue to work to switch to opening in a window (shift click), or a foreground/background tab (with accel/accel-shift click).

Thank you Mike Hoye. I appreciate you explaining why this change was made and knowing the Firefox team is carefully evaluating our concerns. I'm now used to change and find it sometimes useful to have the image open in a new tab.

As previously noted (but hey, lots of comments, easy to miss...), this is bug 1706487, and we intend to fix that bug soon.

Does that mean you'll implement something along the lines of https://bugzilla.mozilla.org/show_bug.cgi?id=1699128#c76?

I have to admit I was also quite unsatisfied with the answer in https://bugzilla.mozilla.org/show_bug.cgi?id=1699128#c77 because it completely ignored my answer. Considering I suggested a way to keep the preferred workflow you're citing by default (so the concerns of the team are addressed and resolved) but also keep the feature powerful and suitable for advanced users via a preference, it felt a bit odd.

Regarding stats (which the Mozilla team seems to give too much weight): I find it generally frustrating if just one user is inconvenienced (without reason!) like in this case. As a FLOSS project we should aim to make Firefox great for everybody (it's the one thing that ultimately differentiates us from commercial software and pseudo-FLOSS like Chrome).
Even with your stats you actually showed that one out of ten people might use the feature in a way that might be inconvenienced with this change! That's not minor. IMHO you have to be very careful with stats, as they quickly have you ignore minorities, whereas I believe we have a chance to foster diversity (I'm almost certain Mozilla even has guidelines on this topic).

Let me know the plans for the feature (maybe in the other issues) because actual technical feedback would be nice; I lately find Firefox to be a very closed community (i.e. Mozilla seems to think they "own" Firefox and they make it very hard for volunteer and other "outside" contributors to participate, which seems like a very alarming development).

We’ve reviewed all of the feedback about this change and discussed it at some length internally. Ultimately, we believe we're making the right decision for this feature, both on its own as as part of a larger effort to redesign and modernized the core experience of Firefox to be cleaner and more welcoming and easier to use for new and returning users. We recognize this change is frustrating for some of longtime users, and for whatever it's worth we aren't making it lightly.
We realize that some people want to view images in the same tab, in particular for efficiency reasons when using this action often, but available telemetry tells us users who use this entry more than once daily are very rare (less than 0.1% of our daily users, or 10% of users of the “View image” feature). And - while I concede, these aren't spectacular workarounds - drag and drop the image to the address bar, copy the image URL and paste it in the address bar, or use an add-on that provides this functionality.

I just want to thank you for giving an answer after all the feedback came in and telling us what the telemetry data shows. I very well understand why this change has happened and according to the data, it is very clear why this should be the new default. The feature what users use the most should always be default so this is a good change, to some degree.
As you stated it seems that around 10% of users used the View Image feature. This doesn't change the fact that there would still be enough users to be considered that preferred the old functionality and the main complain the community has, is just that the feature has been removed completely.

(In reply to :Gijs (he/him) from comment #82)

Modifiers in general have continued to work through this change and will continue to work to switch to opening in a window (shift click), or a foreground/background tab (with accel/accel-shift click).

A modifier key (middle click) for opening it in the same tab is an option that would make perfect sense without confusing anyone if this modfier is also used on other entries like open image/video/link in new tab. Then there is a consistency in this modifier (which was an issue you stated in the beginning of this bug) and would not remove the function a signifgicant amount of people would still use.

Thanks for giving us this update though and make us understand a bit better why the change has been made

(In reply to Mike Hoye [:mhoye] from comment #77)

but available telemetry tells us
one of the things our telemetry systems have shown us, unambiguously,
I do dearly hope that the irony of a privacy-focused browser focusing exclusively on users who allow it to phone home is not lost on you.
You're breaking your back to turn Firefox into something it's not. At this rate, the browser is turning more and more into Chrome-but-with-a-different-renderer, with everything but the privacy options, everything that makes it unique and preferable, sanded right off.

This alienates the potential users who would, and the real users who already do, prefer it over Chrome - in some strange attempt at getting the people who already prefer Chrome on board with a browser that they see no need to switch to. Please see that there is no future in this.

We realize that some people want to view images in the same tab, in particular for efficiency reasons when using this action often, but available telemetry tells us users who use this entry more than once daily are very rare (less than 0.1% of our daily users, or 10% of users of the “View image” feature). And - while I concede, these aren't spectacular workarounds - drag and drop the image to the address bar, copy the image URL and paste it in the address bar, or use an add-on that provides this functionality.

The larger challenge we're addressing with this change - and several others like it - is at a higher level; one of the things our telemetry systems have shown us, unambiguously, is the number of people who've tried out Firefox, found some part of the product that behaves strangely (to them, based on their experience of other browsers) and decided it wasn't for them.

There is a small problem with this line of reasoning - you assume that telemetry is the holy grail of how users use the browser and how they want to use it (in the future):

1. from what I know telemetry is optional, so while regular user may more willingly consent, more "power users" will probably refuse, which would be seen in this case (power users wanting and using the feature but showing up in your data)
2. you can't feasibly be innovative if you only rely on what's expected/used (then you wouldn't push web standards years ago)

Last bit - it was always possible to open image in new tab (and background tab) with modifier. Currently it's not possible at all (without addon).

While switching the defaults (from open in same tab to open in new tab) maybe add support for modifier? (though, that would be counterintuitive as usually clicking on link opens in the same tab and with modifier in new tab). On macOS there is also interesting solution - pressing "alt" when menu is open changes to alternative options - maybe worth exploring (I fully understand that this is mac-specific but maybe could inspire some other solution)

(In reply to nekkowe from comment #87)

I do dearly hope that the irony of a privacy-focused browser focusing exclusively on users who allow it to phone home is not lost on you.

(In reply to wojtek from comment #88)

There is a small problem with this line of reasoning - you assume that telemetry is the holy grail of how users use the browser and how they want to use it (in the future):

1. from what I know telemetry is optional, so while regular user may more willingly consent, more "power users" will probably refuse, which would be seen in this case (power users wanting and using the feature but showing up in your data)

If you want someone to care about your opinion, just turn on telemetry :^)

(In reply to vilim.lendvaj from comment #89)

If you want someone to care about your opinion, just turn on telemetry :^)

I do have it turned on though you underline it perfectly :D

Well, that's quite enough of that. Sorry, everyone, but this is our professional working environment as much as it is an issue tracker, and it looks like it's time to shutter this bug. Feel free to email me if you'd like to discuss this further, but think we've passed the point of constructive disagreement and gotten well into the other kind, and we don't do that here.