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 ***

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.

You're right.

see bug 93184 for reworking the Edit and View browser main menu items, where this would be applicable. gerv, should this be yours?

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.

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?

Bug 42758.

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.

IMO, not a stop-ship or must for TM0.9.4.

marking p3 and mozilla1.0

Don't think I'll get to this for mozilla1.0. Marking 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.

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...

changing milestone

So with this fix, we don't bother to change menuitem text to "Edit Frame". How important is that?

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.

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

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.

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.

filed bug 120358 per comment 26.

Since bug 120358 is filed for menu text issue, I'm resolving this one.

Brade was correct: gFocusedURL is no reset properly when a new document is loaded. Must fix that.

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.

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

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.

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.

NOT checked in (sorry, wrong bug)

Comment on attachment 65639 [details] [diff] [review] A much better Fix [s]r=ben@netscape.com

Comment on attachment 65639 [details] [diff] [review] A much better Fix r=hewitt

checked in

> 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].

Verified fixed on MacOS 9.x build 2002041711