Build: M12 release / win98 If a table has a background image in a cell, and one right clicks on that image and attempts "view image", a new browser is created with the location 'http://imagename.gif/', and nothing is displayed. It does not appear to actually try to DNS-resolve imagename.gif. Of course, it should really be showing the image and its proper URL. Attached is a short html file and image which display the problem. Any gif should work with the html, just rename it to gears-top.gif.

Not sure who gets this; QA assigning to self to check it out.

This is probably Networking, moving to Gagan; holding onto bug just in case it needs further action. twm@andrew.cmu.edu, thanks for the great test case, and watch out for the black powder in cyert hall. ;)

Sounds like a MakeAbsolute problem.

I think it's an *absent MakeAbsolute* problem. It seems only the name of the gif is given to open location without resolving the current path first. It works fine when being a simple image in a table (with src=, not background=).

QA Assigning to tever.

So who owns the functionality of "view image"?

I think it might be pnunn?

Leger: nope. Once we have a filename that we know is image data, the imglib takes over. This bug is occuring before that happens. -P

Interesting. I can't use view image on any image. I get a new browser window, but it is empty. ----------------------------- Here a snippet of our dos debug output for an image (coffee.gif) in a table: Loading page specified via openDialog Check if a view source window got a request Error loading URL http://jazz/users/pnunn/publish/coffee.gif Document: Done (0.14 secs) WEBSHELL- = 8 WEBSHELL- = 7 X Pos: 82 Y Pos: 73 WEBSHELL+ = 8 nsXULKeyListenerImpl::Init() WARNING: unable to load datasource 'rdf:xpinstall-update-notifier', file e:\grap tor\mozilla\mozilla\rdf\content\src\nsXULDocument.cpp, line 5157 ----------------------------------------------- Here's a snippet of what I get when I click on the background image (hat.gif) in the table: Y Pos: 73 WEBSHELL+ = 8 nsXULKeyListenerImpl::Init() WARNING: unable to load datasource 'rdf:xpinstall-update-notifier', file e:\grap tor\mozilla\mozilla\rdf\content\src\nsXULDocument.cpp, line 5157 WEBSHELL+ = 9 WEBSHELL+ = 10 X Pos: 249 Y Pos: 31 WEBSHELL+ = 11 nsXULKeyListenerImpl::Init() WARNING: unable to load datasource 'rdf:xpinstall-update-notifier', file e:\grap tor\mozilla\mozilla\rdf\content\src\nsXULDocument.cpp, line 5157 WEBSHELL+ = 12 WEBSHELL+ = 13 X Pos: 34 Y Pos: 35 WEBSHELL+ = 14 nsXULKeyListenerImpl::Init() --------------------------------------------- Maybe this is context menu problem? passing bug to saari. -p

This is not a context menu problem. I just tried view image on the banner of mozilla.org and it worked fine using WinNT. Peter, I don't know who this should be assigned to, help!

Per pdt mtg, not clear how critical to M13. Moving to M14.

Sounds like a layout bug to me. Whoever handles the background= part of the tag must be using the wrong thing for the base URL, and accidently constructing http://image.gif. Necko just interprets image.gif as the host name as it should.

reassigning to pnunn

saari: If you're talking about mozilla-banner.gif at the top of mozilla.org, this does work fine (it's just a regular image). This bug concerns only background images in tables. html excerpt: <TR><TD BGCOLOR="#000000" VALIGN=TOP><IMG SRC="images/mozilla-banner.gif" ...

twm@andrew.cmu.edu: In testing this bug from a build of 01-16-2000, I saw a slightly different problem. The right click on _any_ image brought up a new blank window. When I updated my tree to 01-19-2000 and rebuilt, a right click on a regular image worked as expected. A right click on an image in a table cell (not a background image) worked fine. A right click on a table cell background image did not give an option for a view-image. In Communicator 4.x, a right click on a table cell background image does not give an view-source option. I think if you update to a current build, you will find the context menu view image functionality working again for html tag images, page background images, images in table cells. But if you have a strong feeling that images used in table cell backgrounds should have a view-menu item in its context menu, it should be submitted as an enhancement. I'm marking the bug as invalid, so it falls through the right QA process. While the view-image context menu functionality WAS broken and is now fixed, the major point of this bug was view-image context menu functionality for table cell background images.... Opening a new bug as an enhancement request (you can specify enhancement in the comment text as well as the severity field.) would put the request in the right track. You could assign it to law@netscape.com to start. -pn

pnunn, I still get the context menu with the buggy behavior in Win98 with 2000012008 (which is a day after yours, right?). Regular images work fine.

Thanks for your tenacity. I finally can see what you are describing. Instead of using your test page, I modified one of mine to duplicate the problem. Rather than making the image a background in a cell, I made it a background in the table: I tested with <table background="hat.gif"> <tr><td>........ rather than: <table > <tr><td background="hat.gif">....... ok. I see it. Let me find out who deals with the tables/context-menus/url resolution. Sorry about the mix up. Reopening bug. -P

Bill: I'm reassigning this to you since you know about context menus. If you aren't the right guy, pass it on to right person. I have demo html on http://jazz/users/pnunn/publish/aaaa2.html right click on the hat. -P

Clearing INVALID resolution due to reopen.

Please explain why this is critical to M13, or move to M14. Thanks!

law hasn't had a chance to look at yet. moving to m14 for more investigation. this looks fixed to me. http://jazz/users/pnunn/publish/coffee.gif shows fine in the latest m13 builds. law thinks other recent fixes for url evaluation may have resolved this problem in the last week or so.

It's not fixed. The problem is that it is hard for the context menu code to discern the *absolute* url given an html element. All we can get is the actual background= attribute value string (which is a relative url). This is code in nsContextMenu.js that came to me from somebody on the Web. It seemed like a neat feature up till now. I'll have to go back and see if we can work around this. Similar code operates on CSS style attributes; I'm not sure if those are broken the same way (depends on whether the css attributes are relative or absolute urls). To be continued...

There should be a base URL around somewhere in this context which can be used to generate a correct absolute URL.

*** Bug 25816 has been marked as a duplicate of this bug. ***

Moving to M15.

Move to M16 for now ...

Move to M21 target milestone.

*** Bug 40874 has been marked as a duplicate of this bug. ***

Nom. nsbeta3, recc. nsbeta3 with - on some date. This is correctness of context menu UI command behavior. We'd really like the context menu commands to work correctly for FCS! However, as a last resort, if we fail for background images in tables only, that could be relnoted and fixed at the first point release.

I wrote code that resolves relative urls by examining document <base> tag content. I'll check that in when this bug's time comes.

law: Can you add your new code to this bug as a patch so all interested people can take a look in advance?

Please note that the patch was against -r 1.20 (the file is currently at rev 1.23).

Integrated the patch into my current version of nsContextMenu.js. Seems to work fine for now, the problem this bug describes is gone with the patch. I will use the patched version to test it some more.

Nav triage team: [nsbeta3-]

I'm still running with that patch, works fine, although I'm not sure all is as it should since it went from some cvs merges that had to be resolved manually in the meantime.

Adding patch keyword; Andreas Otte - do you have a current patch to fix this problem? Gerv

I have added the current diff to nsContextMenu.js that includes the patch. It still works fine, but please do a sanity check on this. In the last months it went through several merges that had to be resolved manually. I can only hope, that I damaged nothing else in the process.

This is [nsbeta3-]. Somebody might want to remove that so it gets re-evaluated. Make sure to emphasize that the patch is available!

Requesting nsbeta3 re-evaluation based on the fact that there's a patch available, and it's simple. Gerv

nav triage team: nsbeta3+, P4 so you can check in the patch

Bumping to P2; patch has been provided.

PDT would like to know how come this patch hasn't been checked in? Is there a problem with the patch?

any update?

I haven't gotten to the task of applying this fix to my working copy of nsContextsMenu.js, getting required reviews, etc. This one seemed like it needed less attention than some of my other bugs...

I've updated the patch yet again, this time to deal with revised lines in patched file, and more importantly, the recent change from progid to contractId. Looking for review/approval...

Let's try to fix this for RTM.

Changed to real "rtm need info" bug.

Fix in hand.

OK, I've received r=radha, sr=brendan. Removing "need info" residue. Don says he'll mark [rtm+].

PDT, please approve.

PDT marking [rtm-] since View Image on table cell backgrounds doesn't seem like a common operation and there are two screenfuls of diffs.

It is not only about table cell backgrounds, the patch also covers the same bug for INPUT TYPE=IMAGE images. I have applied the patch and can confirm that it fixes the INPUT TYPE=IMAGE problem too. I'll make an attachment that illustrates the bug.

If you want PDT to come back and have another looking, taking into account the increased seriousness of this bug, you need to remove [rtm-] :-) Done. Gerv

PDT, re-posting as "rtm+" after new feedback from Andreas J. Koenig about the added seriousness of the bug. Your call ...

This bug also applies to <object type="image/*"> elements, as well.

I checked the fix into the trunk.

rtm-, against normal src=image.gif this seems to work fine. The broken example uses src=showattachment.cgi?attach_id=3272. It's unlikely that many images are generated by a CGI and that in addition one would view image them.

<sigh> This _is_ a reasonably serious bug, and it's not going to go away unless we apply this patch. Removing [rtm-] (again) for reconsideration in the light of increased seriousness (see new testcase)... Gerv

Gang, the PDT is just not gonna take this for N6 RTM at this point. Sorry. Minus again.

It seems unclear to me whether this bug requires either of a "developer" or "user" release note. If anyone feels it does, can they please draft one and then nominate with the relnote-user or relnote-rtm strings in the Status Whiteboard. Thanks :-) Gerv

Upon managerial request, adding the "testcase" keyword to 84 open layout bugs that do not have the "testcase" keyword and yet have an attachement with the word "test" in the description field. Apologies for any mistakes.

Fixed on trunk, so resolving.

*** Bug 32755 has been marked as a duplicate of this bug. ***

Should I be able to click on the first attachment (test html file) and see a table w/ the gif? that is not working for me in M0.9, IE5.5 or Comm4.

benc, no; you need to have a file called "gears-top.gif" relative to the html file. Download the second attachment into the same directory and call it that, and you should be able to see it.

Okay. Generally when I post HTML as a file (not to be viewed from bugzilla), I post it as text/plain...)

qa to layout.

Marking verified in the Sept 06 build (2001-09-06-05).