Closed
Bug 5710
Opened 26 years ago
Closed 26 years ago
file | open only allows for opening files, not pages
Categories
(SeaMonkey :: General, defect, P1)
SeaMonkey
General
Tracking
(Not tracked)
VERIFIED
FIXED
M6
People
(Reporter: cpratt, Assigned: law)
References
Details
although the 5.0 spec only refers to a 'file | open' menu item, the
implementation of this menu item has lost functionality when compared to legacy
Netscape browsers. in previous versions of communicator, selecting "File | Open
Page" gave you the option of entering a URL, or clicking another button to open
a file instead. With this in mind, we probably need to revisit the 5.0 spec and
fix it. The good thing about the 4.6 File | Open is that you can type in a path
to the file or a URL and it works. German, any thoughts on this?
Updated•26 years ago
|
Assignee: shuang → german
Comment 1•26 years ago
|
||
Assign to German and re-evaluate later.
the options are discussed under
news://news.mozilla.org/372F829F.E1DB2757@netscape.com
currently we are implementing the favored option c: which is:
1.There is one Open menu item, leading to a dialog. This dialog has an
editfield which accepts both URL and has a "Select File..." button next to
it. The browse button opens a getFile dialog, and after selecting a file,
the translated URL (file://...) gets put into the edit field much like what
we see in the URLfield on the location bar today.
2.The user has a choice of "Browse" or "Edit" through radio buttons
-- we are not implementing this for now since there is currently no disitinct
editor application.--
3.After selecting a local file or a URL, this gets opened in a new window.
4.A "Go to URL" item in the "Go menu will always re-use the current
window
Re-assigning to Bill Law since he's implementing this for now.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
I've pretty much implemented this in today's (5/18) build.
Notes:
1. I mislabelled the "Select File..." button as "Choose File...". I'll fix that
today.
2. "Select File..." does not return with the selected in the edit field (it
opens the selected file directly). This is mostly due to expediency (the code
that put up the file picker also opened the file rather than returning the
selected file).
3. There is a "Open in new window" checkbox. It defaults to unchecked; please
advise if this is incorrect (I've got two bugs asking for the opposite thing).
4. The dialog doesn't close automatically (due to a crasher bug); the user must
close it manually using the close box.
I'd like to close this one out and issue new bugs for any problems with the
current implementation.
The "open in new window" sounds good to me. Perhaps we could make its state an
implied preference - ie if the user checks it once, it remains checked for
subsequent uses? that would seem to provided the best of both worlds: anyone
used to legacy behavior (files and URLs opened in the same window) could keep
using it that way, and yet anyone who would like to always open files and URLs
in a new window could do that by checking the box once... German?
this looks fine to me - works with files and URLs. there are problems with its
current behavior, but those will be covered in other bugs.
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•