After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 154887 - wrong context menu on some images
wrong context menu on some images
Status: RESOLVED FIXED
Product: epiphany
Classification: Core
Component: [obsolete] Backend:Mozilla
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Marco Pesenti Gritti
Depends on:
Blocks:
 
 
Reported: 2004-10-08 12:16 UTC by Christian Persch
Modified: 2005-09-26 19:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
First attempt to unify background image and image context popup (7.89 KB, patch)
2005-09-20 19:45 UTC, Jean-François Rameau
none Details | Review
Clean previous patch. (7.22 KB, patch)
2005-09-21 20:25 UTC, Jean-François Rameau
none Details | Review
Forgot -u when diffing :( (8.76 KB, patch)
2005-09-21 20:53 UTC, Jean-François Rameau
accepted-commit_now Details | Review

Description Christian Persch 2004-10-08 12:16:58 UTC
Steps to reproduce:
0) Go to http://www.mozilla.org/
1) Right-click on the slanted firefox screenshot

Expected results:
Context menu for images + link.

Actual result:
Context menu for link.
Comment 1 Crispin Flowerday (not receiving bugmail) 2004-10-08 17:30:51 UTC
This is because the image is actually a background image, rather than an img link.

(I looked at this in bug 151681 for galeon)
Comment 2 Lionel Dricot 2005-08-04 11:17:53 UTC
I cannot reproduce or I don't understand this bug.
Comment 3 Jean-François Rameau 2005-09-20 19:45:11 UTC
Created attachment 52441 [details] [review]
First attempt to unify background image and image context popup

I also modified the code in EventContext::GetEventContext so the first image is
the right one to avoid CSS computations when bubbling out.

According to discussion with chpe on irc, this is not always true:

(15:03:05) chpe: but it's not always true that the first image is the right one

(15:03:19) chpe: for example, amazon look-inside images 
(15:03:39) chpe: they're covered by a fake transparent 'image'
(15:04:14) chpe: which is 1x1 pixels... maybe 1x1 images should always be
disregarded
(15:04:47) jfrhome: hmm, trying too ...
(15:04:56) chpe: for example
http://www.amazon.com/gp/reader/0764596500/ref=sib_dp_pt/104-5758501-1417501#reader-link

(15:08:17) jfrhome: Right :(
(15:09:13) chpe: <div id="pageFront" style="position:relative;z-index:3;"><a
href="/gp/reader/0764596500/ref=sib_rdr_next2_toc1/104-5758501-1417501?%5Fencoding=UTF8&p=S00H&ns=1#reader-page"><img
src="http://g-images.amazon.com/images/G/01/x-locale/common/transparent-pixel.gif"
height="752" border="1" width="600" /></a></div><div id="pageBack"
style="position:relative; top: -753; z-index:1; height:752; width:600"
class="readerImage"><img src="http://lookinside2
(15:09:13) chpe:
-images.amazon.com/Qffs+v35leoYtqeuj4B9FJmDA9cJwZPLQE3I1SZhDtSr+0Z1S6SGPaCdpGTvdyiB"
height="752" border="0" width="600" name="si_pageUnder" /></div></div></td>
(15:09:31) chpe: different z-index values, clever
(15:11:07) chpe: so the click is on the transparent image, and you don't even
get the real image by going up in the dom :(
(15:11:19) chpe: oh well, at least let's get well-behaved pages right :)

I think there should be a fix to object tag for which the event context is not
set to EPHY_EMBED_CONTEXT_IMAGE (don't know why, but experimenting ...)
Comment 4 Jean-François Rameau 2005-09-21 20:25:26 UTC
Created attachment 52479 [details] [review]
Clean previous patch.

Didn't see the EPHY_EMBED_CONTEXT_IMAGE relative to Object tag (code is ok).
Some EPHY_EMBED_CONTEXT_IMAGE are moved to a place where we are sure the image
has been identified.
Comment 5 Jean-François Rameau 2005-09-21 20:53:54 UTC
Created attachment 52481 [details] [review]
Forgot -u when diffing :(
Comment 6 Jean-François Rameau 2005-09-26 19:28:08 UTC
Committed on CVS HEAD.