Matthew T (active 1999-2002) Reporter
	Description • 24 years ago

Build: 2001051504, Mac OS 9.1

Currently if you open the `File' menu, you could be excused for thinking you 
were suffering from double vision. The menu has two `New' items and two `Open' 
items, contrary to almost every other application on Windows and Mac OS.

Merging the two `New' items into one is the subject of bug 37537; this bug 
concerns merging the two `Open' items into one. (See bug 14945 for some 
gruesome history.)

I can see three possible approaches.

(1) Have a single `Open ...' item, which opens a dialog for entering an
    address; this dialog having a `Choose File ...' button for allowing you to
    select a file.

    Advantages:
    -   Simple.
    -   Familiar to users of Internet Explorer for Windows, i.e. a large
        proportion of Mozilla's potential user base.
    -   Would fix bug 35339 for free, since you could check the `Open in New
        Window' checkbox in the main `Open' dialog once you had selected a
        file.
    -   Would allow us to implement bug 75378, if a sensible UI for that could
        be found.

    Disadvantages:
    -   Harder to open an address, if you have the address bar hidden.
    -   Would require two steps to open a file. However, we could implement
        Shift+accel+O to open the filepicker directly, just as we currently
        have Shift+accel+L to open the Open Location dialog.

(2) Have an `Open' submenu, containing:
    -   `Open File ...          accel+O'
    -   `Open Address ... Shift+accel+L'
    -   a separator
    -   a list of recently-opened files and URLs.

    Advantages:
    -   Symmetrical with the `File' > `New' submenu.
    -   Familiar to users of 4.x.
    -   Would allow access to recently-opened files and URLs, to those who have
        the address bar hidden (or who have no windows open). This would
        make Composer's `File' menu more consistent with the `File' menu in the
        rest of Mozilla, too (it currently has a `Recent Files' submenu).

    Disadvantages:
    -   A bit harder to access each item, for those who don't have their hands
        on the keyboard at the moment they want to open a file (or open an
        address, if they have the address bar hidden).

(3) Do nothing. Leave the UI as it is.

    Advantages:
    -   Requires the least work.
    -   Familiar to users of Internet Explorer for Mac OS.

    Disadvantages:
    -   The double vision problem persists.

	timeless
	Comment 1 • 24 years ago

while the address bar is hidden, we should bind accel-l to the open location 
dialog.

mpt: you missed one advantage for (3) it's low risk. [as everyone keeps 
reminding me: any code change has risk]

	Gervase Markham [:gerv]
	Comment 2 • 23 years ago

I'd go for Option 1. This could be implemented merely by removing Open File...
from the menu, and renaming Open Web Location... to Open Location... . However,
this would need newsgroup discussion first.

Gerv

	Jeremy M. Dolan
	Comment 3 • 23 years ago

> The menu has two `New' items and two `Open'

And now, two close (tab and window), two send (page and link), and two print.

> I'd go for Option 1. This could be implemented merely by removing Open
> File... from the menu, and renaming Open Web Location... to Open Location....
> However, this would need newsgroup discussion first.

I agree I like option 1... give the "Choose File" button a hotkey so it's
ctrl+shift+l, alt+c to open a file, then you can do it in a new tab/window too.
So, did this get the newsgroup discussion?

Actually, if open file is going away, why can't open location take over ctrl+O,
instead of ctrl+shift+L?  ctrl+o, alt+c is hardly bad, for file browsing. Alt+c
is basically a freebie as they're next to each other... thumb plus index, quick!

	James "Kovu" Russell
	Comment 4 • 23 years ago

As per a recent IRC discussion, I wanted to note that I think "Edit Page" should
become "Open in Composer". This would result in not two but THREE menu items
that start with the word Open. Three items is definitely worth a submenu on the
File menu such as follows:

File-->
   New-->
   Open-->File
       -->Web Location
       -->In Composer
   Close

Personally I think this would clean up the File menu nicely.

	neil klopfenstein
	Comment 5 • 23 years ago

At present, choosing "Open Web Location..." from the File menu opens up a
dialog with an "Open File" choice. It seems redundant to have this as well as
an "Open File..." entry on the File menu. This patch removes the Open File
entry from the menu, lumping it and Open Web Location into "Open...". The
hotkey for Open File is preserved.

	Felix Miata
	Comment 6 • 23 years ago

I recommend wontfix on this. Status quo resembles Netscape 3, which is much
better than the bad old days of Netscape 4 opening a separate dialog through
which to extricate a file. Opening a local file shouldn't require a three deep menu.

	timeless
	Comment 7 • 22 years ago

uid is being phased out.

	Robert Kaiser
	Comment 8 • 15 years ago

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

	Robert Kaiser
	Comment 9 • 15 years ago

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

	Robert Kaiser
	Comment 10 • 15 years ago

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

	Robert Kaiser
	Comment 11 • 15 years ago

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

	Robert Kaiser
	Comment 12 • 15 years ago

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

	Robert Kaiser
	Comment 13 • 15 years ago

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

	Robert Kaiser
	Comment 14 • 15 years ago

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

	Robert Kaiser
	Comment 15 • 14 years ago

We don't have plans to do this, esp. not as discussed in comment #0.

I wonder though if just removing "Open Web Location" completely would make sense, given that there's a location bar for that anyhow.

	Felix Miata
	Comment 16 • 14 years ago

(In reply to comment #15)
> I wonder though if just removing "Open Web Location" completely would make
> sense, given that there's a location bar for that anyhow.

I use the location bar as a mini bookmarks/history device. I never type or paste anything there that I don't want in that list, which means most of my editing/pasting/typing that would otherwise go there gets put in Open Web Location, or Google. My SM's search function lies in Google, which quickly enough loads every time I click the throbber. For Open Web Location to go away would be another advantage SM has over FF lost.