Last Comment Bug 513147 - Get rid of the "Properties" context menu item
: Get rid of the "Properties" context menu item
Status: VERIFIED FIXED
[killthem] See comment #40 for an ext...
: dev-doc-complete, useless-UI, verified1.9.2
Product: Firefox
Classification: Client Software
Component: Menus (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: Firefox 3.7a1
Assigned To: Johnathan Nightingale [:johnath]
:
: Jared Wein [:jaws] (please needinfo? me)
Mentors:
: 252685 (view as bug list)
Depends on: 520300 514520 515108 515368 517902 522913
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-27 17:29 PDT by Johnathan Nightingale [:johnath]
Modified: 2010-05-12 04:11 PDT (History)
52 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
beta1-fixed


Attachments
I can't believe this is more than a thousand lines long (34.28 KB, patch)
2009-08-27 17:44 PDT, Johnathan Nightingale [:johnath]
vladimir: review+
vladimir: superreview+
Details | Diff | Splinter Review
Missed the jar manifest for the dtd/properties (35.96 KB, patch)
2009-08-27 18:49 PDT, Johnathan Nightingale [:johnath]
no flags Details | Diff | Splinter Review
Eef. (48.00 KB, patch)
2009-08-28 08:10 PDT, Johnathan Nightingale [:johnath]
vladimir: review+
jonas: superreview+
mbeltzner: approval1.9.2+
Details | Diff | Splinter Review
Screenshot of dialog that was removed (27.12 KB, image/pjpeg)
2009-09-08 06:30 PDT, u88484
no flags Details

Description Johnathan Nightingale [:johnath] 2009-08-27 17:29:04 PDT
Seriously, right click on a link - there's an actual "Properties" entry there. The dialog it launches is... not sufficiently useful.
Comment 1 Johnathan Nightingale [:johnath] 2009-08-27 17:33:52 PDT
cc'ng sicking as the original implementer (really?!) - is there a reason I'm not seeing for keeping this around?
Comment 2 Johnathan Nightingale [:johnath] 2009-08-27 17:41:24 PDT
cc'ng robcee too, on the off chance that firebug uses this?
Comment 3 Johnathan Nightingale [:johnath] 2009-08-27 17:44:42 PDT
Created attachment 397178 [details] [diff] [review]
I can't believe this is more than a thousand lines long

Remove metadata.xul/js, its properties and dtd files, the hooks in nsContextMenu, and the appropriate strings from browser.dtd.

I think that's all of it?
Comment 4 Johnathan Nightingale [:johnath] 2009-08-27 17:48:02 PDT
Adding relnote keyword because I think a small number of addons may exist which augment this (e.g. EXIFData).
Comment 5 Vladimir Vukicevic [:vlad] [:vladv] 2009-08-27 18:27:58 PDT
Comment on attachment 397178 [details] [diff] [review]
I can't believe this is more than a thousand lines long

KILL
Comment 6 Ted Mielczarek [:ted.mielczarek] 2009-08-27 18:36:26 PDT
Yeah, this will break FxIF. Bummer. (Not sufficient reason to keep it alive, FxIF could just add its own menu item.)
Comment 7 Johnathan Nightingale [:johnath] 2009-08-27 18:49:33 PDT
Created attachment 397198 [details] [diff] [review]
Missed the jar manifest for the dtd/properties
Comment 8 Gervase Markham [:gerv] 2009-08-28 00:50:38 PDT
Does this remove the Properties menu item in every case? What are the cases? (Links, images, ...?)

Is it worth checking with the accessibility people in case that's the original use case?

Gerv
Comment 9 tabmix.onemen 2009-08-28 03:36:59 PDT
you missed some more.....
in browser-context.inc
>       <menuitem id="context-metadata"
>                 label="&metadataCmd.label;"
>                 accesskey="&metadataCmd.accesskey;"
>                 oncommand="gContextMenu.showMetadata();"/>

and in nsContextMenu.js
>  initMetadataItems: function() {
>    // Show if user clicked on something which has metadata.
>    this.showItem("context-metadata", this.onMetaDataItem);
>  },

and the call to initMetadataItems in initItems
Comment 10 Johnathan Nightingale [:johnath] 2009-08-28 07:27:50 PDT
(In reply to comment #9)
> you missed some more.....
> in browser-context.inc
> >       <menuitem id="context-metadata"
> >                 label="&metadataCmd.label;"
> >                 accesskey="&metadataCmd.accesskey;"
> >                 oncommand="gContextMenu.showMetadata();"/>
> 
> and in nsContextMenu.js
> >  initMetadataItems: function() {
> >    // Show if user clicked on something which has metadata.
> >    this.showItem("context-metadata", this.onMetaDataItem);
> >  },
> 
> and the call to initMetadataItems in initItems

Yeah - mentioned this to Vlad - new patch coming up soon.
Comment 11 Johnathan Nightingale [:johnath] 2009-08-28 08:10:08 PDT
Created attachment 397272 [details] [diff] [review]
Eef.

Fixed browser-context, did a bunch more removal in nsContextMenu and changed the behaviour of the separators so that we wouldn't get duplicate or trailing separators. Removed mentions in the context menu mochitest. Removed styling rule on gnomestripe. Literally went through every case-insensitive occurrence of "metadata" in browser/

I've tested this visually on various element types and it looks fine. I've run the unit tests locally and have a try server build churning as well.

We're up to 50k in removals now!  :)
Comment 12 David Bolter [:davidb] 2009-08-28 09:26:48 PDT
I think we are okay for a11y. Jamie, Marco, do you guys know of cases where removing the contextual properties dialogs will cause accessibility pain?
Comment 13 Jonas Sicking (:sicking) No longer reading bugmail consistently 2009-08-28 17:47:28 PDT
Comment on attachment 397272 [details] [diff] [review]
Eef.

Aww, this was basically my first patch. My fifteen pixels of fame. I'm not crying, it's just some dirt in my eye.

Jokes aside, I agree that this is largely useless. Not sure if there occasionally might be useful information in there.

Anyhow, whatever the front-end people think is the right thing to do.
Comment 14 James Teh [:Jamie] 2009-08-28 22:10:28 PDT
I frequently use this to copy just part of the URL for a link. I could use "Copy Link Location" and then edit the link when I paste it, but there are times when that is irritating. Also, if you want to paste it more than once, you'd have to use "Copy Link Location", paste into an editor, edit it, then copy back to the clipboard. Note that this isn't a11y related, just a personal preference.
Comment 15 Ria Klaassen (not reading all bugmail) 2009-08-29 02:13:43 PDT
I wonder if this won't cause problems for people who have their statusbar unchecked. Although you can also use an extension (I guess it exists) or bookmarklet to show the URL of the link in a tooltip.
Comment 16 u88484 2009-08-29 05:41:01 PDT
What is the bug number for the bug that implemented this?  I'm curious as to the reason this was added in the first place?  Sorry Jonas, but I think it is almost completely from what I can tell.  Open this over the gmail logo in gmail, "Miscellaneous Properties...Title: Gmail by Google"

@ comment 14, you can paste the link more than once after copying with 'copy link location'.

@ comment 15, I don't think you can but if you can add icons to tooltips an extension could easily implement tooltips showing an icon for a window or tab that shows what the link will open into and also can add the URL to the tooltip.
Comment 17 James Teh [:Jamie] 2009-08-29 15:13:40 PDT
(In reply to comment #16)
> @ comment 14, you can paste the link more than once after copying with 'copy
> link location'.
To clarify, I meant pasting only a portion of the link. This is currently possible by only copying a portion of the link from the properties dialog. It's useful when working with relative URLs.
Comment 18 Marco Zehe (:MarcoZ) 2009-08-30 22:25:26 PDT
(In reply to comment #16)
> @ comment 15, I don't think you can but if you can add icons to tooltips an
> extension could easily implement tooltips showing an icon for a window or tab
> that shows what the link will open into and also can add the URL to the
> tooltip.

Unfortunately, tooltips are probably the most inaccessible way of communicating information to visually impaired people.

Removing this dialog would take away a source of information for non-mouse users regarding where the link opens and what the possible attributes are.

I STRONGLY suggest setting this bug to "WONTFIX" and instead file a follow-up bug to give this some a11y love (XUL markup errors with non-associated labels).

Jonas, I vote for your very first patch to stay in! ;)
Comment 19 David Bolter [:davidb] 2009-08-31 06:47:05 PDT
It sounds to me like the information in the properties page is useful to at least some keyboard power users. But we have to weigh that against the goals of making our code and UI simpler. That said, whatever info we provide visually (like the link icons idea), we need to also expose in other ways.

Marco, Jamie, we could provide the link information via a11y API. Thoughts?
Comment 20 Johnathan Nightingale [:johnath] 2009-08-31 10:23:39 PDT
(In reply to comment #18)
> Unfortunately, tooltips are probably the most inaccessible way of communicating
> information to visually impaired people.
> 
> Removing this dialog would take away a source of information for non-mouse
> users regarding where the link opens and what the possible attributes are.

This UI is really not very useful in most scenarios, and in any event I think doesn't require 50k of code and the associated maintenance burden. I also think it is *very* rarely used by the majority of our userbase. BUT I really don't want to remove a genuinely useful a11y tool without an alternative.

(In reply to comment #19)
> It sounds to me like the information in the properties page is useful to at
> least some keyboard power users. But we have to weigh that against the goals of
> making our code and UI simpler. That said, whatever info we provide visually
> (like the link icons idea), we need to also expose in other ways.
> 
> Marco, Jamie, we could provide the link information via a11y API. Thoughts?

I think David's exactly right here - we should look for another way to supply this information if we believe it has value for some users. The fact that two or three pieces of info (link target, opening behaviour, maybe img alt text? others?) in these dialogs are useful is not a reason to keep them intact, imo - it's not free to do so. If there are APIs we can hook into to supply the appropriate details directly, that would be my strong preference.

And sorry Jonas - I don't relish killing anyone's first patch. :) FWIW, I think, when it landed and browser-integrated web developer tools were in their infancy, this kind of dialog could have been the beginning of something useful. But since tools have evolved in a different direction, I think this is now legacy code that wants removal.

Put another way, and I think this is central to the whole bug and the arguments for/against: if this hadn't landed back in 2000, and someone attached a patch to do this right now, we'd almost certainly WONTFIX it, and redirect it to an add-on.
Comment 21 Marco Zehe (:MarcoZ) 2009-08-31 10:33:10 PDT
Hi Jonathan,

my primary intention was to raise the flag that replacing this with a tooltip-only solution would not be terribly accessible. I'm all for a good alternative, for example I was thinking of folding this into the pageInfo dialog: Add a tab witha  list of all the links on the page, and when a link is selected, associated read-only textboxes are filled with the appropriate info (target, title, image?).

While exposing this through a11y APIs, which is mostly done already, as David suggested, is useful for the screen reader itself to give users info about a link, it does not cover the scenario Jamie was pointing out, which is being able to copy parts of a link address. Also, the a11y APIs don't yet have a means to expose whether a link opens in something other than the current page (although I believe this could be useful info for screen readers).

So, I'm all for better UI solutions, we just need to make sure they're not tooltips only. ;) That was the primary intent of my comment.
Comment 22 David Bolter [:davidb] 2009-08-31 10:39:54 PDT
(In reply to comment #21)
> While exposing this through a11y APIs, which is mostly done already, as David
> suggested, is useful for the screen reader itself to give users info about a
> link, it does not cover the scenario Jamie was pointing out, which is being
> able to copy parts of a link address. Also, the a11y APIs don't yet have a
> means to expose whether a link opens in something other than the current page
> (although I believe this could be useful info for screen readers).

Spun off bug 513715 for this.

I think Jamie should file a bug for the easier link copying.

> So, I'm all for better UI solutions, we just need to make sure they're not
> tooltips only. ;) That was the primary intent of my comment.

Good point.

Sounds like this can land IMHO.
Comment 23 Johnathan Nightingale [:johnath] 2009-08-31 14:47:00 PDT
Tryserver ran without incident, I'll aim to land this tomorrow.
Comment 24 Rob Campbell [:rc] (:robcee) 2009-08-31 14:51:58 PDT
(In reply to comment #2)
> cc'ng robcee too, on the off chance that firebug uses this?

don't think so. we have our own "Inspect Element" menu item.
Comment 25 Johnathan Nightingale [:johnath] 2009-09-01 06:24:17 PDT
http://hg.mozilla.org/mozilla-central/rev/60ddd1db0397
Comment 27 Masahiro YAMADA 2009-09-01 14:13:50 PDT
Is URL displaying on status-bar trustful ?
I don't think so.
Now, we have no way to show correct URL of link href without add-on.
# status bar's implementation of decoding percent encoded URL is not same as  location bar's implementation. and the difference can be to used to spoof status bar.
Comment 28 Johnathan Nightingale [:johnath] 2009-09-01 14:22:15 PDT
(In reply to comment #27)
> Is URL displaying on status-bar trustful ?
> I don't think so.
> Now, we have no way to show correct URL of link href without add-on.
> # status bar's implementation of decoding percent encoded URL is not same as 
> location bar's implementation. and the difference can be to used to spoof
> status bar.

If you have a feature request here, I'd encourage you to file a new bug, detailing how you'd expect it to work. But for what it's worth, I don't believe that the dialog as-removed was at all an effective defense against link-destination spoofing. Not only was it not designed for, nor popularly used for, that purpose, but it would also fail against anyone actually trying to deceive you. There are myriad other ways to redirect a link click, which the properties dialog would not reveal.

It is good to know that you found the dialog useful in some way, and I would welcome your attempts to design a feature that reduces the impact of href spoofing, but I would hope you'd agree that the use case you describe does not, on its own, justify a feature of this size or prominence, appearing for nearly every right click in content.
Comment 29 Henrik Skupin (:whimboo) 2009-09-01 14:33:01 PDT
Johnathan, will this patch be checked into 1.9.2? If it not intended the dev docs should be updated because it mentions the ui change for 3.6 now.
Comment 30 Johnathan Nightingale [:johnath] 2009-09-01 14:42:01 PDT
Comment on attachment 397272 [details] [diff] [review]
Eef.

(In reply to comment #29)
> Johnathan, will this patch be checked into 1.9.2? If it not intended the dev
> docs should be updated because it mentions the ui change for 3.6 now.

That's a call for drivers to make. I certainly don't think a code-cleanliness removal should block, but I will request approval for 1.9.2, since I believe it's safe, and removes code that we would later have to maintain.
Comment 31 Biju 2009-09-02 18:20:37 PDT
It is sad to see this feature going away. It helped me to see the properties of an image, able copy alt text. 
On about:config I have disabled mailto url. So this was the only way I could get "subject" and "body" of mailto link.
IE still has this feature.
Comment 32 Benoit 2009-09-04 05:43:35 PDT
I understand that the content of this window could be better left as an extension and is not very interesting at the moment. 

What worries me is the removal of the context menu item itself, and of the info window as an overlay point for extensions. That means that every extension wanting to add extra information about an element (like FxIF) will have to add its own context menu to the list. Image properties, Link properties, Language properties, and so on.

The former design had at least the advantage of being cleanly extensible with a single entry point in the context menu for all "properties" that one could think of.
Comment 33 Jesse Ruderman 2009-09-04 18:17:27 PDT
*** Bug 252685 has been marked as a duplicate of this bug. ***
Comment 34 Henrik Skupin (:whimboo) 2009-09-08 04:35:09 PDT
I have no idea how many extensions could be broken by this change when we wanna target it for Firefox 3.6. Chris, can we identify those extensions on AMO?
Comment 35 Danial Horton 2009-09-08 05:40:10 PDT
The removal of the properties window would have to be the stupidest things done in mozdev history.
Comment 36 u88484 2009-09-08 05:50:36 PDT
(In reply to comment #35)
> The removal of the properties window would have to be the stupidest things done
> in mozdev history.
I beg to differ but only because you probably don't understand what this bug is about.  This removed a small window that popped up when right-clicking on links and selecting 'Properties'.  This window only showed a few things like the url and alt text.  This isn't the page properties windows with lots and lots of info.
Comment 37 u88484 2009-09-08 06:30:46 PDT
Created attachment 399193 [details]
Screenshot of dialog that was removed

Adding this just for reference on what was actually removed.
Comment 38 Danial Horton 2009-09-08 06:32:34 PDT
i know exactly what it was, and i know exactly why it was useful.

mozdev is getting as bad as IEteam when it comes to removing the minor stuff and replacing it with bloaty stuff.
Comment 39 ABC 2009-09-09 08:23:36 PDT
So now all the Property menu items are gone.. Not just for links. =(
Comment 40 Geoff Lankow (:darktrojan) 2009-09-10 05:11:19 PDT
I've reworked this patch as an extension:
https://addons.mozilla.org/en-US/firefox/addon/14228/

Enjoy.
Comment 41 Johnathan Nightingale [:johnath] 2009-09-10 05:40:41 PDT
Hey Geoff - thanks for doing that. My assertion was never that this functionality was useless, just that it wasn't useful enough, to a large enough portion of the user base, to merit continued inclusion in the core product. But I think it makes a great deal of sense as an extension, and I appreciate you making the effort.
Comment 42 Henrik Skupin (:whimboo) 2009-09-10 05:49:28 PDT
Verified fixed on trunk with builds on all platforms like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20090908 Minefield/3.7a1pre ID:20090908030622
Comment 43 Please Ignore This Troll (Account Disabled) 2009-09-10 09:43:40 PDT
I vote against fixing this "bug". It's a useful information for me. Sometimes I want to check fast what is the size (height, width) of a picture and it's weight (kbytes).
For those, who hate this so much - you can write a CSS userstyle to hide it. Don't cut the functionality!!!!!
Comment 44 u88484 2009-09-10 09:46:10 PDT
(In reply to comment #43)
> I vote against fixing this "bug". It's a useful information for me. Sometimes I
> want to check fast what is the size (height, width) of a picture and it's
> weight (kbytes).
> For those, who hate this so much - you can write a CSS userstyle to hide it.
> Don't cut the functionality!!!!!
Please read bugs before commenting in them.  This bug has already been fixed.  This dialog will not be in Firefox 3.6 release.  An extension has been created as linked to in comment #40.
Comment 45 Please Ignore This Troll (Account Disabled) 2009-09-10 09:49:37 PDT
Damn >:(
How to bring this dialog back in Firefox 3.6 release?
Comment 46 u88484 2009-09-10 09:55:42 PDT
(In reply to comment #45)
> Damn >:(
> How to bring this dialog back in Firefox 3.6 release?
Well actually the patch has been only been checked in for 3.7, it might make it for 3.6.

Install the extension to get the dialog back.
Comment 47 Please Ignore This Troll (Account Disabled) 2009-09-10 10:00:48 PDT
Oh sorry, seems like I got the conversation wrong, I thought that patch or add-on will cut this dialog and that it was built-in in Firefox 3.6
just miss-read. :(
Comment 48 Frédéric Buclin 2009-09-11 03:52:19 PDT
we use the "Properties" menu a lot in Bugzilla to easily copy the name + email address of patch authors (which is in the title attribute of anchors) to paste in CVS commit messages. Now there is no way to copy the content of tooltips anymore. You can see the tooltip, read it, but cannot copy it when it's useful to you. That's a real regression for some Bugzilla users (especially for people like me who commit patches of contributors with no CVS account). Sadness!
Comment 49 Please Ignore This Troll (Account Disabled) 2009-09-11 07:38:47 PDT
Seems like degradation is a new policy for Mozilla :(
Comment 50 Shawn Wilsher :sdwilsh 2009-09-11 10:01:38 PDT
(In reply to comment #48)
> we use the "Properties" menu a lot in Bugzilla to easily copy the name + email
> address of patch authors (which is in the title attribute of anchors) to paste
> in CVS commit messages. Now there is no way to copy the content of tooltips
> anymore. You can see the tooltip, read it, but cannot copy it when it's useful
> to you. That's a real regression for some Bugzilla users (especially for people
> like me who commit patches of contributors with no CVS account). Sadness!
Your use case doesn't apply to the vast majority of our users.  Comment 40 has an add-on that restores this for people who need it.
Comment 51 Shawn Wilsher :sdwilsh 2009-09-11 10:07:07 PDT
...and if someone nominates it for public, I'll be happy to do the review on AMO.
Comment 52 Seungbeom Kim 2009-09-12 02:32:18 PDT
Gee, I can never understand why a few people are so eager to remove a feature that we already have and that is working well, just because some people claim it's not very useful, even though some other people have been maintaining that it is sometimes useful, and though some others have been warning of potential breaks of some extensions. And to force those people who need it to install an extension that "undoes" this "bug fix". As the famous saying goes, "why fix it if it ain't broke," despite the concerns?

I'm not saying this because I'm a great fan of this feature, but I'm talking about the process here. I don't claim that mozdev has to be a great model for democracy, but this feels much more like a secret military operation to me -- doesn't it? Especially considering how long it took to finish it from the initial report -- just a few days! Isn't it amazing? It feels as if this feature were a major security problem! Was this so urgent? It's the more amazing considering that some requests for other useful (but not too difficult to implement) changes stay unfulfilled for years.

I sincerely appreciate the efforts of the developers to make Mozilla better, but I cannot help feeling that their efforts would have been better spent on adding other useful features than on removing one some still find useful despite a controversy.
Comment 53 Ted Mielczarek [:ted.mielczarek] 2009-09-12 07:34:03 PDT
A secret military operation right out here in the open, yes. It got fixed quickly because Johnathan both filed it and fixed it. That happens a lot. If more people fixed the bugs they filed, they'd get fixed a lot faster!
Comment 54 Michael Ryan 2009-09-12 09:32:15 PDT
The doc says that "Right-clicking on links no longer offers a "Properties" menu item", yet this patch removes the item for all elements. Is the doc wrong, or is the patch wrong?
Comment 55 Biju 2009-09-12 13:53:27 PDT
(In reply to comment #48)
Frédéric,

If Bug 48570 (Allow votes against a particular bugzilla bug) was fixed I would have got a chance to vote against this bug.
Comment 56 Frédéric Buclin 2009-09-13 04:46:58 PDT
(In reply to comment #55)
> If Bug 48570 was fixed I would have got a chance to vote against this bug.

Haha, but this won't happen before Bugzilla 3.6. And bmo is still running 3.2. ;)

Note that I suggested a compromise in bug 515368 comment 13 to make as much people as possible happy (both devs and users). I'm still waiting for some feedback.
Comment 57 Biju 2009-09-13 18:48:02 PDT
(In reply to comment #56)\
> Note that I suggested a compromise in bug 515368 comment 13 
I support...
Comment 58 Mike Beltzner [:beltzner, not reading bugmail] 2009-09-14 19:50:18 PDT
Comment on attachment 397272 [details] [diff] [review]
Eef.

a192=beltzner
Comment 59 Axel Hecht [:Pike] 2009-09-15 03:27:49 PDT
Even though string removal isn't that critical to string freeze, I'd like to see this landed on 1.9.2 rather sooner than later.
Comment 61 Gordon P. Hemsley [:GPHemsley] 2009-09-15 08:43:26 PDT
There was little discussion about removing this feature, and not much reason was given except that some people don't find it useful.

Now there is no way to find out what language a particular selection of text is. Not to mention all the other details that used to be present in the Properties dialog. I agree with the sentiments expressed in comment 18, comment 32, comment 35 (sort of), comment 39, comment 48, comment 52 (minus the militant accusation), and comment 55 (if I had known about the bug beforehand).

Bug 356038 had intended to supplement the language information available in the Properties window. Now, I'm not sure what good it would do—because, again, there is no longer any place where that information is available.
Comment 62 Henrik Skupin (:whimboo) 2009-09-16 03:15:07 PDT
Verified on 1.9.2 with builds on all platforms like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a2pre) Gecko/20090915 Namoroka/3.6a2pre ID:20090915041724
Comment 63 Artem S. Tashkinov 2009-09-18 02:49:19 PDT
"Excellent".

Now Extended Link Properties extension ceases to work.
Comment 64 Brett 2009-09-21 07:48:33 PDT
I use to use this feature often to check the link to an image.
Now I have to select copy image, and paste it to an editable text box to see the link.

This bug fix is counter productive in so many cases. Just because 1 users pushes their idea shouldn't cause things to be committed to a product with million of existing users.
Comment 65 Please Ignore This Troll (Account Disabled) 2009-09-21 12:19:44 PDT
You may thank Hitler for this...
..oops I meant Johnathan Nightingale
Comment 66 Gervase Markham [:gerv] 2009-09-21 14:02:11 PDT
iDrugoy: about five seconds after this mail is sent, I will be disabling your Bugzilla account. Go and read about Godwin's Law. There is no reason why jonath should have to put up with that sort of thing.

Gerv
Comment 67 Gervase Markham [:gerv] 2009-09-21 14:03:06 PDT
Oh, drat. mconnor beat me to it. :-|

Gerv
Comment 68 Majken Connor [:Kensie] 2009-09-27 21:44:21 PDT
I used this menu mostly for reading tooltips before the long tooltip bug was fixed, though occasionally I use it to read tooltips that take longer to read than the time out will leave it up for.

Is there a pref/existing bug for tweaking the tooltip timeout?
Comment 69 Jesse Ruderman 2009-09-28 02:27:38 PDT
Lucy, see bug 395668.
Comment 70 Fabian Norman 2009-10-16 01:12:56 PDT
Sometimes the democratic system works.
Sometimes a group with a very closed perspective hijack it.

Congrats on making FF a laughing stock of a browser.
Comment 71 Fabian Norman 2009-10-16 01:15:29 PDT
(In reply to comment #70)
> Sometimes the democratic system works.
> Sometimes a group with a very closed perspective hijack it.
> 
> Congrats on making FF a laughing stock of a browser.

Oh, and now how can we fix this bug, because this is a major issue. I have no properties context menu, and an add-on is NOT an acceptable solution for whats a basic standard elsewhere.
Comment 72 Gervase Markham [:gerv] 2009-10-16 02:21:40 PDT
Fabian: Mozilla is not a democracy. Open source does not mean "the developers must do my bidding". And being able to comment in Bugzilla is a privilege, not a right. 

If you want this decision reversed, the only way to do it is for you to provide information about important use cases which have not already been considered in this bug.

Gerv
Comment 73 Artem S. Tashkinov 2009-10-16 03:06:26 PDT
(In reply to comment #72)
> 
> If you want this decision reversed, the only way to do it is for you to provide
> information about important use cases which have not already been considered in
> this bug.
> 
> Gerv

I used to use the link properties option with conjunction with the Extended Link Properties extension which gives a lot of information about the remote server.

Now I cannot use this extension and I have no desire to use anything like Live HTTP headers, when in the past I could just right mouse click the link and get the information which I need(ed).
Comment 74 u88484 2009-10-16 04:53:21 PDT
It is being added back and will be better.  See bug 517902 and no further comments are needed in this bug or that bug.
Comment 75 Artem S. Tashkinov 2009-10-16 05:59:54 PDT
I'm terribly sorry but bug 517902 "Reimplement image properties, using the existing "Media" panel" has nothing to do with link properties.
Comment 76 u88484 2009-10-16 06:06:29 PDT
(In reply to comment #75)
> I'm terribly sorry but bug 517902 "Reimplement image properties, using the
> existing "Media" panel" has nothing to do with link properties.
Ummm yes it does, it has everything to do with it.  You must have commented in this bug without reading the entire bug and/or using a build with the patch for this bug in it.

The patch in this bug removed the properties contenxt menu item that was present in the right-click context menu when a user right-clicked on a link...which an image link happens to basically be in a non-technical sense.

bug 517902 is going to add this context menu item back to where it was.  Now the change that is happening, is that instead of a complete window for the minute information that was displayed is now going to be display in the "regular" properties menu window in the media tab.  (Right-click on a blank spot in a webpage, select 'Properties' -> 'Media' tab).
Comment 77 u88484 2009-10-16 06:11:13 PDT
(In reply to comment #75)
> I'm terribly sorry but bug 517902 "Reimplement image properties, using the
> existing "Media" panel" has nothing to do with link properties.

And file a new bug with specific reasons that you think should be changed.
Comment 78 Fabian Norman 2009-10-16 11:38:05 PDT
(In reply to comment #72)
> Fabian: Mozilla is not a democracy. Open source does not mean "the developers
> must do my bidding". And being able to comment in Bugzilla is a privilege, not
> a right. 
> 
> If you want this decision reversed, the only way to do it is for you to provide
> information about important use cases which have not already been considered in
> this bug.
> 
> Gerv

I would just like to clear up this miss-understanding.
I never said that anyone must do my bidding. And I do understand that anyone that is here is here because they are allowed to, and not that they have "the right".
But, and correct me if I'm wrong, Bugzilla works with an element of voting on the issue by it's members, correct? Is that not a democratic element to software development?

So then the issue here is that a group of people with a closed and single perspective all voted for this without taking consideration outside of their views. Yes, this was voted on. But you can't tell me that the people that voted on this is comparable to the entire userbase.

And that there is a new bug to add this back in simply shows the lack of thought put into this. That this new bug movies the dialog window to a new area is great. That is what this bug should have been in the first place. But instead you remove it and then you add it back in... Which is just not very competent. But I am glad that at least this system seems to be able to fix itself.


And I only commented in the first place because I was linked to this and in my opinion, no one will no about your opinion unless you let them know.
My opinion is that it's stupid to remove something that millions of users use, myself included, and that an add-on is not an acceptable solution to the greater problem.

I mean, look at the reasoning:
"Jokes aside, I agree that this is largely useless. Not sure if there
occasionally might be useful information in there."

Not sure if it's useful? Maybe I'm wrong here, but wouldn't it be smart to find out if it's useful first? That person is obviously "unsure" about it. If I was unsure about something I would investigate and make myself "sure" about it first.

And if you want a use, heres one.
Say you got to a site in a foreign language, but you are unable to identify the language. The solution to that is to go to the properties window, which will then tell you the language.

There's lots of uses that are related to grabbing detailed information on the page or an item on the page. The properties context menu isn't something that's used often, yes, I agree. But when it's needed, it's use is essential.

And seeing how there is a very large group of Firefox's user base that has no concept or idea of add-ons, having the fix for the removal of the properties as an add-on is not a good idea.

Anyway, I'm done here. It looks like this bug is being reversed, and that was my main concern, for this bug to be reversed.
Comment 79 Reed Loden [:reed] (use needinfo?) 2009-10-16 11:50:04 PDT
(In reply to comment #78)
> But, and correct me if I'm wrong, Bugzilla works with an element of voting on
> the issue by it's members, correct? Is that not a democratic element to
> software development?

Nope, there's no "voting" involved at all. Mozilla is a meritocracy, and as such, the module owner/peers have final say over decisions concerning the codebase. In this particular case, Johnathan proposed that this be done and provided a patch. Vlad, a Firefox module peer, reviewed this change giving it his approval in the process, which allowed it to land. Approval was requested for landing on the 1.9.2 branch and was then granted by Beltzner, a Firefox driver.

If you're referring to the "voting" feature supported in Bugzilla, votes for bugs are almost always ignored and mean pretty much nothing.

> Anyway, I'm done here. It looks like this bug is being reversed, and that was
> my main concern, for this bug to be reversed.

This bug is not being reversed. The "Properties" content menu item is gone for all the various forms. Bug 517902 may eventually lead to it being readded for only images, but that's not set in stone at all.
Comment 80 WulfTheSaxon [:Wulf] 2009-10-16 14:00:10 PDT
Is there a list somewhere of everything that was exposed via the Properties menu item (without having to look through the source)?
Comment 81 Artem S. Tashkinov 2009-10-16 22:00:28 PDT
As for clean Firefox 3.5.3 it shows:

Window Title:
Element Properties

Text:
Link Properties
Address: Link URL
Will open in: Same window/Same frame/"Another frame name"/New Tab/New Window
Comment 82 WulfTheSaxon [:Wulf] 2009-10-17 03:26:23 PDT
(In reply to comment #81)

There are certain things (e.g. the lang attribute) that are only shown when present.
Comment 83 Geoff Lankow (:darktrojan) 2009-10-17 14:48:31 PDT
(In reply to comment #80)
> Is there a list somewhere of everything that was exposed via the Properties
> menu item (without having to look through the source)?

https://bugzilla.mozilla.org/attachment.cgi?id=397272&action=diff#a/browser/locales/en-US/chrome/browser/metaData.dtd_sec1
Comment 84 Shy Shalom 2009-10-17 14:53:20 PDT
This page is now featured in reddit:
http://www.reddit.com/r/geek/comments/9ufq4/who_decided_that_firefoxs_context_menu_item/
Comment 85 Biju 2009-10-18 21:08:40 PDT
we should really back this out, created Bug 523046, please vote
Comment 86 Biju 2009-10-18 21:21:55 PDT
(In reply to comment #85)
> we should really back this out, created Bug 523046, please vote

Oh there was duplicate bug 515368 ...
Please CC and vote on that
Comment 87 Nochum Sossonko [:Natch] 2009-10-18 22:29:25 PDT
Guys, can't you all get a fuckin' grip. I've been watching this program develop for some three cycles already, contributing what I can to be a part of this effort of moving the internet along in a reasonable and friendly fashion. The developer that contributed this patch here, I've known to be very forthcoming in the furtherance of open source and helped me personally contribute to this program. It's ludicrous and an outcry to barage him, or for that matter, any of the developers in this project.

This has been sanctioned by the original contributor (see comment 13) that implemented this functionality, and frankly, I haven't seen any of the 50+ people I've introduced Firefox to ever use this context menu item. You don't want to see this evolve as an extension? I've yet to see a serious developer use Firefox without extensions. The common case most certainly agrees with the developers and drivers that have sanctioned this change, it's obvious to anyone with a shred of intelligence (has your Grandma ever been interested in the kb size of an image? For that matter, does she even understand its significance?).

So, without further due, stop lamenting this change, move on, or create your own forum where you can bitch about each and every change made in this *technical* bug system. I'm sure some constructive commenting, or open-eye bug filing wouldn't fail to catch the attention of the devs and drivers involved, but this incoherent bitching is just a joke and a sign of ineptitude.

Seriously, y'all sound like a horde of groupies...

Removing CC, bug is fixed and some people here can't read: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html .
Comment 88 Chris Proels 2009-10-22 07:16:58 PDT
Removing "Properties" menu can not be the right solution to fix a bug. I miss this feature. I suggest to enhance it like opera's 'show meta detail data on pictures include base64 encoded once' instead of removing it!!!
Comment 89 Kirill 2009-10-26 06:07:34 PDT
"If man have headache, let's cut his head" - It's name of this damn fix.

Properties, we will wait you back.
Comment 90 Mike Beltzner [:beltzner, not reading bugmail] 2009-10-30 13:21:21 PDT
Added relnote, removing tag.
Comment 91 Vincent Tsang 2009-11-07 02:03:43 PST
PLEASE KEEP IT.   I WORK WITH LOTS OF IMAGES ON MY SITES.   
I USE IT VERY VERY OFTEN TO CHECK THE PROPERTIES OF THE IMAGES.
IT IS ONE OF THE MAIN REASONS I USE FF INSTEAD OF IE OR CHROME.
IT IS THE MAIN REASON THAT I DON'T USE FF 3.6 BETA SINCE I INSTALLED IT.

WHILE YOU AT IT.  PLEASE MAKE IT TO REMEMBER THE SIZE OF THE WINDOW SO THAT
USERS DON'T HAVE TO RESIZE IT EVERY TIME.

http://watchreview.com/index.html
http://218.103.16.209/home.html
Comment 92 Mark Macdonald 2009-11-07 07:35:17 PST
Poster #91 is right. Think of the watches, people. Think of the watches.
Comment 93 Artem S. Tashkinov 2009-11-07 10:45:18 PST
(In reply to comment #40)
> I've reworked this patch as an extension:
> https://addons.mozilla.org/en-US/firefox/addon/14228/
> 
> Enjoy.

It does not work for me. Nothing happens when I right mouse click a link. I don't have any errors in Tools -> Error Console.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b1) Gecko/20091029 Firefox/3.6b1
Comment 94 Vincent Tsang 2009-11-08 09:02:29 PST
THANK YOU VERY VERY MUCH!

I'VE GOT MY "Element Properties" BACK WITH FF3.6B1 !!!!!!!!
THANK TO THIS EXTENSION :
https://addons.mozilla.org/en-US/firefox/addon/14228/

HOW CAN YOU DO IT SO FAST ?

3 HOURS 10 MINUTES AND 1 SECOND AFTER I HAVE MY WISH POSTED AND YOU HAVE DONE IT!

AMAZINGLY FAST!

AGAIN THANK YOU
Comment 95 Frédéric Buclin 2009-11-08 11:01:59 PST
Please stop shouting stupidly! If you read some more comments, you would know that image properties are again available in the context menu in 3.6 beta 2, thanks to bug 517902.
Comment 96 Artem S. Tashkinov 2009-11-18 02:58:25 PST
Element Properties 4 extension does *not* work in Firefox 3.6 beta 1/2/3.

What a mess.
Comment 97 u88484 2009-11-18 04:02:09 PST
(In reply to comment #96)
> Element Properties 4 extension does *not* work in Firefox 3.6 beta 1/2/3.
> What a mess.

Contact the author through addons.mozilla.org then.  This isn't the place for addon feedback.
Comment 99 leave 2009-11-21 06:02:20 PST
(In reply to comment #95)
> Please stop shouting stupidly! If you read some more comments, you would know
> that image properties are again available in the context menu in 3.6 beta 2,
> thanks to bug 517902.

I have not found that the "image properties" was available in the context menu of 3.6 beta 3.
Could anyone tell me the truth ?
I don't like the removal of element properties.
Comment 100 Tanner M. Young [:tmyoung] 2009-11-21 14:46:39 PST
(In reply to comment #99)
It's called "View Image Info" and it appears below the "Block Images from example.com" item.
Comment 101 leave 2009-11-22 00:21:43 PST
(In reply to comment #100)
> (In reply to comment #99)
> It's called "View Image Info" and it appears below the "Block Images from
> example.com" item.

I know that.
But it is too slow when there's many imgages in a page.

Did "comment #95" say that the "View Image Info" was also removed in 3.6 beta1 ? I cannot remember and I think its a terrible thing...
Comment 102 serfty 2009-12-14 15:28:10 PST
(In reply to comment #101)
> (In reply to comment #100)
> > (In reply to comment #99)
> > It's called "View Image Info" and it appears below the "Block Images from
> > example.com" item.
> I know that.
> But it is too slow when there's many imgages in a page.

Fully agree - I moderate a forum and often need to check the size of an image.  Viewing the Properties of a single image is simple with a left and right click.

Going to view image info is rime consuming.

I guess I'll stick with 3.5 ....
Comment 103 serfty 2009-12-14 15:39:27 PST
... ok, probably not stick with 3.5.  Will review 517902 ...
Comment 104 gfclement 2010-01-24 12:38:44 PST
(In reply to comment #40)
> I've reworked this patch as an extension:
> https://addons.mozilla.org/en-US/firefox/addon/14228/
> 
> Enjoy.
Like many have said in other versions of this bug, as a user I was surprised by this removal of "properties."  I've read through the discussions here, not necessarily agreeing with the philosophy of the removal.  Sounds like mozdev could use an influx of assembly programmers.  I recall the "eject a page" command years ago written in C, 18K of code.  When written in assembler it was 13 bytes.

But your addon restores it and it works for me.  I used this feature to copy and paste transaction data from the dialog into other programs saving me much retyping.

Thanks.

Jerry Clement
gfcdomain-linux@yahoo.com
Comment 105 Morning 2010-01-29 05:02:19 PST
I am VERY depressed and upset that that amazing feature was removed. It was the #1 thing I loved about FireFox vs. IE and Chromium.
Comment 106 DarkWolf 2010-01-30 16:09:48 PST
I think this is a great feature and not a bug :|
Anyway, thanks to author extension :)
-
Article+Screenshot: http://darkwolf.altervista.org/news-board/firefox-3-6-dove-finita-lopzione-proprieta-del-menu-contestuale/
Comment 107 DarkWolf 2010-01-30 16:17:48 PST
PS: direct link image: http://darkwolf.altervista.org/mgallery/?sa=media;id=4767
As you can see, more useful info with only one click.
Comment 108 Paul Sladen 2010-02-07 06:00:30 PST
Right-Click->Properties used show the Language of the text selection highlighted.  Where can this language setting information now be found?

A lot of effort goes into multilingual website (such as Wikipedia) to ensure that nested sets of lang="" attributes are set correctly, and (hopefully) parsed correctly.  This becomes much harder to validate when the final result is no longer presented to the end-user in an easy fashion.
Comment 109 Zéfling 2010-02-07 06:27:10 PST
This extensions restore the original “properties” for all elements : 
http://extensions.geckozone.org/ExtendedLinkProperties (Extended Link Properties 2.0.1 beta)
Comment 110 shimi 2010-03-18 22:51:48 PDT
I just found out that my most used FF feature is gone. Are you guys serious? Me (and everyone else I know) - use this VERY USEFUL MENU ITEM many times a day!

I don't take the "there is an extension to restore it". Why remove it? What does it disturb anyone that it is there?

Maybe remove "Back", "Forward", "Reload", "Stop" and "Home" buttons as well, and make an extension to add them?

Seriously guys. UNDO THIS!

The funny thing is in the bug status: "FIXED" - where Firefox is now *BROKEN* for me. It really hinders my work as a web programmer.
Comment 111 markpet 2010-03-28 09:26:39 PDT
This is an incredibly *not* thought through decision. 

Images frequently act as hyperlinks. In the past you could right-click on the image properties to get the image source as well as the hyperlink. Now all you can do to get to the image location is.... nothing.

So this fixes that "some scenarios didn't make sense"? Where is the fix for "at least 4 scenarios that did make sense and now don't?
Comment 112 Shawn Wilsher :sdwilsh 2010-03-28 09:43:38 PDT
(In reply to comment #111)
> So this fixes that "some scenarios didn't make sense"? Where is the fix for "at
> least 4 scenarios that did make sense and now don't?
https://addons.mozilla.org/en-US/firefox/addon/14228
Comment 113 UnknownVT 2010-04-07 20:50:55 PDT
Right-click > Properties is one of my MOST USED features.

Really was there a real advantage for removing it in 3.6?

Personally I think it is a very serious MISTAKE.

Please put it back!

Thank you
Comment 114 serfty 2010-04-07 21:02:27 PDT
(In reply to comment #103)
> ... ok, probably not stick with 3.5.  Will review 517902 ...

After closely reviewing this for months, I have stuck to FF 3.5.

The feature that was removed for later versions is great and I use it daily.

Today I disabled the check for update feature so I don't get continually nagged.
Comment 115 WulfTheSaxon [:Wulf] 2010-04-07 21:47:42 PDT
(In reply to comment #114)
> Today I disabled the check for update feature so I don't get continually
> nagged.

As has been mentioned multiple times before, the feature has been made into an extension, available at https://addons.mozilla.org/en-US/firefox/addon/14228/

AFAIK, Firefox 3.5.x support will end in June (6 months after 3.6 was released).
Comment 116 serfty 2010-04-07 21:52:18 PDT
(In reply to comment #115)
> (In reply to comment #114)
> > Today I disabled the check for update feature so I don't get continually
> > nagged.
> 
> As has been mentioned multiple times before, the feature has been made into an
> extension, available at https://addons.mozilla.org/en-US/firefox/addon/14228/
>

YES, I CHECKED IT OUT AND IT IS NOT AS DIRECTLY USEFUL FOR ME AS THE FEATURE THAT WAS REMOVED


> 
> AFAIK, Firefox 3.5.x support will end in June (6 months after 3.6 was
> released).
>

I'LL DEAL WITH ANY ISSUES IF THEY ARISE; FOR THE TIME BEING *NOT* UPGRADING IS THE MORE EFFICIENT OPTION FOR ME ...
Comment 117 Q.M. 2010-04-10 14:45:25 PDT
I used this feature every day on qwantz.com

Not being able to read the entire comments field on a mail:to link is incredibly irritating.

Offloading functionality into extensions is not in accordance with the rest of firefox's development; otherwise, why isn't the "awesomebar" just an officially sponsored extension, rather than integrated with the rest of the browser?
Comment 118 a.b. 2010-05-11 12:21:55 PDT
In reply to comment #110 and in reply to comment #117, obviously not every feature can be built into Firefox. Instead, balance / judgment is required to identify the most-used features and include those. I think we can all agree that the "awesomebar", "Back", and "Forward" buttons are likely used by more users than this feature.

Thanks as always to the devs for their work.
Comment 119 shimi 2010-05-11 23:18:46 PDT
In reply to comment #118

That's correct; Not every feature can be built into Firefox. However, I have a proof that this feature can be. After all, it has been in FF since ever...

MSIE and Opera had, and still have, that option.

So let's talk statistics. I am basing myself on http://marketshare.hitslink.com/report.aspx?qprid=0 .

MSIE, FF and Opera today count together for 86.84% of the browsers market.

Before this change, 86.84% of the browsers in the world, supported this.
After this change, 62.25% of the browsers in the world, supports this.

One of the most annoying things in the world, when you try to make some MSIE user to convert to FF, is the need to confirm to him that TRIVIAL FEATURES that HE NOW HAS (of course he does, they're trivial!), would need him TO INSTALL AN EXTENSION on every computer he chooses to use the new browser on...

So thanks, you did it again! 

I do thank the devs for their work; Unfortunately, this is an UNWORK. Yes, there isn't such a word in English, but I don't have any other way to express my feelings regarding this.

Oh and regarding awesomebar. Sorry dude, more people I know use the Properties button than the awesomebar. Some even find it annoying and don't know how to turn it off...

Note You need to log in before you can comment on or make changes to this bug.