Closed Bug 1700239 Opened 2 months ago Closed 2 months ago

"View Image Info" is no longer present in contextual menus

Categories

(Firefox :: Menus, defect)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1702013
Tracking Status
firefox89 --- affected

People

(Reporter: yoasif, Unassigned)

References

(Regression)

Details

(Keywords: nightly-community, regression)

Attachments

(2 files)

Also seen on https://www.reddit.com/r/firefox/comments/mazcfu/what_the_heck_happened_to_view_image_info_when/

I ran into this today, while attempting to find out whether a page was using webp or png - I did eventually realize I could use page info, but I think that is far less discoverable.

In bug 1692552 it is noted that the page info panel is available via shortcut and via the tools menu, but the tools menu is not visible by default on non-macOS - and I don't know how someone would discover the shortcut without consulting help pages or enabling the menubar.

Can the removal of this menu item be reconsidered?

Regressed by: 1690029

(In reply to Asif Youssuff from comment #0)

Also seen on https://www.reddit.com/r/firefox/comments/mazcfu/what_the_heck_happened_to_view_image_info_when/

I ran into this today, while attempting to find out whether a page was using webp or png - I did eventually realize I could use page info, but I think that is far less discoverable.

In bug 1692552 it is noted that the page info panel is available via shortcut and via the tools menu, but the tools menu is not visible by default on non-macOS - and I don't know how someone would discover the shortcut without consulting help pages or enabling the menubar.

Can the removal of this menu item be reconsidered?

Thank you for reporting this. Having to scroll through and select dozens or even hundreds of images from Ctrl+I/Page Info is...unimaginably non-ideal!

(In reply to Asif Youssuff from comment #0)

Also seen on https://www.reddit.com/r/firefox/comments/mazcfu/what_the_heck_happened_to_view_image_info_when/

I ran into this today, while attempting to find out whether a page was using webp or png - I did eventually realize I could use page info, but I think that is far less discoverable.

I'm a bit confused. You could find this out using the "inspect" web developer tool, or (in most cases) by opening the image in a new tab. Is there some reason not to do either of those, which are still in the same context menu (and, being at the top/bottom, are easier to access)?

Is the only reason to use "view image info" to find out what the content type of the image is? And... why would you care about the type of the image in the first place?

Flags: needinfo?(yoasif)

You could find this out using the "inspect" web developer tool, or (in most cases) by opening the image in a new tab. Is there some reason not to do either of those, which are still in the same context menu (and, being at the top/bottom, are easier to access)?

I actually did try "Inspect" initially, but because the page was using a picture tag with multiple sources, the fallback image is what showed up in the inspector, not the image actually served to me. As far as opening the image in a new tab, I suppose that may have worked, but is a pretty indirect way of getting to this and I did not think of it - that is two steps instead of one.

Is the only reason to use "view image info" to find out what the content type of the image is? And... why would you care about the type of the image in the first place?

It was in this instance (for me), although I have used it in the past to get the images' dimensions without needing to view the image. Your proposed workaround above used to be an easy way to do this back when Firefox had a titlebar by default, and I could "View Image" to look at the dimensions and quickly go back. Today, this is more annoying as I need to hover over the tab title to get the tooltip containing the dimensions I am looking for. I don't know if it as obvious to look for metadata in the titlebar as it used to be, since it isn't present at first glance and is hidden behind a tooltip.

As far as caring about the image type - I was writing a web page and wanted to see whether I was getting the optimized webp image or whether I was getting the fallback image (like what Inspect seemed to claim).

Flags: needinfo?(yoasif)

(In reply to Asif Youssuff from comment #3)

You could find this out using the "inspect" web developer tool, or (in most cases) by opening the image in a new tab. Is there some reason not to do either of those, which are still in the same context menu (and, being at the top/bottom, are easier to access)?

I actually did try "Inspect" initially, but because the page was using a picture tag with multiple sources, the fallback image is what showed up in the inspector, not the image actually served to me.

This seems like an issue with the inspector that should be filed separately.

As far as opening the image in a new tab, I suppose that may have worked, but is a pretty indirect way of getting to this and I did not think of it - that is two steps instead of one.

I don't understand why you consider this 2 vs 1 step - it's still just 1 context menu item, and then having to either navigate the list in the page info dialog (which per reddit is allegedly only 60% of the time selecting the right image...) for the right image, or hovering the title of the tab. Or you could just copy image link and then the URL would distinguish what type you get (in this particular case, for the <picture> element). The page info dialog also doesn't seem any easier or harder to get rid of than the additional tab that "open image in new tab" would produce.

Is the only reason to use "view image info" to find out what the content type of the image is? And... why would you care about the type of the image in the first place?

It was in this instance (for me), although I have used it in the past to get the images' dimensions without needing to view the image. Your proposed workaround above used to be an easy way to do this back when Firefox had a titlebar by default, and I could "View Image" to look at the dimensions and quickly go back.

You could still enable the titlebar if this is important to you, or as you say you could use the tooltip.

Today, this is more annoying as I need to hover over the tab title to get the tooltip containing the dimensions I am looking for.

I suspect we would take patches that show this kind of metadata (size, image type) in the whitespace (well, grey / dark background) around the image in the image viewer document, if that's the main issue here.

As far as caring about the image type - I was writing a web page and wanted to see whether I was getting the optimized webp image or whether I was getting the fallback image (like what Inspect seemed to claim).

Again I would suggest the inspector here needs fixing. You could also rely on the network pane in devtools, if verifying server behaviour is what you're after.

Basically, there are a lot of other ways to get this information that should be just as easy if not easier (and that double up doing other work like showing you the image in a convenient size and place, unlike the weird preview in page info which also has other issues), this isn't a usecase most people have (which we have telemetry for), other browsers don't have an equivalent which further cements the understanding that this isn't crucial functionality, so the item got removed to try to simplify the menu and make it easier to find the items that do get use.

Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → WONTFIX

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

(In reply to Asif Youssuff from comment #3)

As far as opening the image in a new tab, I suppose that may have worked, but is a pretty indirect way of getting to this and I did not think of it - that is two steps instead of one.

I don't understand why you consider this 2 vs 1 step - it's still just 1 context menu item, and then having to either navigate the list in the page info dialog (which per reddit is allegedly only 60% of the time selecting the right image...) for the right image, or hovering the title of the tab. Or you could just copy image link and then the URL would distinguish what type you get (in this particular case, for the <picture> element). The page info dialog also doesn't seem any easier or harder to get rid of than the additional tab that "open image in new tab" would produce.

I don't think I had to navigate the list, it just showed me the information I wanted to see immediately - eg dimensions and type. Hovering the title of the tab is the second step, closing the tab or the window is equivalent. Copying the link location destroys the contents of my clipboard, so it doesn't really feel like a workable solution, and works even less well in cases where the location doesn't change but the type of image does (not an issue in the <picture> case).

Opening a new tab (or navigating to the image in the same tab in previous version) feels like more of an interruption than what seems to be the equivalent of an inspector panel: https://developer.apple.com/design/human-interface-guidelines/macos/windows-and-views/panels/

As far as caring about the image type - I was writing a web page and wanted to see whether I was getting the optimized webp image or whether I was getting the fallback image (like what Inspect seemed to claim).

Again I would suggest the inspector here needs fixing. You could also rely on the network pane in devtools, if verifying server behaviour is what you're after.

This seems far more complex than what was previously already available (the regression here).

Basically, there are a lot of other ways to get this information that should be just as easy if not easier (and that double up doing other work like showing you the image in a convenient size and place, unlike the weird preview in page info which also has other issues), this isn't a usecase most people have (which we have telemetry for), other browsers don't have an equivalent which further cements the understanding that this isn't crucial functionality, so the item got removed to try to simplify the menu and make it easier to find the items that do get use.

I understand wanting to make things easier to find, but there really isn't that many items here (in my testing) to be overwhelming, especially if grouped. Safari has two instances of "Save" (Save to Downloads/Save Image As...) and "Open Image" (Open Image in New Tab, Open Image in New Window) and doesn't feel heavyweight to me - they group those options together to make them feel like bundles of options. I think grouping would be more effective to organize the information hierarchy and to make things easier to find (and ignore) - removing things just make them impossible to find - or force users into unwieldy workarounds.

Email Image would have been a better candidate for removal (this was suggested in the reddit thread) - Chrome doesn't have this menu item, and emailing the image is a much more straightforward operation to workaround - copy, copy image location, even open in new tab and share. Chrome actually has a QR code generator when context clicking images, but no email image.

Can that be considered instead, if the concern is to simplify the menu and to eliminate items that don't have equivalent functions in other browsers?

Flags: needinfo?(gijskruitbosch+bugs)

For me, viewing image info was a way to quickly and instantly tell what, if any, metadata was embedded in an image...again, doable by opening the image in another tab and then also hitting Ctrl+I, but I think "view image info" is a vastly more useful menu item than "email image" — would prefer to see image info replace email image.

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

this isn't a usecase most people have (which we have telemetry for), other browsers don't have an equivalent which further cements the understanding that this isn't crucial functionality, so the item got removed to try to simplify the menu and make it easier to find the items that do get use.

I am not sure if I understand the logic behind this. What data do you have indicate that menu items with low usage actively hinder end users' ease in finding "the items that do get use"?

And asking end users to just use the Inspector is to assume all users to have at least some knowledge with HTML code. Is it reasonable to assume the "normal" users that Mozilla seemingly desperate trying to pursue are familiar with the Devtools? I would argue "View Image Info" is much more accessible and beginner friendly.

I also use "View Image Info" occasionally, so +1 for restoring it.

On the other hand I have never used "Email image" and would not miss it, if it was removed.

See Also: → 1700496

FYI, I filed the devtools issue to bug 1700496. I do not believe that really solves the missing feature here, but it would help work around one of the use cases affected by this issue.

Others - like finding out what format the image is when the filename retains the wrong extension (like when web servers transparently translate to webp from other formats) would continue to be harder to discover.

We carefully looked at options here and the reality is that twice as many users use "Email image" compared to "View image info". Also worth noting is that 85% of users using the "View image info" selection do it just once a month - i.e this entry has low user count VS other options AND the users use it very rarely (not a core workflow that a work-around should address without too much pain).
As Gijs outlined above there are are a lot of other ways to get this information and the intention here is to reduce entries with very low use in order to make it simpler for higher usage entries to be more easily discoverable.
I realize that the current users will have to learn the alternate way to achieve this action but this change is made with the intention to satisfy most users - this is never simple.

Flags: needinfo?(gijskruitbosch+bugs)

(In reply to Romain Testard [:RT] from comment #10)

We carefully looked at options here and the reality is that twice as many users use "Email image" compared to "View image info".

Obviously you have the data and I don't, but that's absolutely wild to me. Thanks for sharing, though.

Just sad to see more power-user-friendly workflows nerfed. :(

(In reply to Romain Testard [:RT] from comment #10)

Also worth noting is that 85% of users using the "View image info" selection do it just once a month - i.e this entry has low user count VS other options AND the users use it very rarely

I do wonder if it would be possible to shove it in a submenu or something, just to keep it around. 🤔

Duplicate of this bug: 1700864

(In reply to Romain Testard [:RT] from comment #10)

We carefully looked at options here and the reality is that twice as many users use "Email image" compared to "View image info". Also worth noting is that 85% of users using the "View image info" selection do it just once a month - i.e this entry has low user count VS other options AND the users use it very rarely (not a core workflow that a work-around should address without too much pain).

I don't understand why you wouldn't allow context menus to be user definable? You keep referring to options when you have removed an option.

Honestly, I'd love to know how many devs (or their working environments) even have telemetry allowed/enabled...

As Gijs outlined above there are are a lot of other ways to get this information and the intention here is to reduce entries with very low use in order to make it simpler for higher usage entries to be more easily discoverable.

And all of the ways are less convenient and involve extra steps: page info requires you to know what the media in reference is, or sift through them. For example I had to click through 8 or 9 of the images listed before I found your avatar since there is no interaction between the main window and the Page info window.

https://secure.gravatar.com/avatar/35c1f4c621a0d22ad40c441c592c7b52?d=mm&size=64 to then see it is 64x64 scaling to 32x32.

I realize that the current users will have to learn the alternate way to achieve this action but this change is made with the intention to satisfy most users - this is never simple.

Unfortunately that's not what I'm going to end up doing: if you've made this one function less usable and clearly your telemetry and the future of your UX/UI is catering towards people who would email an image from a website more frequently than they'd view an image quickly to see it's info, then it's clear that not using firefox for what I do should happen sooner rather than later.

For reference:

I want to right click an image and "view image info." It is one of the distinguishers as to why I use firefox for my main testing browser over chrome/other. No other browser had that it removed. I didn't yearn to use other browsers because "things in my right click weren't discoverable."

I do not want to, and have never:

  1. email an image
  2. set as desktop background

Further, I have other things in my right-click context menu courtesy of plug-ins whereas default functionality--that was just in my browser yesterday and is no longer there--is not immediately configurable.

I'm all for whatever your metrics are saying is "more discoverable" and leave that to whatever analysis you've done (though you clearly aren't separating your audiences between types of user, i find it VERY hard to believe that any front-end dev that was using firefox would not be using view image info (I used it a ton to see not only the image size but what scaling was happening)) but then meet me halfway and make configuration something that is easy to manage.

It could be that "...the reality is that twice as many users use "Email image" compared to "View image info". Also worth noting is that 85% of users using the "View image info" selection do it just once a month..."

But that audience is probably twice as many just day to day users who have no interest in View Image Info and don't care.

By removing the feature you are depriving the rest of the audience which are folks like web site developers, troubleshooters, support people of while it may not seem important to most users it is important to us.

The people that use View Image Info are very unlikely to use email image and set as background image - we are developers and will probably never use either of those features - never, ever.

Kludgy workaround suggestions are awkward and clumsy.

The number of folks in this topic should be an indication that the feature has value.

It would be prudent to reconsider the change or make it something we can turn on/off through some of the many "about:" options... Now there are some things that nobody will ever use.

Flags: needinfo?(jose_ease)

Here's a thought:

Why not make the right click menu configurable (maybe through about:config) - like with Windows you can add or remove things from the right click context menu for files/folders, etc. I'm pretty sure Microsoft is not just going to remove some right click option because somebody there thinks not enough people use it. That is very short sighted.

Instead of just removing what you think are options that most people don't use allow enabling/disabling of the right click options perhaps through something about:config or an .ini file.

That way users can be in control of the options and if they want/desire can "disable/turn off" things they will never use and "enable/turn on" the things they want to see offered.

The image info is useful since it tells you the path to the image (which I know can be revealed in other ways), the dimensions/size of the image and the Alt Text behind the image to name a few things.

If my customer says an image takes too long to load I can with one right click see the size and decide to do something about it.

If my SEO analysis says I have an image with no Alt Text I can take a look at that and decide what to do about it.

If I want my customer to tell me that information I don't want to help them learn how to use the Analyze or Inspect features and they don't want to know that level of detail.

If I want to use that image someplace else I can get the complete path to the image - or just select part of the displayed path to use somewhere else.

Just because somebody at Firefox can't think of ways to use that option doesn't mean other folks find the option useful and valuable.

Flags: needinfo?(jose_ease)

I've added image info to my extension. Due to its other features, it requires a lot of permissions, so it would be better if a dedicated extension could be developed that only requires activeTab permission (not sure it's possible).

https://addons.mozilla.org/firefox/addon/save-webp-as-png-or-jpeg/

(In reply to Jose Ibarra from comment #16)

The image info is useful since it tells you the path to the image (which I know can be revealed in other ways), the dimensions/size of the image and the Alt Text behind the image to name a few things.

If my customer says an image takes too long to load I can with one right click see the size and decide to do something about it.

If my SEO analysis says I have an image with no Alt Text I can take a look at that and decide what to do about it.

Understood. If you have the extension, you can right-click the image, then "Save webP as... " to show an overlay. Click the "i" button to toggle image info (this is sticky for the duration of your session).

Maybe that helps for the time being, but...

If I want my customer to tell me that information I don't want to help them learn how to use the Analyze or Inspect features and they don't want to know that level of detail.

... it seems unlikely to me that a customer will install an extension related to images unless it offers especially useful features, such as generating an email message with the details ready to send to you.

I use this feature all the time! It's so handy for me to find out the size of an image and to see if it is being scaled down.

Could we not get a checkbox in the settings that allows us to enable/disable this or even an official Mozilla add-on that re-enables this feature.

I have never used Email Image or Set as Desktop Background like a lot of others have mentioned above and in a Reddit thread.

Please bring this back.

Have to agree with other comments here about how useful this is/was. I can understand the usage stats - and maybe the desire to reduce the context menu size - but, for me, this was an indispensable tool in being able to quickly see exactly what image had been served up, from where and at what size (because the information showed both the original and sometimes unexpectedly different displayed size). You can't get this from opening the image in its own tab - and as others have noted, scrolling through the Ctrl-I list on an image-heavy page is a non-starter. Please do consider at least making this an option for those of us who would like to see it back in our context menus :)

See Also: → 1702013

After more discussion, we've decided that we'd take a patch to add a hidden pref to bring it back, and to enable that pref by default in devedition. bug 1702013 will track implementing such a change.

Gijs and team, I'd like to express my thanks for your reconsideration of this request by the community. Thank you!

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

After more discussion, we've decided that we'd take a patch to add a hidden pref to bring it back, and to enable that pref by default in devedition. bug 1702013 will track implementing such a change.

Awesome news, thanks so much!

When will we be able to re-enable it and will there be a guide on how to do it?

Thanks again 🙂

(In reply to Matt from comment #23)

When will we be able to re-enable it and will there be a guide on how to do it?

The core dev team is very time-pressured right now so we are unlikely to spend time working on it in the near future, so I'm afraid there is no date right now. I've marked it as a mentored bug for some of the outreachy projects we're hoping to run in the near future, and it may get picked up that way. Alternatively, all this code is CSS/JS/markup so if people following this bug are motivated to do so they are welcome to provide a patch themselves; I left instructions about the different moving parts in the bug already.

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

(In reply to Matt from comment #23)

When will we be able to re-enable it and will there be a guide on how to do it?

The core dev team is very time-pressured right now so we are unlikely to spend time working on it in the near future, so I'm afraid there is no date right now. I've marked it as a mentored bug for some of the outreachy projects we're hoping to run in the near future, and it may get picked up that way. Alternatively, all this code is CSS/JS/markup so if people following this bug are motivated to do so they are welcome to provide a patch themselves; I left instructions about the different moving parts in the bug already.

Ah OK, thanks for letting me know. If I need how to do that I would have contributed but unfortunately that's beyond my skillset.

Duplicate of this bug: 1702443

For bug managers: Maybe this bug should be duped to bug 1702013 (FIXED in Firefox 89)?

For other readers:

View Image Info is in Firefox 89 (beta) and should be available to you when Firefox 89 releases in June. You will be able to turn it on this way:

(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button accepting the risk.

(2) In the search box in the page, type or paste browser.menu.showViewImageInfo and pause while the list is filtered

(3) Double-click the preference to switch the value from false to true

(In reply to jscher2000 from comment #29)

For bug managers: Maybe this bug should be duped to bug 1702013 (FIXED in Firefox 89)?

Yes, thank you for flagging this!

Resolution: WONTFIX → DUPLICATE
Duplicate of bug: 1702013
You need to log in before you can comment on or make changes to this bug.