607230 - Remove "Page Info" from the Tools menu

Status: NEW

(Firefox :: Menus, defect)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

This bug is to remove the "Page Info" command from the Tools menu.  This command will still be available on the context menu of the page itself.

The rationale is that this menu command received an extremely low level of usage according to our usability metrics coming in through test pilot, especially when considered relative to some of the other items in the same menu, like access to the add-ons manager.

Comment 1

[Jesse Ruderman]

Wouldn't it make more sense to remove it from the context menu and leave it in the Tools menu?  I'd think keeping the context menu clean is more important than keeping the Tools menu clean.

Comment 2

[tymerkaev]

(In reply to comment #0)
Probably might be better to move it from 'Tools' into 'View' (under Page Source). Also, this menuitem doesn't have an accesskey, and removing it from menubar will make "Page Info" fully unaccessible.

Comment 3

[u88484]

I can take this if the decision has been finalized to remove or move this.

Comment 4

[Adam Kowalczyk]

I sometimes find Page Info in the Tools menu useful for saving images from websites that disable the context menu. In general, if we make some things available only through the context menu, we should do better job at preventing websites from disabling it.

Comment 5

[Ian Pottinger]

note that Page Info is also easily accessed via the "More Information" button in the Site Identity drop-down (Larry)

Comment 6

[Pleyone]

Attachment: patch

Comment 7

[Alex Faaborg [:faaborg] (Firefox UX)]

The UX team is very eager to get this bug landed over the next few days in order to make Beta 11.  If anyone can get a patch for this bug posted soon, we will push hard for reviews and approval (even though this isn't blocking).

You can view all of the related bugs to clean up the traditional menu bar here: http://areweprettyyet.com/4/traditionalMenu/

Comment 8

[:Margaret Leibovic]

Comment on attachment 505835 [details] [diff] [review]
patch

>--- browser-menubar.inc	2011-01-21 18:03:27.179011052 +0100
>+++ b/browser-menubar.inc	2011-01-21 18:06:53.087011051 +0100

>-                        accesskey="&pageInfoCmd.accesskey;"
>-                        label="&pageInfoCmd.label;"
>-#ifndef XP_WIN
>-                        key="key_viewInfo"
>-#endif

You should probably remove these strings from browser.dtd and the key from browser-sets.inc, since they are not used elsewhere. Other than that, I think this patch would work.

Comment 9

[Brian Carpenter [:geeknik]]

Just an FYI, I submitted a patch to #611568 that removed this. I guess I'll have to re-do my patch if this one lands?

Comment 10

[Brian Carpenter [:geeknik]]

Attachment: Removes Page Info from browser menu

Comment 11

[Brian Carpenter [:geeknik]]

Attachment: Removes Page Info from browser menu

Removes Page Info from browser menu (browser-menubar.inc) and from browser-sets.inc and browser.dtd.

Comment 12

[jag (Peter Annema)]

Wow, harsh.

I'm with Jesse and Azat on this. Move Page Info under Page Source in the View menu, and drop View Page Info and View Page Source from the context menu.

Or if your mind's made up on removing this item from the menu, can we keep the shortcut hooked up?

Comment 13

[Robert Kaiser]

Also note that context menu is less accessible and discoverable than "normal" menus, AFAIK.

Comment 14

[Justin Dolske [:Dolske]]

Comment on attachment 506657 [details] [diff] [review]
Removes Page Info from browser menu

>--- a/browser/base/content/browser-menubar.inc	Mon Jan 24 19:47:52 2011 -0800
...
>-              <menuitem id="menu_pageInfo"

So, question for UX: Instead of flat-out removing Page Info, how about creating a Tools --> Web Developer submenu (as the FF App Button now has)? We would move a few other menu items under there (from their current locations) -- web console, error console, view source. I guess Char Encoding and Work Offline, for consistency, but maybe the cost of moving those from their current (expected) location isn't worth it?

>--- a/browser/base/content/browser-sets.inc	Mon Jan 24 19:47:52 2011 -0800
...
>-    <command id="View:PageInfo" oncommand="BrowserPageInfo();"/>

There are still a couple things referring to "View:PageInfo". Notably the <key> for non-Windows platforms which provides a keyboard shortcut to open Page Info (ie, Cmd-I on OS X). I see some kits for "View:PageInfo" in the addons MXR, so some addons might have issues if the command is removed too.

Unless UX really wants to kill this dead dead dead, we should keep the <key> and thus <command>. 


>--- a/browser/locales/en-US/chrome/browser/browser.dtd	Mon Jan 24 19:47:52 2011 -0800
...
>-<!ENTITY pageInfoCmd.commandkey "i">

Can't remove this since the <key> still uses the entity (and would thus break the browser ;).

Comment 15

[Alex Limi (:limi) — Firefox UX Team]

(In reply to comment #14)
> Comment on attachment 506657 [details] [diff] [review]
> So, question for UX: Instead of flat-out removing Page Info, how about creating
> a Tools --> Web Developer submenu (as the FF App Button now has)? We would move
> a few other menu items under there (from their current locations) -- web
> console, error console, view source. I guess Char Encoding and Work Offline,
> for consistency, but maybe the cost of moving those from their current
> (expected) location isn't worth it?

I'd support making a submenu for these things, and making it consistent between the new and old-style menu. This assumes that it has no string impact, and is simple and non-risky work. I'll let you make the call there.

We could potentially move Char Encoding there too — moving Work Offline there depends on whether we get bug 620472 in, IMO, as we put them erroneously in that state way too often, so it can't be in a submenu.

The downside of putting Character Encoding there is that it creates a submenu in a submenu, which is bad. So overall, I'd leave those two alone for now, at least until we have more clarity what happens to Work Offline, and know whether we get the top-level special handling of Character Encoding for the locales where it's used more often (Japan?)

> Unless UX really wants to kill this dead dead dead, we should keep the <key>
> and thus <command>. 

I think this is a good thing to keep, yes.

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

We can't really move view > page source though.  I'm generally in favor of keeping the classic menu bar classic, and not messing with built up muscle memory.

Comment 17

[Frank Yan (:fryn)]

Have we made a clear decision on this?

Comment 18

[Steffen Wilberg]

The tools Menu got a Web Developer submenu in the meantime.
We could move Page Info down there.

Comment 19

[Dão Gottwald [:dao]]

Permissions and Security aren't web developer tools...

Comment 20

[Brian Carpenter [:geeknik]]

Someone is else is going to have to take over this bug, I'm not going to have time in the foreseeable future to work on it. :(

Comment 21

[Jennifer Morrow [:Boriss] (UX)]

Now that we have a web developer menu, why not move "Page Info" there?  We already have "Page Source" on that menu, and I can't imagine why "Page Info" is given higher priority in the hierarchy given its extremely low usage.  I'm happy to ui-review a patch if anyone has time to write one

Comment 22

[Frank Yan (:fryn)]

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #21)

See comments 18 and 19.

Comment 23

[u428464]

Is there any plans about a "page info" redesign ? I think it's one of the many things that should be in-content or partially in-content as the new devtools.

Comment 24

[Sebastian Zartner [:sebo]]

May this be something for Photon?

Sebastian

Comment 25

[:Gijs (he/him)]

(In reply to Sebastian Zartner [:sebo] from comment #24)
> May this be something for Photon?
> 
> Sebastian

No. We have too much stuff on our plate for Photon already (ie no time to do this before Photon ships), there is no clear consensus in this bug, and no obvious relevance to what we're doing in Photon (which is not messing with the old-style toplevel menus in any way).