We should remove "View Background Image". It stopped being useful lots of years ago. Today backgrounds are often composed of dozens of images with borders that aren't obvious to the user, making the menu item lead to random tile images. The context menu as a web inspector doesn't scale.

I use this button relatively often for its intended purpose, and furthermore I have not once encountered a website where the image has been split up (what a waste of resources that must be!).

I apologize if this is too far off-topic for this bug. Is there a plan for an alternative way of viewing background images once this menu item is removed? I find that it is very common for sites to hide an image as a background image behind a transparent one, and that background images are often the ones I’m interested in. From the user’s perspective, there’s no difference between foreground images and background images; it’s a purely technical distinction. If I’m pointing at an image and I want to view it, I expect ‘View Image’ to work. At the moment, sometimes it works and sometimes it doesn’t, which is very inconsistent. It’s good that the extra menu item is being removed, since technical differences should not be exposed to the user. But perhaps ‘View Image’ could somehow take over the removed functionality by working for background images as well? My suggestion is that ‘View Image’ would appear as a ‘View Image ‣’ menu whenever there are multiple images stacked on top of each other. The menu would expand to show a list of images that can be viewed. Would this be possible?

(In reply to comment #3) > I apologize if this is too far off-topic for this bug. Is there a plan for an > alternative way of viewing background images once this menu item is removed? Maybe install Firebug? With CSS sprites and multiple background images, the "view background image" at some point is useless. At first I also thought "why remove this, its useful", but then I realized that I can do the same thing better with Firebug, so if the UI will become faster and less bloated I am for removing things like this. If the author of the site want to hide the images within background to prevent copying, he can hide it with various ways and "view background image" wont work at the end.

(In reply to comment #4) > Maybe install Firebug? You cannot ask the average user to install Firebug. The average user _expects_ ‘View Image’ to work. Working inconsistently is not good. Yes, there are many problems with the reliability of ‘View Background Image’. That is why I am in favour of removing it, as is being done here, and replacing it with a better interface that works more reliably and more consistently. My suggestion was a attempt at proposing such an interface.

(In reply to comment #5) > That is why I am in > favour of removing it, as is being done here, and replacing it with a better > interface that works more reliably and more consistently. My suggestion was a > attempt at proposing such an interface. View Page Info in the context menu or from the Tools menu, then select the media tab. Fairly convenient.

I'm going to take some time to consider this. On the one hand, I do like the idea of removing more and more from the context menu. On the other hand, I do want to ensure that some of the questions in comment 3 are answered. It may mean enhancing the Page Info functionality so that it's easier to do things like get at background images. /me will continue to think it over.

(In reply to comment #6) > View Page Info in the context menu or from the Tools menu, then select the > media tab. Fairly convenient. Not if you have to search through dozens of entries until you find the right one. And, more importantly, that does not solve the issue of user expectations and inconsistency (unless you want to remove ‘View Image’ as well). (In reply to comment #7) > /me will continue to think it over. Thanks Mike!

(In reply to comment #7) > I'm going to take some time to consider this. On the one hand, I do like the > idea of removing more and more from the context menu. On the other hand, I do > want to ensure that some of the questions in comment 3 are answered. It may > mean enhancing the Page Info functionality so that it's easier to do things > like get at background images. > > /me will continue to think it over. I have debated the same thing in Bug 528426. I looked at adding Background Image support to View Image Info and I would like to. However, to fix Bug 539068, which is for images that have a background image (like Wikimedia), I added a "feature" that View Image Info wont load background images so that Wikimedia and other sites behave correctly, which in turn invalidates Bug 528426. So I don't really know a clean way to do this, but I would be happy to work on it if there is an elegant solution.

I didn't file this bug because I disliked the "View Background Image" label, but because I don't think this belongs in the context menu. Making "View Image" and "View Image Info" cover background images would clutter the UI even more. There's a fundamental difference between <img> and background-image. The former is part of the content whereas the latter is part of the styling, most of the time. If you're interested in how the styling is implemented, Page Info, View Source, DOM Inspector and Firebug are your friends. Cases where the CSS is used for content seem rare enough that we shouldn't let these dictate the UI for every right click on any page.

I am wondering if we should also get rid of "View Image" which would consolidate all of these similar image functions into "View Image Info". If we did that--and moved "View Image Info" lower in the context menu with "View Page Info"--we would consolidate three current context menu features into one and add useful information for background images to View Image Info at the same time since background images are already in Page Info, which would be more efficient and reduce the excess UI. I agree that a background image and an image tag are different and that the latter is far more important, but many projects and websites use background images as if they were image tags (like the Wikimedia logos), which the current implementation of View Image Info prevents the user from getting any information about the image quickly. So, currently, the only way that a user can access any information about a background image is through View Background Image and then running View Image Info on it; therefore, consolidating the features consolidates user clicks.

(In reply to comment #11) > I agree that a background image and an image tag are different and that the > latter is far more important, but many projects and websites use background > images as if they were image tags (like the Wikimedia logos), Even if you're on such a page, there will likely be ordinary background images, where a "View Image Info" entry wouldn't make sense when clicking on a random part of the page. So making the item work like that wouldn't be as clearly a win as you think it would be.

(In reply to comment #10) > Cases where the CSS is used for content seem rare enough that we shouldn't let > these dictate the UI for every right click on any page. Examples: Flickr for any image with restrictive settings, Amazon’s book previews, dating sites. You’re also making the implicit assumption that background images are useless to users. Regardless, ‘View Image’ not working for images that were not added via <img> breaks the expectations of those people who don’t intimately understand the technical differences. Consider Joe. Joe sees an image he likes, so he right-clicks on it in order to view it alone and possibly save it. Lo and behold, he discovers that this sometimes works and sometimes doesn’t. Soon enough, he stops stops using ‘View Image’ altogether. Though my own proposed solution in comment 3 is arguably clutter, simply having ‘View Image’ work for background images (or whatever image is at the top of the stack) is not. These issues also apply to ‘View Image Info’, which is actually more useful, as pointed out in comment 11.

(In reply to comment #13) > Though my own proposed solution in comment 3 is arguably clutter, simply having > ‘View Image’ work for background images (or whatever image is at the top of the > stack) is not. It is, for the reason pointed out in my previous comment.

(In reply to comment #12) > Even if you're on such a page, there will likely be ordinary background images, > where a "View Image Info" entry wouldn't make sense when clicking on a random > part of the page. So making the item work like that wouldn't be as clearly a > win as you think it would be. We can tweak the parameters passed to function to be smarter. Bug 287048, for example, is easily fixed by not using shouldShow on "View Background Image" or "View Image Info" and changing what parameters we want to specify in the check for whether the item is available or not. By following the "View Image Info" solution we achieve two things: we phase this feature out rather than removing it outright (and we could ultimately remove View Image Info or even Page Info itself in the future, making them extensions) and we consolidate the behavior of our disparate image viewing functions. Currently we have "View Image", "View Background Image", and "View Image Info" (arguably "Copy Image" as well), each of these serves essentially the same purpose and we could consolidate these into one feature and resolve more clutter, and we would unify how the "View Image..." functions work in response to layered backgrounds. With View Image Info, whichever image (be it <img> or background) that is on top gets selected and then in the Page Info list, the other images below it are immediately accessibly because the majority of the time, the other backgrounds are listed before.

(In reply to comment #15) > (In reply to comment #12) > > Even if you're on such a page, there will likely be ordinary background images, > > where a "View Image Info" entry wouldn't make sense when clicking on a random > > part of the page. So making the item work like that wouldn't be as clearly a > > win as you think it would be. > > We can tweak the parameters passed to function to be smarter. Bug 287048, for > example, is easily fixed by not using shouldShow on "View Background Image" or > "View Image Info" and changing what parameters we want to specify in the check > for whether the item is available or not. I'm afraid we're talking about different things. I'm saying that when a background-image is used for styling (e.g. as a texture), the menu item doesn't add significant value but just clutters the menu (no matter how it's labeled). Bug 287048 is about showing the item in /more/ cases.

Which is what I'm saying, in the comment #15. By removing this feature and then tweaking the parameters of when "View Image Info" is shown in place of View Background Image, we can resolve both resolve your concerns about the illogical nature of the feature (which are totally valid) while resolving other issues of when it appears at the same time. By replacing this feature, we gain much more control of the functionality, and then it's a matter of UX deciding what cases, like links, merit having background image information available or not. I wouldn't want this functionality on background images that are 1px wide and 10px high, but on an image that is treated as if it were an <img> tag.

(In reply to comment #17) > Which is what I'm saying, in the comment #15. By removing this feature and > then tweaking the parameters of when "View Image Info" is shown in place of > View Background Image, we can resolve both resolve your concerns about the > illogical nature of the feature (which are totally valid) I didn't say it's illogical, but that it's useless clutter most of the time. Displaying "View Image Info" instead of "View Background Image" doesn't change this. > I wouldn't want this functionality on background images that are 1px wide > and 10px high, but on an image that is treated as if it were an <img> tag. I'd really like to see the algorithm that discriminate between these two kinds.

(In reply to comment #18) > I'd really like to see the algorithm that discriminate between these two kinds. I have a basic version of one in the View Image Info bug, I'll post it in just a minute. I think it will work for users need and remove the majority of the clutter.

Dao: why do we want to call out background images as special? Can you help me understand why we need a dedicated context menu item for this as opposed to just making the background image something on which you can right click like with any other image?

Background images aren't objects you can right click on. They are properties of other objects. For instance, the free space on this page has a background image, but obviously you don't want to access this when right clicking on the free space.

(In reply to comment #21) > Background images aren't objects you can right click on. They are properties of > other objects. Again, a technical distinction that does not neatly correspond to a semantic distinction in practice. No normal user will expect a distinction, nor understand it. > For instance, the free space on this page has a background image, but obviously > you don't want to access this when right clicking on the free space. The background image on this page repeats only horizontally, not vertically. If I right-click on the image where it actually appears--at the very top of the page--there’s a good chance I’m interested in that image (and, thus, ‘View Image’ working there would be nice). If, however, I click on a random part of the page, since that image is not situated directly under the cursor, it is almost certainly not what I’m interested in. The fact that ‘View Background Image’ appears on random space on this page should be considered a bug, and I don’t think anyone here is asking for ‘View Image’ to appear there too.

I suppose there are common cases where a single 1px by 1000px image is repeated across an entire page in order to fill the entire content area with a gradient of some form. In those cases, indeed, clicking on the "background" of the page should end up with all the image-related context menu items - for the background image. This all makes sense to me; the fact that the image is specified as a property of a body object or other object remains an implementation detail. It's an image, and right-clicking on it should bring up the same options as right-clicking on any other image, shouldn't it?

Yes, an image is an image is an image.

(In reply to comment #23) > I suppose there are common cases where a single 1px by 1000px image is repeated > across an entire page in order to fill the entire content area with a gradient > of some form. In those cases, indeed, clicking on the "background" of the page > should end up with all the image-related context menu items - for the > background image. We have eight context menu items for images. Your not saying they should all appear when clicking on a web page that happens to have a background image, are you? > This all makes sense to me; the fact that the image is specified as a property > of a body object or other object remains an implementation detail. It's an > image, and right-clicking on it should bring up the same options as > right-clicking on any other image, shouldn't it? The fact that it's a property rather than an object indicates that it's decoration rather than content, but I said that already. On content images: A web page putting a photo in an <img> tag does it right. For that we need the context menu items. A web page using <div style="background-image:..."> for a photo does it wrong. We don't want this to be our model for which menu items should appear in which contexts. On decorations: They don't need to exist as image files; whether they do really is an implementation detail. -moz-linear-gradient is the most obvious counter example. So if you're saying users want the ability to access directly, copy, send etc. everything decorative that might be an image (which I find highly questionable), we're not going to be able to meet that expectation.

I've another issue for consideration: if a web page presents a particularly large image I will often use View Image to have Firefox display it scaled down to fit. View Image Info doesn't have that functionality, and even if it was added the dialogue is far smaller than an actual browser window. Dragging the image onto a new tab is not an intuitive solution, and in addition has an unexpected outcome if the image is a link.

(In reply to comment #26) > I've another issue for consideration: if a web page presents a particularly > large image I will often use View Image to have Firefox display it scaled down > to fit. View Image Info doesn't have that functionality, and even if it was > added the dialogue is far smaller than an actual browser window. That's been bothering me, too; I have even wondered if we need more drastic changes to the Media Tab UI than this. Do we have a bug open for either changing the UI or at very least addressing large images better? If not, please file one. > Dragging the image onto a new tab is not an intuitive solution, and in addition > has an unexpected outcome if the image is a link. I tested it on several images, and I haven't found a situation where an unexpected outcome occurred. However, if we don't have bug open for that problem, please also open one for it.

The "unexpected outcome" I meant was the link opening in the tab instead of the image. That's not a bug. ;)

> We have eight context menu items for images. Your not saying they should all > appear when clicking on a web page that happens to have a background image, > are you? Not at this point, here we are removing one context menu item and replacing it with one other that only appears in some of the contexts that the original feature did. If we use View Image Info, it already has the majority of the functions of the image context menu items built in. If we start consolidating these items, there is the possibility in the future of removing other items like "View Image" or "Copy Image" or "Set As Desktop Background" and have them solely as part of the Page Info functionality and reduce more potential UI clutter. > The fact that it's a property rather than an object indicates that it's > decoration rather than content, but I said that already. I'm not convinced that users wouldn't necessarily want to look at information about decorative image material. > On content images: A web page putting a photo in an <img> tag does it right. > For that we need the context menu items. A web page using <div > style="background-image:..."> for a photo does it wrong. We don't want this to > be our model for which menu items should appear in which contexts. We're not saying that at the moment, we suggesting making the way that UI treats images as more consistent. Truly, an image is an image is an image. There may be implementation differences or details, but to the end user there is no visible difference. We haven't dealt with the opposite possibility of someone floating text over an <img> tag and treating it instead like a background. With the current implementation, such a case would be treated as if it were an image, because it is one. Therefore, let's take this opportunity to remove View Background Image and replace it with a more intuitive option that only looks at backgrounds attached to the element on the surface (which View Background Image should have done to begin with). This reduces a lot of the clutter that View Background Image made, and we can move towards making the UI's treatment of images more logical and consistent. > On decorations: They don't need to exist as image files; whether they do really > is an implementation detail. -moz-linear-gradient is the most obvious counter > example. So if you're saying users want the ability to access directly, copy, > send etc. everything decorative that might be an image (which I find highly > questionable), we're not going to be able to meet that expectation. That's not what we're suggesting at all. The problem that needs to be addressed is that backgrounds serve a multiplicity of purposes on the internet. The differentiation between content and decoration has been convoluted--at best--through the development of the internet, therefore a distinction between content and decoration in this case leads to convoluted behaviors and results in the UI. Consistency reduces confusion. Less-confused users are happier and more productive users.

(In reply to comment #29) > > We have eight context menu items for images. Your not saying they should all > > appear when clicking on a web page that happens to have a background image, > > are you? > > Not at this point, here we are removing one context menu item and replacing it > with one other that only appears in some of the contexts that the original > feature did. If we use View Image Info, it already has the majority of the > functions of the image context menu items built in. If we start consolidating > these items, there is the possibility in the future of removing other items > like "View Image" or "Copy Image" or "Set As Desktop Background" and have them > solely as part of the Page Info functionality and reduce more potential UI > clutter. Now you're talking about reducing clutter for the <img> context. The multiple items don't hurt there, though; in fact, they should probably stay. They would hurt in the page context where they'd compete against Reload, View Page Info & Co. > > The fact that it's a property rather than an object indicates that it's > > decoration rather than content, but I said that already. > > I'm not convinced that users wouldn't necessarily want to look at information > about decorative image material. So, what's the convincing argument that they would? You need to make that when adding UI. > > On content images: A web page putting a photo in an <img> tag does it right. > > For that we need the context menu items. A web page using <div > > style="background-image:..."> for a photo does it wrong. We don't want this to > > be our model for which menu items should appear in which contexts. > > We're not saying that at the moment, we suggesting making the way that UI > treats images as more consistent. Truly, an image is an image is an image. > There may be implementation differences or details, but to the end user there > is no visible difference. There is. Content bears information, decoration doesn't. That's why View -> Page Style affects background images but not <img>s. That's why you usually print <img>s but not background images. "An image is an image is an image" is a ridiculous simplification of the matters, sorry. > We haven't dealt with the opposite possibility of > someone floating text over an <img> tag and treating it instead like a > background. With the current implementation, such a case would be treated as > if it were an image, No, it wouldn't, as the user would be right-clicking on the element containing the text. > > On decorations: They don't need to exist as image files; whether they do really > > is an implementation detail. -moz-linear-gradient is the most obvious counter > > example. So if you're saying users want the ability to access directly, copy, > > send etc. everything decorative that might be an image (which I find highly > > questionable), we're not going to be able to meet that expectation. > > That's not what we're suggesting at all. The problem that needs to be > addressed is that backgrounds serve a multiplicity of purposes on the internet. > The differentiation between content and decoration has been convoluted--at > best--through the development of the internet, therefore a distinction between > content and decoration in this case leads to convoluted behaviors and results > in the UI. I'm not sure in what way that's a response to my claim that a background doesn't need to be an image. If you want to enable the user to view information about a texture, you'll fail him in certain cases. If enabling the user to view information about a texture is not a priority, "View Image Info" shouldn't cover background images. > Consistency reduces confusion. Less-confused users are happier and > more productive users. "View Image Info" would confuse users in the context you're suggesting it should appear in, and thus make them less happy and less productive.

I’ve been thinking a bit about this and about my original proposal in comment 3, and I have a much simpler proposal. To recap, one of the main examples of stacked multiple images is a background image with a transparent image on top of it (where the vendor is specifically trying to prevent the use of View Image). This is common on dating sites, Flickr, Amazon’s book previews, and Google Books (I just counted three separate transparent layers on top of an image of a page), among others. The background image is sometimes done with background-image and sometimes with <img>; to the user, there is no difference. When a user right-clicks on such an image, my original idea was to show a submenu of all the images under the cursor. This would admittedly add complexity and end up showing many useless entries. My new proposal is to have ‘View Image’ (without ‘View Background Image’) to act upon the topmost _visible_ image. Fully-transparent pixels at the cursor position would simply be ignored. This proposal would also fix the current imperfection in View Image where I get a transparent gif half the time (there may already be a bug filed for this, but I could not find one). The above is just one use case where exposing the background image to the user is important. I myself am quite often interested in isolating a background image, which could be a photograph, an interesting icon, or simply a nice design. Declaring that people are not interested in such images is a value judgement based on a technical difference; different people are interested in different types of images. I say ‘technical’ because the distinction is invisible without viewing the source and because the semantic distinction is rarely adhered to. So, I don’t think you can declare all background images as irrelevant solely because sometimes they are arguably useless (though arguably still useful to some people, such as web developers). Finally, I’d like to ask, which situation will annoy users more: one where people see the “clutter” of ‘View Image’ sometimes when they don’t need it, or one where they often _want_ to use the command but it’s either completely unavailable to them (in the case of background images) or simply useless (in the case of transparent overlays) because of some technical distinctions they do not understand nor care about? And the former situation can also be improved by not showing ‘View Image’ for the most useless types of images, where people wouldn’t actually notice any images, and, thus, will not try to invoke View Image (perhaps using Tanner’s algorithm in bug 528426).

I don't see a reason why "View Background Image" should be removed. It's an entirely different thing from "View Image". Merging the two is not a good idea. It's quite clear what "background" refers to. As David Regev has pointed out, it's not uncommon that a user would want to view the background image (be it the page's background or the element's background). Limiting it to where the background image actually is might be helpful though. > On decorations: They don't need to exist as image files; whether they do really > is an implementation detail. -moz-linear-gradient is the most obvious counter > example. So if you're saying users want the ability to access directly, copy, > send etc. everything decorative that might be an image (which I find highly > questionable), we're not going to be able to meet that expectation. I believe the current solution works pretty well. "View Background Image" is disabled for background fills/gradients. Hiding the menu item when it's disabled sounds good to me though.

(In reply to comment #32) > I believe the current solution works pretty well. "View Background Image" is > disabled for background fills/gradients. No, it's enabled if the texture is an image file.

(In reply to comment #33) > (In reply to comment #32) > > I believe the current solution works pretty well. "View Background Image" is > > disabled for background fills/gradients. > > No, it's enabled if the texture is an image file. Is there any specification for that? It's not in the W3C Editor's Draft. http://dev.w3.org/csswg/css3-images/

There's some misunderstanding here. I never said/implied that it's disabled when the background is an image file.

You said it's disabled for "fills/gradients", but those can be implemented as images. This implementation detail shouldn't be exposed to users.

Sorry that I didn't phrase it clear enough. I meant solid colour/gradient fills. I'm in the opinion that the risk of "exposing the users to uninteresting patterns/gradients implemented as images" is one worth taking as there are many cases where the user might appreciate being able to get to the background image (even a pattern/gradient might turn out useful to an average user).

It's quite clear to me what you mean, and I disagree. I'm not convinced that the "many cases where the user might appreciate being able to get to the background image" outweigh the other cases where this UI is clutter. And how exactly would a pattern/gradient be useful to an average user? Note that we generally don't design UIs in ways that "might turn out useful", but for concrete, clearly defined use cases.

Copyright issues aside, patterns/gradients are useful for derived work or decorative purposes. Firefox's user base is diverse so I think it's unwise to arbitrarily conclude that users won't need/use it.

So you're talking about web developers, a minority that would be better served by add-ons that can expose the HTML and CSS implementation details in meaningful ways, like Web Developer or Firebug.

Not specifically web developers but designers, artists, students, etc.

Do you have crystal eggs? "View Background Image" shouldn't be removed. I wonder when you developers start learning to read other minds....

People on Twitter seem to like this feature: http://search.twitter.com/search?q=firefox+%22view+background%22

This should show a more complete picture: http://search.twitter.com/search?q=%22view+background+image%22 Some are lamenting the lack of that feature in Google Chrome and Safari.

IMHO, the background images and patterns (decoration/styling) are different from the content images and should be treated as such. The context menu item "View Background Image" should be preserved; when the cursor is on a content image, it should not be visible (just like it's working right now). For displaying the background images, the following strategy could be implemented: 1. If the background is a pattern (not an image file), it can be displayed as such (content removed). There would be no "Save image" option on right clicking it, though (or, if we can think of this as an enhancement, the pattern might be exported as an image file, however that seems like something more suitable for an extension/add-on as few people would need that). 2. If the background is layered (multiple images), then, as one earlier comment suggested, there can be a right pointing arrow alongside the "View Background Image" context menu item, pointing to which would pop up a sub-menu with the names of all the layered images, possibly with little thumbnails to aid the user in selecting the right one. Clicking any of them would then display that image. 3. If the background has a single image, it should work as it does at present. 4. If there's no background image/pattern, the context menu item "View Background Image" should disappear, as it does right now. Plus, consider opening the background image in a new tab/window which as detailed in the bug 650764 is better for the users with a slow connection (saves from reloading the original page).

I use this button relatively often for its intended purpose, and furthermore I have not once encountered a website where the image has been split up so can there be a easy way to toggle this on off(firebug is not too friendly with casual users)

Comment on attachment 428206 [details] [diff] [review] patch Clearing old ui-review flag.

Close as WONTFIX?

No assignee, updating the status.

No assignee, updating the status.