Closed Bug 513147 Opened 15 years ago Closed 15 years ago

Get rid of the "Properties" context menu item

Categories

(Firefox :: Menus, defect)

Product:
Firefox
Component:
Menus
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3.7a1
Tracking Flags:
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: johnath, Assigned: johnath)

References

(Depends on 1 open bug)

Details

(Keywords: dev-doc-complete, useless-UI, verified1.9.2, Whiteboard: [killthem] See comment #40 for an extension if you need this back, also comment 95)

Attachments

(2 files, 2 obsolete files)

Eef.
48.00 KB, patch
vlad
: review+
sicking
: superreview+
beltzner
: approval1.9.2+
Details | Diff | Splinter Review
Screenshot of dialog that was removed
27.12 KB, image/pjpeg
Details
Seriously, right click on a link - there's an actual "Properties" entry there. The dialog it launches is... not sufficiently useful.
cc'ng sicking as the original implementer (really?!) - is there a reason I'm not seeing for keeping this around?
cc'ng robcee too, on the off chance that firebug uses this?
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?
Assignee: nobody → johnath
Status: NEW → ASSIGNED
Attachment #397178 - Flags: review?(vladimir)
Adding relnote keyword because I think a small number of addons may exist which augment this (e.g. EXIFData).
Keywords: relnote
Whiteboard: [killthem]
Comment on attachment 397178 [details] [diff] [review] I can't believe this is more than a thousand lines long KILL
Attachment #397178 - Flags: superreview+
Attachment #397178 - Flags: review?(vladimir)
Attachment #397178 - Flags: review+
Yeah, this will break FxIF. Bummer. (Not sufficient reason to keep it alive, FxIF could just add its own menu item.)
Attachment #397178 - Attachment is obsolete: true
Attachment #397198 - Flags: superreview?
Attachment #397198 - Flags: review?(vladimir)
Attachment #397198 - Flags: superreview? → superreview?(jonas)
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
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
(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.
Attached patch Eef. — — Splinter Review
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! :)
Attachment #397272 - Flags: superreview?(jonas)
Attachment #397272 - Flags: review?(vladimir)
Attachment #397198 - Attachment is obsolete: true
Attachment #397198 - Flags: superreview?(jonas)
Attachment #397198 - Flags: review?(vladimir)
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 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.
Attachment #397272 - Flags: superreview?(jonas) → superreview+
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.
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.
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.
(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.
(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! ;)
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?
(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.
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.
(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.
Tryserver ran without incident, I'll aim to land this tomorrow.
(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.
http://hg.mozilla.org/mozilla-central/rev/60ddd1db0397
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
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.
(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.
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.
Target Milestone: --- → Firefox 3.7a1
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.
Attachment #397272 - Flags: approval1.9.2?
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.
Keywords: useless-UI
Depends on: 514520
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.
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?
The removal of the properties window would have to be the stupidest things done in mozdev history.
(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.
Adding this just for reference on what was actually removed.
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.
Blocks: 515368
So now all the Property menu items are gone.. Not just for links. =(
No longer blocks: 515368
Depends on: 515368
I've reworked this patch as an extension: https://addons.mozilla.org/en-US/firefox/addon/14228/ Enjoy.
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.
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
Status: RESOLVED → VERIFIED
Version: unspecified → Trunk
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!!!!!
(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.
Damn >:( How to bring this dialog back in Firefox 3.6 release?
(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.
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. :(
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!
Seems like degradation is a new policy for Mozilla :(
(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.
...and if someone nominates it for public, I'll be happy to do the review on AMO.
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.
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!
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?
(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.
(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.
(In reply to comment #56)\ > Note that I suggested a compromise in bug 515368 comment 13 I support...
Comment on attachment 397272 [details] [diff] [review] Eef. a192=beltzner
Attachment #397272 - Flags: approval1.9.2? → approval1.9.2+
Whiteboard: [killthem] → [killthem][strings]
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.
Whiteboard: [killthem][strings] → [killthem]
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.
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
Keywords: verified1.9.2
"Excellent". Now Extended Link Properties extension ceases to work.
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.
Whiteboard: [killthem] → [killthem] See comment #40 for an extension if you need this back
Blocks: 517902
You may thank Hitler for this... ..oops I meant Johnathan Nightingale
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
Oh, drat. mconnor beat me to it. :-| Gerv
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?
Lucy, see bug 395668.
Depends on: 520300
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.
(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.
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
(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).
It is being added back and will be better. See bug 517902 and no further comments are needed in this bug or that bug.
I'm terribly sorry but bug 517902 "Reimplement image properties, using the existing "Media" panel" has nothing to do with link properties.
(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).
(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.
(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.
(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.
Is there a list somewhere of everything that was exposed via the Properties menu item (without having to look through the source)?
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
(In reply to comment #81) There are certain things (e.g. the lang attribute) that are only shown when present.
(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
we should really back this out, created Bug 523046, please vote
(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
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 .
URL: https://bugzilla.mozilla.org/page.cgi...
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!!!
No longer blocks: 517902
Depends on: 517902
No longer blocks: 522913
Depends on: 522913
"If man have headache, let's cut his head" - It's name of this damn fix. Properties, we will wait you back.
Added relnote, removing tag.
Keywords: relnote
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
Poster #91 is right. Think of the watches, people. Think of the watches.
(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
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
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.
Whiteboard: [killthem] See comment #40 for an extension if you need this back → [killthem] See comment #40 for an extension if you need this back, also comment 95
Element Properties 4 extension does *not* work in Firefox 3.6 beta 1/2/3. What a mess.
(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.
(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.
(In reply to comment #99) It's called "View Image Info" and it appears below the "Block Images from example.com" item.
(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...
(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 ....
... ok, probably not stick with 3.5. Will review 517902 ...
(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
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.
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/
PS: direct link image: http://darkwolf.altervista.org/mgallery/?sa=media;id=4767 As you can see, more useful info with only one click.
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.
This extensions restore the original “properties” for all elements : http://extensions.geckozone.org/ExtendedLinkProperties (Extended Link Properties 2.0.1 beta)
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.
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?
(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
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
(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.
(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).
(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 ...
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?
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.
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...
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: