74729 - `Page Info' and `Properties' windows should be merged

Status: VERIFIED WORKSFORME

(SeaMonkey :: Page Info, defect)

Description

[Matthew T (active 1999-2002)]

Build: 2001033004, Mac OS 9.1

To reproduce:
*   Load a page in Navigator.
*   Choose `View' > `Page Info'.
*   Note the appearance of the window which opens, then close it.
*   Now open the context menu for the page, and select the last item.

What you should get:
*   An item reading `Page Info', which brings up the Page Info window.

what you actually get:
*   An item reading `Properties', which brings up a separate `Properties'
    window.

Props to whoever it was who implemented the `Properties' window for images, but 
it makes no sense to have two separate windows which are both for displaying 
general information and metadata about the current page.

So, this bug is asking for three things:
(1) making the `Properties' context menu item context-sensitive, to display
    `Page Info', `Frame Info', `Object Info', or `Image Info', depending on
    what is under the cursor;
(2) making the `Page Info' item open the Page Info window, rather than the
    `Properties' window;
(3) removing the code dealing with Page Properties from Mozilla.

Comment 1

[Blake Ross]

taking...

Comment 2

[Gervase Markham [:gerv]]

mpt: This bug is correct, but your proposed fix is wrong. This is because the 
properties window is designed to give you the properties of particular special 
elements (INS, DEL, IMG, BLOCKQUOTE, Q, and anything with a title or a lang 
attribute) whereas Page Info is about the entire page. There is no way that Page 
Info can display the sort of information that Properties can.

There is a bug, bug 74121, about cleaning up the Properties window, which I am 
currently working on because sicking's computer is broken. This involves 
removing the page-specific stuff and concentrating on the element stuff only, 
and also not having Properties appear unless there are some. 

Gerv

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

If we merge properties with page info we can't just have one contextmenu item.
What if the user rightclicks on an image that is in a link, does he want info on
the page, the link or the image? It's not good if the user has to bring up the
pageinfo dialog and naviagate in that to find info on a link or an image.

What we *could* do is to move the image and link info in the properties window
to the pageinfo window and have a contextmenu that contains "Page Info", "Link
Info" and "Image Info". The "Link Info" and "Image Info" would only be visible
when appropriate.

When clicking "Link Info" the pageinfo dialog is opened and the Links tab
selected and correct link is selected in the listbox. The same would happen when
selecting "Image Info". However we would need to add room to display the link
metadata below the list of links, the same goes for images.

But the Quote, InsDel and Misc info in the current properties window should IMHO
remain where it is now. I can't find an appropriate place for that in the
pageinfo dialog...

Comment 4

[Blake Ross]

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

Comment 5

[John Keiser (jkeiser)]

Merging the Properties and Page Info to become Element Info, which (correct me 
if I'm wrong) is what Jonas is talking about, doesn't sound good to me.  The 
problem is, who wants to click on a Links tab when there is only one link, or 
an Images tab when there is only one image?

I think Properties should show up for the entire document when you are not 
clicking on a link or image.  This is more consistent with other programs.  But 
in this case, the Page Info dialog should show up instead of the element-level 
Properties dialog.

However this is done, the View Page Info still needs to be there in all cases, 
for consistency's sake.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

No that's not what I'm talking about. This is how I mean:

The PageInfo dialog should (amonst other things) contain a tab with a list of 
all links. If you select a link in the list information about that link is 
shown in an area below the list.

When you rightclick on a link the contextmenu will contain the item "Link 
Info". Clicking that item opens the PageInfo dialog, showing the linktab (with 
all links on the page) and the link you rightclicked on selected in the list. 
Since the link is selected you will immedeately be able to see information 
about the link below the list.

Same thing for images (but of course on a image tab containing a list of all 
images)

Comment 7

[Blake Ross]

Someone want to take this?  Gerv?  Daniel?

Comment 8

[Gervase Markham [:gerv]]

> it makes no sense to have two separate windows which are both for displaying 
> general information and metadata about the current page.

This was mpt's problem. It is fixed. The Properties window now only displays 
information about the right-clicked element. The Page Info window displays info 
about the entire page. These are semantically and logically separate and should 
not be merged.

mpt's enhancement requests would not provide good UI in the (common) case where 
you are right-clicking on multiple "layers" of things - an image which is also a 
link, and so on. Even if we ignored that problem, the current Page Info dialog 
doesn't support half the stuff it would need to to even attempt this.

It would be rude of me to mark this bug WONTFIX, but I strongly suggest that 
someone close it.

Gerv

Comment 9

[Blake Ross]

I think others are in a better position to judge the fate of this bug. --> Gerv

I will say that the current state of the properties dialog is unacceptable, and 
is facing almost certain backout soon if its aesthetics don't improve...

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Blake: could you be more specific about what you want changed? There is a patch 
in bug 84259 to make links look like links (skinability problem, they do sort-
of look good in modern), but is there something more you want changed?

The problem right now isn't that nobody is prepared to work on the properties 
window, the problem is that nobody has any suggestion on how it should work.

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

oops, make that "they do sort-of look good in clasic" in my above comment

Comment 12

[Gervase Markham [:gerv]]

Marking this bug WONTFIX. These two windows will not be merged.

> I will say that the current state of the properties dialog is unacceptable, 
> and is facing almost certain backout soon if its aesthetics don't improve...

This is the first time I've heard any complaints about the aesthetics of the 
Properties window. I can only repeat sicking's request for an elaboration from 
Blake, preferably in Newsgroups or a new RFE bug.

I would very much object to a backout without some solid reasons.

Gerv

Comment 13

[Matthew T (active 1999-2002)]

All three items requested in the original bug report WORKSFORME, build 
2001050308, Mac OS 9.1. The `Properties' item is no longer present in the page 
content context menu. `Page Info' is not at the bottom, but that's my fault.

> This is the first time I've heard any complaints about the aesthetics of the
> Properties window.

Well, where do we start? :-)

Comment 14

[Matthew T (active 1999-2002)]

Filed bug 89250 (tracking bug), bug 89258, bug 89261, bug 89262, bug 89264, and 
bug 89266 for initial cleanup of the Properties window.

Comment 15

[Blake Ross]

I don't know specifically at this point what needs changing, but I'm sure a new 
bug will get my creative juices flowing.

I do know that I look at a Windows Properties dialog, wherever it's from, and 
recognize it, and think professionalism. I look at ours, can't tell what it is, 
and think 'resizable, maximizable, minimizable window, uncopyable Flash-acting 
pseudo-url type thing that triggers on right click,' and other thoughts I can't 
repeat in this family-oriented bug database :-)

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Wow, I feel the complete opposite. I don't like the IE properties dialog, IMHO 
it's big and clumsy and has a low information-density. But that is an totally 
subjective oppinion and there could be some UI guidelines saying I'm wrong, but 
lets take that in the separate bugs mpt has filed

Comment 17

[Daniel Brooks [:db48x]]

Well, a windows property dialog (say for a file) does do it's job very well.
It's the IE property dialog that's horrible, in my opinion. A windows file
properties dialog presents pretty much every available piece of metadata stored
in the filesystem for any given file. IE's page info dialog cannot possibly hope
to present all of the available metadata in a single tab, so they just don't
even try. Oh, and has anyone ever seen IE's page properties window with more
than one tab? I never have, so why the lone tab?

Now, as for the topic at hand, I really don't think the Page Info window and the
Properties window should be merged, because they serve two seperate uses. The
Properties dialog is (was) there so that a user can point at something and say
"what's that?". It presents information about a single element at a time, an
image, a quote, a link, etc. The Page Info dialog on the other hand, is a dialog 
 that's there to present information about the entire page. It shows information
about every image, every link. It would be a simple matter for me to cook up
another tab for the Page Info window that distilled down the text of a page into
a list of paragraps and quotes, and gave their language or whatever else in a
nice neat list (it would literaly take about 5 minutes, it'd be almost cookie
cutter work), but that's not a very useful way to present the information.

Gerv said the two are "semantically and logically separate," and I agree.

I propose WONTFIXING it from here on out, and continuing the work in mpt's new
tracking bug for cleaning up the properties window.

Comment 18

[sairuh (rarely reading bugmail)]

mass verification of WorksForMe bugs: to find all bugspam pertaining to this,
set your search string to "IfItWorksForSlappyTheSquirrelThenItWFM".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. that it's still a problem with ***recent trunk builds*** on the all
appropriate platform[s]

b. provide clear steps to reproduce (unless a good test case is already in the
bug report), making sure it pertains to the original problem (avoid morphing as
much as possible :)