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)

defect

Tracking

(Not tracked)

VERIFIED FIXED

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?
QA Contact: 4137
Assignee: shuang → german
Assign to German and re-evaluate later.
Assignee: german → law
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.
Priority: P3 → P1
Target Milestone: M6
*** Bug 6231 has been marked as a duplicate of this bug. ***
*** Bug 5507 has been marked as a duplicate of this bug. ***
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?
Status: RESOLVED → VERIFIED
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
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.