Edit frame menu item is missing

VERIFIED FIXED in mozilla0.9.9

Status

P3
normal
VERIFIED FIXED
17 years ago
9 years ago

People

(Reporter: IDontUseMozillaAnyMore, Assigned: cmanske)

Tracking

Trunk
mozilla0.9.9
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

17 years ago
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.

Comment 1

17 years ago
dup


*** This bug has been marked as a duplicate of 14156 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 2

17 years ago
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 → ---

Comment 3

17 years ago
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

Comment 7

17 years ago
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.
(Assignee)

Comment 9

17 years ago
You mean we don't show any border on the active frame like we do in 4.7?

Comment 10

17 years ago
Bug 42758.

Comment 11

17 years ago
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

Comment 12

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

Comment 13

17 years ago
marking p3 and mozilla1.0
Priority: -- → P3
Target Milestone: --- → mozilla1.0

Comment 14

17 years ago
Don't think I'll get to this for mozilla1.0. Marking mozilla1.2
Keywords: helpwanted
Target Milestone: mozilla1.0 → mozilla1.2
(Reporter)

Comment 15

17 years ago
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.

Comment 16

17 years ago
I think we need to try to get this fixed before mozilla 1.0.
Whiteboard: EDITORBASE
(Assignee)

Comment 17

17 years ago
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 → ---
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Keywords: mozilla0.9.4
Target Milestone: --- → mozilla1.0
(Assignee)

Comment 20

17 years ago
changing milestone
Target Milestone: mozilla1.0 → mozilla0.9.8
(Assignee)

Comment 21

17 years ago
Created attachment 65179 [details] [diff] [review]
Make "Edit Page" use the focused frame if it exists

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

Updated

17 years ago
Keywords: helpwanted → patch, review
Whiteboard: EDITORBASE → EDITORBASE, FIX IN HAND, need r=,sr=

Comment 22

17 years ago
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+
(Assignee)

Comment 23

17 years ago
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 25

17 years ago
Comment on attachment 65179 [details] [diff] [review]
Make "Edit Page" use the focused frame if it exists

r=syd
Attachment #65179 - Flags: review+
(Assignee)

Comment 26

17 years ago
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.)
(Assignee)

Comment 27

17 years ago
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

Comment 28

17 years ago
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.
(Assignee)

Comment 30

17 years ago
Since bug 120358 is filed for menu text issue, I'm resolving this one.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
(Assignee)

Comment 31

17 years ago
Brade was correct: gFocusedURL is no reset properly when a new document is 
loaded. Must fix that.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Updated

17 years ago
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.9 → mozilla0.9.8
(Assignee)

Comment 32

17 years ago
Created attachment 65516 [details] [diff] [review]
Fix to initialize gFocusedURL and gFocusedDocument 

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
(Assignee)

Updated

17 years ago
Keywords: patch, review
Whiteboard: FIX IN HAND, need r=,sr=
(Assignee)

Comment 33

17 years ago
In last comment, I meant "we could leave out the 1st, but it seemed safe to 
include it."

Comment 34

17 years ago
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+
(Assignee)

Comment 35

17 years ago
Created attachment 65639 [details] [diff] [review]
A much better Fix

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

Comment 36

17 years ago
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?

Comment 37

17 years ago
cc blake and hewitt in case they know about these globals
(Assignee)

Comment 38

17 years ago
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.
(Assignee)

Comment 39

17 years ago
checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
(Assignee)

Comment 40

17 years ago
NOT checked in (sorry, wrong bug)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Updated

17 years ago
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Comment 42

17 years ago
Comment on attachment 65639 [details] [diff] [review]
A much better Fix

r=hewitt
Attachment #65639 - Flags: review+
(Assignee)

Comment 43

17 years ago
checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Keywords: patch, review
Resolution: --- → FIXED
Whiteboard: FIX IN HAND, need r=,sr=

Comment 44

17 years ago
> 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.
(Assignee)

Comment 45

17 years ago
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
(Reporter)

Comment 47

17 years ago
Verified fixed on MacOS 9.x build 2002041711
Product: Core → Mozilla Application Suite

Updated

9 years ago
Blocks: 537155
You need to log in before you can comment on or make changes to this bug.