Per bug 515368 comment 13: Right clicking on an image should still display "Properties", and this item should point to the existing "Media" tab in Page Info, with the image item preselected, so that you immediately get the metadata you want. This way, you don't need to duplicate the code/UI; all you need is Properties pointing to the right place. I doubt it would take 48 Kb of code to implement, and it would make everybody happy.

I have a patch in the works, so I will assign it to me.

Won't block on this, cc'ing Johnath and Alex for some UI opinion. My feeling is that it's reasonable to have this sort of linkage for items for which we show specific properties within the Page Info window, and potentially helpful.

(In reply to comment #3) > My feeling is that it's reasonable to have this sort of linkage > for items for which we show specific properties within the Page > Info window, and potentially helpful. By "items", you mean not only images, but also links, blockquote/q/ins/del etc. ? Now, bug 1995 is totally regressed on Firefox. If we are to fix bug 1995 along with that strategy, we need another 2 panels. 1: Links tab 2: Cites/Dates tab |cite| attribute is almost identical to |href|, as long as we neglect XHTML2.0-like fundamentalism. So that we might need just one tab as a UI. Anyway, is it possible to implement Links panel again?

It would be nice if we exposed the color profile of the image (if any) in the properties, since we now render based off of those. Not sure if that is in scope for reimplementing image properties.

(In reply to comment #5) > It would be nice if we exposed the color profile of the image (if any) in the > properties, since we now render based off of those. Not sure if that is in > scope for reimplementing image properties. This should be done in a separate bug. The goal of this bug is to reimplement the item in the context menu of images.

Here is a screenshot of the new context menu item.

Comment on attachment 402433 [details] [diff] [review] Context menu option for image properties ui-r+ with the nit that this should appear as the very last item in the context menu, after block image.

(In reply to comment #5) I think you're looking for bug 232806 and bug 106068 (EXIF and IPTC, respectively).

Comment on attachment 402433 [details] [diff] [review] Context menu option for image properties > // mmm, yummy. global variables. > var gWindow = null; > var gDocument = null; >+var imgUrl = null; Well, I don't care for global variables, but lets at least follow the naming conventions and name it gImageURL. >@@ -521,37 +530,30 @@ function processFrames() > var doc = gFrameList[0]; > onProcessFrame.forEach(function(func) { func(doc); }); > var iterator = doc.createTreeWalker(doc, NodeFilter.SHOW_ELEMENT, grabAll, true); > gFrameList.shift(); > setTimeout(doGrab, 16, iterator); > } > else > onFinished.forEach(function(func) { func(); }); >+ onFinished.push(selectImgUrl); This line is indented as if you intend for it to be a part of the else clause, but without braces it is actually happening unconditionally. >+function selectImgUrl () >+{ >+ if (imgUrl) { >+ var tree = document.getElementById("imagetree"); >+ for (c = 0; c <= tree.view.rowCount; c++) >+ { >+ if (imgUrl == gImageView.data[c][COL_IMAGE_ADDRESS]) { >+ tree.view.selection.select(c); >+ return; >+ } >+ } >+ } >+} As written 'c' is a global variable. Lexically scope it with a 'var': for (var c = 0; c < tree.view.rowCount; c++) Also, note that using <= in the test will produce an off-by-one error resulting in a js exception when you read past the end of the array.

Here is the new patch. I have fixed the Mochitests, moved the item to the bottom of the image context menu--from ui-review, and fixed the three items from the review.

Comment on attachment 405688 [details] [diff] [review] Patch v 1.1 > // doc - document to use for source, or null for this window's document > // initialTab - name of the initial tab to display, or null for the first tab >-function BrowserPageInfo(doc, initialTab) >-{ >- var args = {doc: doc, initialTab: initialTab}; >+function BrowserPageInfo(doc, initialTab, gImageUrl) >+{ >+ var args = {doc: doc, initialTab: initialTab, gImageUrl: gImageUrl}; This gImageUrl is a local variable, so don't use the 'g' prefix. Don't use the 'g' prefix on the property name either. Also, add a comment describing the new argument while you're here. r=db48x with those minor changes.

I've made those review changes.

I want to add my 2cents as a user that has been made aware of this "removed properties menu" bug. It appears that this will only add the right click properties menu back when clicking on images and links. Do be aware that the proprieties menu can be also used to identify the language of a site, and that you get from not clicking on a link or image, but just on any random element on the web-page. This is vital information for many. Example: http://imgur.com/wInyw.png

(In reply to comment #14) > I want to add my 2cents as a user that has been made aware of this "removed > properties menu" bug. > > It appears that this will only add the right click properties menu back when > clicking on images and links. Do be aware that the proprieties menu can be also > used to identify the language of a site, and that you get from not clicking on > a link or image, but just on any random element on the web-page. > This is vital information for many. > Example: > http://imgur.com/wInyw.png This is only for images, not links. You should probably open up a new bug for other element properties.

Can we get a different reviewer than Vlad? I wager he's a little too busy at the moment ...

I won't have time to get to this for a while, and I doubt mconnor will either -- but from a quick glance, this is r-; adding a context menu item is a no-go. The main browser context menu is a cesspit, and adding more stuff to it is not going to work.

(In reply to comment #17) Except this isn't adding a new item, just replacing an old one (and in fewer circumstances). (On a side note, and IMHO, more needs to be done to discourage extension developers from adding needless context menu items in the AMO review process.)

(In reply to comment #18) > Except this isn't adding a new item, just replacing an old one (and in fewer > circumstances). Yeah, exactly. Comparing Fx 3.5 and this patch, there is no context menu change when viewing images. And beltzner agrees in comment 3 that this may be helpful.

For my part--and I am obviously biased--now that I have this feature, I use it all the time. In fact, I use it far more often than "Page Info" which brings up the same window. The time savings for users, particularly web developers, is substantial enough that it's definitely worth it. Also, from Alex's comments, I have moved it to the bottom of the image menu, so it shouldn't get in the way, and as Frédéric notes, it only applies to images so the majority of users wont see it in their day-to-day routine anyway. And, mconnor said he would get to it today.

This, of course, should have a test...

Yeah, definitely needs a test; Axel, would you be willing to allow this string into mozilla-1.9.2?

I am unwilling, in general. I'd be easier to push over if it'd be my own "get me back my properties" pet thing (that'd be links, "opens in new tab or not"). I'm sensitive to the outcry there, though, and I'd not be blocking, but it's not my personal experience that this would be blocking. Basically, I'm coming in here with stop energy, nothing more, nothing less. It's Thursday, it's not on trunk yet, etc... . I defer to beltzner to push me over my inner hill, or this bug off to 3.7. I'd personally say "nah, not really".

(In reply to comment #21) > This, of course, should have a test... And to clarify, the only test this has is to make sure that the right thing is shown in the menu. What it's missing is testing the that actually opens the window and contains the right information for the image that we right clicked on.

No test, no review, not on trunk yet, doesn't look like it'll make it for Firefox 3.6. :(

Comment on attachment 406368 [details] [diff] [review] Patch v 1.2 >+// imageUrl - url of an image to load in the Media Tab of the Page Info window this can be null/omitted, so please include that in the comment sr=me, discussed this with beltzner a little, we both think it's worthy, whether it makes 3.6 or not is hard to say, but we should get a quick test added and landed on trunk.

(In reply to comment #24) > And to clarify, the only test this has is to make sure that the right thing is > shown in the menu. What it's missing is testing the that actually opens the > window and contains the right information for the image that we right clicked > on. Where do we want the test, in the test_contextmenu.html file? And, how do I simulate a click on the context menu item in this case? (With every day, my memory gets worse and worse...)

Spoke with mconnor about landing this without a test for now, and he was ok with it as long as a test is quickly added soon (preferably later tonight). tmyoung is actively working on getting a test written, so he will hopefully have it soon. http://hg.mozilla.org/mozilla-central/rev/9617b5335022

Comment on attachment 406368 [details] [diff] [review] Patch v 1.2 We should take it for 3.6. Having a whole cycle without it is painful and there is no release *without* this feature yet, AFAIK, so this would be transparent to the average user.

Comment on attachment 406368 [details] [diff] [review] Patch v 1.2 OK, let's get this on to 1.9.2. I think I agree that it's a significant loss for a subset of users, and a limitation of the media panel that there's no easy way to get info for a specific image. Tanner: please get that test done ASAP.

It needs check-in for 1.9.2.

This is the general test I have been trying to make. My test should load the image > click the context menu item > open the page info dialog > check if the preview image exists and has the correct source. I'm sure I've made a stupid mistake somewhere (or many stupid mistakes), so any help is welcome and desperately needed.

Some general comments: We generally place all the testing code in a function (runTest) and run it onload, so in the window element you want |onload="runTest"|. You need to QI the pageInfo window to nsIDOMWindow off the enumerator. There's a simpler way of doing this context menu test, see http://mxr.mozilla.org/mozilla-central/source/browser/base/content/test/browser_bug424101.js . Where were you planning on dropping in this test? Browser chrome tests are js files, which this one should be.

Maybe of some importance: in Page Info dialog, media item is indeed preselected (as expected), but media files list is *not* automatically *scrolled* to make this item *visible*. For example, try see properties of "QMO" image on http://www.mozilla.org/projects/minefield/ page.

(In reply to comment #35) > Maybe of some importance: in Page Info dialog, media item is indeed preselected > (as expected), but media files list is *not* automatically *scrolled* to make > this item *visible*. For example, try see properties of "QMO" image on > http://www.mozilla.org/projects/minefield/ page. Bug 524090 was just filed for that.

(In reply to comment #34) > We generally place all the testing code in a function (runTest) and run it > onload, so in the window element you want |onload="runTest"|. Done. > You need to QI the pageInfo window to nsIDOMWindow off the enumerator. I tried adding that, but it returned "[Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface]" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "JS frame :: chrome://mochikit/content/browser/browser/base/content/test/browser_bug517902.js :: anonymous :: line 32" data: no]"]" > There's a simpler way of doing this context menu test, see > http://mxr.mozilla.org/mozilla-central/source/browser/base/content/test/browser_bug424101.js Done. > Where were you planning on dropping in this test? Browser chrome tests are js > files, which this one should be. Now, I will do it as a js. file, where it belongs... The only thing that I still lack on this test is the ability to check if the preview image src is correct. I keep getting null values.

> The only thing that I still lack on this test is the ability to check if the > preview image src is correct. I keep getting null values. The reason for this is that the src is not populated until some time after the pageInfo window loads. Setting a setTimeout and other methods like that don't work nor does using waitForEvents(event) like in http://mxr.mozilla.org/mozilla-central/source/browser/base/content/test/test_contextmenu.html?force=1#369 since the events never seem to fire. The only time it has worked is when a js alert was fired and closed manually by me, and then the test finished, but that's useless for automated test. Advise please. With this fixed, the test is complete...

Could you try hooking into the onLoadRegistry which is called at the end of loadPageInfo().

This passes, but it can sometimes skip the last steps that check for the image (they are in the scope of the observer function) without returning any error. There aren't any js console errors, and it functions on the same logic as the browser_pageInfo.js test, so I'm not sure why these events are skipped in one and not the other.

1) I'd suggest placing the observer out of the test function. 2) Add the observer _before_ opening the page info dialog. 3) The test belongs in browser/base/content/test/

Here is the testcase ready to go. It uses a new observer notifier in pageInfo.js for when an image is selected. This wont clutter the "observer airways"; it enables the testcase to be more elegant; and add-ons or other features that relate to this new feature will be able to access this information, since adding a hook to onFinished wont guarantee that the correct image is selected because selectImgUrl could still be running when a test's, add-on's, or feature's hook is started.

Dao's patch for Bug 524106 fixes several idiosyncrasies with this patch. However, his patch uses the element instead of the src to load the image information, which I agree is a better way to do it, but it will break this test. Do we want this test and redo his patch or commit his patch and do a test for everything afterwards?

Fwiw, I don't think it's a good idea to add an observer for every image selection. But that's just me... Alternatively, you can just add your own "select" event listener in the test (if I'm reading it correctly)...

The observer should only fire when someone calls View Image Info with an imageUrl (imageElement in Bug 524106), and if it is not present no observer fires. Also if you change the image after it has selected the image the first time, the observer will not continue fire. The reason I added this is that even if I hooked into onFinished, it wouldn't know if the image has been selected or not. This not only applies to this test but to any addons or other features that might depend on this functionality.

Comment on attachment 408240 [details] [diff] [review] Testcase v 1.3 >diff --git a/browser/base/content/test/browser_bug517902.js b/browser/base/content/test/browser_bug517902.js >+netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect'); this isn't necessary for browser chrome tests, the code only runs in a chrome context.

Comment on attachment 408240 [details] [diff] [review] Testcase v 1.3 Since Bug 524106 was landed, I need to update the testcase.

Updated testcase after Bug 524106 was landed, and I removed the line Gavin noted was unnecessary.

I don't think we should add that observer topic, so here's a test without that. This covers bug 524106, too. What do you think, Tanner?

> I don't think we should add that observer topic, so here's a test without that. > This covers bug 524106, too. What do you think, Tanner? Perfect! It looks good to me. I'm happy to use it instead. The only thing is that we must land Bug 524106 on 1.9.2 at the same time, which I think we should anyway...

Anything you'd like to add to the test? Your version also tested the presence of the context menu item, but I think that's covered elsewhere.

No, there is nothing I need. The context menu test is part of the test submitted with the initial patch, so we don't need to add it again in the chrome test.

Comment on attachment 409534 [details] [diff] [review] alternative test a192=beltzner, though tests do not need review, really

Verified Fixed. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091104 Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20091104045446

Looks good on 1.9.2 too with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b2pre) Gecko/20091106 Namoroka/3.6b2pre ID:20091106033745