Images have a different context menu from the page itself, which is good. However, it is confusing for the user to click on a seemingly blank area and not find the context menus he is looking for, cause it is really a transparent image.
-> user interface design, doesn't seem to be a dup.
Assignee: Matti → mpt
Status: UNCONFIRMED → NEW
Component: Browser-General → User Interface Design
Ever confirmed: true
QA Contact: imajes-qa → zach
I intented to suggest something like this as a joke; now I notice that somebody really files this as a bug... An image is an image, therefore should get the image context menu, imho.
Futhermore, what with design using some transparent and some non-transparent images in several layers? =) I agree with Christian. If we really need provide page context menu for user, realize it by adding page context menu to image context menu for this case.
Ummmmmmm ... no. Interrogating the image under the pointer to find out whether it was transparent would be prohibitively expensive. And what about images that were only transparent in some places? What about semi-transparency in a PNG with an alpha channel? Etc. This problem is only likely to affect the user if he/she is trying to use an item quickly and gesturally (without reading the menu), i.e. choosing Back or Forward. That's why Back and Forward should be at the top of the shortcut menu for an unlinked image. (Unlinked images may be transparent, but this is extremely unlikely to be the case for linked images.)
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
The spacer.gif's used by many sites cause a usability problem, as mentioned in the summary. If this is a WONTFIX, and Bug 135331 is a WONTFIX, then what is the FIX?
the fix is to use the menu or click where no image is
> click where no image is You probably only visit well-made sites. Most sites that most people go to (which excludes nerds like us) use spacer.gif's, not because the author intentionally puts it, but because the spacers are automatically generated by ScreamWeaver. 90% of authors have no idea what is going on beneath the page they are making. What you mentioned is not a fix. It is the problem. I filed this because I want to draw attention to this problem.
mbt -- *are* back and forward going to be at the top of the shortcut menu for unlinked images? I agree, that would be a huge improvement. (Although I still think it's a terrible UI design mistake to make the page-navigation options vanish ever.)
What about an image that is mostly red, on top of a page that has a red background? From the user's point of view, there's no difference between "images that are transparent" and "images that are hard to tell apart from the background." The right fix is, still, to put the page-context items on all of the context menus.
Authors do that when transparency is impossible, such as jpg's. But users recognize them as part of an image because they are often within the rectangular boundaries of an image. Nobody uses jpegs of the same color to fill up huge amounts of space for formatting. And I don't really care what the fix is as long as the problem is fixed. This is a usability problem that is sure to confuse many users.
Regardless of what the pedants here think about the metaphysics of contexts or how many angels fit on the head of pin, having the "back" entry on the link and image context popup menus made my life considerably easier. After clicking on a link, going "back" is the commonest operation in a browser. Before I could consistently do this by clicking on the right menu button and moving the mouse a millimeter down. Now I click on the right menu button and 90% of the time carry out the old behaviour. The other 10% of the time I have to pop the menu down again and carefully find a bit of the page where there is no link or image. This is a real pain with big images or a lot of links. Or I have to move the mouse all the way to the arrow button in the toolbar. More hand-eye coordination on my part. In my inexpert opinion, the current behaviour is a real usability bug and I would be thankful if someone could mail me a recipe to get back the old behaviour by editing the configuration files.
The loss of back/forward when context switching is the single most aggravating UI 'feature' I've experienced in over two years of Mozilla use. Comment #11 : http://www.mozillazine.org/talkback/read.php?f=3&i=1236&t=1236 (not confirmed)
You need to log in before you can comment on or make changes to this bug.