Closed Bug 89975 Opened 23 years ago Closed 23 years ago

Edit frame menu item is missing

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: IDontUseMozillaAnyMore, Assigned: cmanske)

References

(
URL
)

Details

Attachments

(1 file, 2 obsolete files)

A much better Fix
8.14 KB, patch
hewitt
: review+
bugs
: superreview+
Details | Diff | Splinter Review 
There is no 'Edit Frame' menu command. If you are viewing a framed
document and wish to edit one of the documents you have to first
select 'Open frame in new window' and then select edit page. If,
however, the document contains a script that checks that it's frame
set is loaded and auto-reloads when it's not pressent, this work around
is not viable. NS4.x used to have the 'Edit Frame' command on the file
menu, which allowed you to click in the frame to be edited and then
go straight to this page in composer. This is not a request to be
able to edit a frameset document.
dup


*** This bug has been marked as a duplicate of 14156 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
This is *NOT* a duplicate of that item. This is not a request to be able to edit
frameset documents. It is a request to be able to click in a frame and then
choose Edit Frame from the file menu and have the document in the frame you
clicked available for editing in composer.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
You're right.
Assignee: asa → pchen
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
QA Contact: doronr → sairuh
see bug 93184 for reworking the Edit and View browser main menu items, where
this would be applicable.

gerv, should this be yours?
Blocks: 93184
I think the chances of this making it into the context menu are very slim,
because we are in a constant battle to avoid context menu bloat, and this is a
very niche request. What's wrong with Copy Frame Location, or whetever it's
called, and then firing up Composer and doing Open Web Page?

This isn't related to bug 93184, but there is another bug about the context menus.

mpt may have more to say.

Gerv
actually, my thought was to add Edit Frame to the File main menu, which i think
is a sensible request...esp since it exists in 4.x. :)

o'course, even in 4.x there wasn't cross-platform consistency here:

* on linux 4.x, the menu items are called: File > Edit Frame Set and File > Edit
Frame.

* on win32 4.x, the menu items are called: File > Edit Page and File > Edit Frame.

* on mac9.x 4.x, the menu items are the same as on win32 4.x.

anyhow you're right, gerv, bug 93184 wouldn't apply in this case. [sorry,
thinking more generically about the browser's main menus...] removing dependency.
No longer blocks: 93184
Keywords: 4xp, mozilla0.9.4
For now, could we just make File>Edit page edit the current frame? this way 
people don't get a rendered document + <press ok to close editor because we're 
lame>
timeless, interesting suggestion.

however, it might be tricky since we [still] don't display active frames. what
if the user forgot to explicitly make a frame active [true, i'm making a strange
assumption here]? composer won't open since it cannot handle a frameset.
You mean we don't show any border on the active frame like we do in 4.7?

imo that's not a big deal. so they get the lame dialog, go back, click 
somewhere, try again, and it works.  -- of course it's not perfect, but imo 
it's still an improvement -- and we can do it today.

I'm marking the dependency, i know it's not a strong one but I think it's worth 
having the reference.
Depends on: 42758
IMO, not a stop-ship or must  for TM0.9.4.
marking p3 and mozilla1.0
Priority: -- → P3
Target Milestone: --- → mozilla1.0
Don't think I'll get to this for mozilla1.0. Marking mozilla1.2
Keywords: helpwanted
Target Milestone: mozilla1.0 → mozilla1.2
This is a major pain, it would appear to be so simple a fix too. It makes
Mozilla completely useless for editing our website. Just try it yourself. Go to
http://www.ditl.org and try and edit one of the frames. The normal work around
of opening the frame in a new window and then editing that page is not viable
because our site checks to see if the frames are loaded and reopens the page in
the frameset if it isn't. I guess it's time to order a copy of Dreamweaver.

What ever happened to timeless's surgestion of making edit page work with the
current frame, that would solve this probelem.
I think we need to try to get this fixed before mozilla 1.0.
Whiteboard: EDITORBASE
I agree with Kathy an Ian. If you can't get to it, assign it to me.
> because our site checks to see if the frames are loaded and reopens the page in
> the frameset if it isn't.

That's your problem right there - remove this user-annoying behaviour, and
everything will be fine :-)

I like timeless' suggestion too - a great way to do this without bloating the
context menus (a spec's currently being hammered out, so whoever fixes this bug
needs to coordinate with that group.)

Gerv


over to charley...
Assignee: pchen → cmanske
Target Milestone: mozilla1.2 → ---
Status: NEW → ASSIGNED
Keywords: mozilla0.9.4
Target Milestone: --- → mozilla1.0
changing milestone
Target Milestone: mozilla1.0 → mozilla0.9.8
So with this fix, we don't bother to change menuitem text to "Edit Frame".
How important is that?
Keywords: helpwanted → patch, review
Whiteboard: EDITORBASE → EDITORBASE, FIX IN HAND, need r=,sr=
Comment on attachment 65179 [details] [diff] [review]
Make "Edit Page" use the focused frame if it exists

good god, another context menu item.  I'll sr it for now and leave it to UE to
decide it's ultimate fate down the road.
Attachment #65179 - Flags: superreview+
Note: I reopened 42758 'cause I don't see any focus styling when I click in a 
frame.
context menu item? this bug was originally to add Edit Frame to the toplevel
File menu; see my comment #6...
Comment on attachment 65179 [details] [diff] [review]
Make "Edit Page" use the focused frame if it exists

r=syd
Attachment #65179 - Flags: review+
This fix fulfills timless' suggestion in comment #7 to simply make "Edit Page" use 
the frame if that is focused. We should probably change the menuitem text to 
"Edit Frame" in those circumstances (let's file another bug on that issue.)

Patch from 1/15 checked in. I'll keep this open to address menu text issue, if
we can get to it.
Keywords: patch, review
Whiteboard: EDITORBASE, FIX IN HAND, need r=,sr=
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Does this patch actually work in this situation:
 1) open navigator
 2) load page with frames
 3) select a frame
 4) load a different url
 5) choose edit page

I'm concerned because I never see gFocusedURL modified outside of frame focus.

Also, the current problem is that you now can't edit a frameset (probably better
than not editing a frame).  Please file a new bug on this issue if you resolve
this bug without addressing it.
Since bug 120358 is filed for menu text issue, I'm resolving this one.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Brade was correct: gFocusedURL is no reset properly when a new document is 
loaded. Must fix that.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.9 → mozilla0.9.8
When a new URL is loaded, contentAreaFrameFocus() is not always called, thus
we have to initialize in multiple places:
1st block in patch is in code that happens when filemenu is opened
2nd is in contentAreaFrameFocus(), when page doesn't have frames
3rd is when new page is loaded in standard window
4th is when new page is loaded in tab window
I guess we could leave out the 2nd, but it seemed safe to include it.
Attachment #65179 - Attachment is obsolete: true
Keywords: patch, review
Whiteboard: FIX IN HAND, need r=,sr=
In last comment, I meant "we could leave out the 1st, but it seemed safe to 
include it."
Comment on attachment 65516 [details] [diff] [review]
Fix to initialize gFocusedURL and gFocusedDocument 

Charley and I have discussed this on irc.

I am unhappy with the use of globals.

I'd like to see the following:
 * globals removed from navigator.js
 * editPageOrFrame removed from navigator.js
 * editPageOrFrame moved into editorApplicationOverlay.js or some more
appropriate location
Attachment #65516 - Flags: needs-work+
Ok, we've rethought the whole problem. 
1. Moved all editor-related code out of XPFE and into
editorApplicationOverlay.js,
which is included via editorNavigatorOverlay.xul by the browser.
2. Backed out changes to navigator.js from 1st patch.
3. Implemented much simper editPageOrFrame() to detect a focused frame.
Attachment #65516 - Attachment is obsolete: true
I'd still like the useless globals removed (or aren't they useless?)

ben--can you please comment on the need for globals or if they should be removed?
cc blake and hewitt in case they know about these globals
Ben: In an attempt to eliminate gFocused... globals, as brade suggested, I 
thought we could simply call this from "Save Frame" menuitem:
function saveFrameDocument()
{
  var focusedWindow = document.commandDispatcher.focusedWindow;
  if (isDocumentFrame(focusedWindow))
    saveDocument(focusedWindow.document);
}
I've tested that and it seems to work fine.
We could then eliminate gFocusedURL, gFocusedDocuement and
contentAreaFrameFocus() from navigator.js
The context menu uses the target document from the window clicked on, so it is
not affected.

checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
NOT checked in (sorry, wrong bug)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Comment on attachment 65639 [details] [diff] [review]
A much better Fix

r=hewitt
Attachment #65639 - Flags: review+
checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Keywords: patch, review
Resolution: --- → FIXED
Whiteboard: FIX IN HAND, need r=,sr=
> Moved all editor-related code out of XPFE and into editorApplicationOverlay.js,
> which is included via editorNavigatorOverlay.xul by the browser.

But not by other apps. This means that the editor button in the component bar is
broken unless the app happens to overlay editorNavigatorOverlay.xul or
editorMailOverlay.xul, i.e. only for browser and mail, but not e.g. ChatZilla.

Please either move NewEditorWindow() back to tasksOverlay.js, or (better) create
editorTasksOverlay.xul and editorTasksOverlay.js to resolve this, thus making it
easier to remove Editor.
Bug 122271 is filed on the issue Neil described.
verified fixed on win2k and linux rh7.2 [2002.01.29.10 comm bits] and mac 10.1.2
[2002.01.29.11 comm].
Status: RESOLVED → VERIFIED
Verified fixed on MacOS 9.x build 2002041711
Product: Core → Mozilla Application Suite
Blocks: 537155
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: