we cannot edit a frameset document. we rely on being able to find the one and only body tag, and this is ambiguous in framesets. we really need a design session for what it means to edit a frameset document. I would argue that we should be editing the frameset only, and the documents being displayed are readonly. users who wish to edit the individual documents can do so separately. I would further argue that this isn't a 5.0 feature. We need a design to be sure we haven't shot ourselves in the foot, but for now let's just disable editing of framesets entirely. Is there some easy way to know that the user has tried to load a frameset, so we can put up an error message and halt document load?

Since composer is't in beta, this is post beta, right? M15.

Make this an RFE bug. Bug 14599 exists in dealing gracefully with frameset docs now.

*** Bug 29162 has been marked as a duplicate of this bug. ***

Note: we need to support 'Edit Frame' like 4.5 does. This should be pretty easy to do.

moving to future milestone

Is loading the frame's url into an editor (as Simon suggested) filed as a separate bug? We definitely should do that.

moving back to previous owner

adding help wanted keyword

Including this bug in RTM release notes.

*** Bug 63515 has been marked as a duplicate of this bug. ***

Replacing kristif with robinf. Robin Foster-Clark is now the Composer doc contact.

*** Bug 29162 has been marked as a duplicate of this bug. ***

*** Bug 89975 has been marked as a duplicate of this bug. ***

Simon: Were you still planning on working on this issue? Seems it should be reassigned to Composer. Reassign to me if you're not.

It's all yours.

*** Bug 158505 has been marked as a duplicate of this bug. ***

reset milestone; nominate for nsbeta1; it affects mail so adding mailtrack keyword

*** Bug 171309 has been marked as a duplicate of this bug. ***

[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.

*** Bug 189071 has been marked as a duplicate of this bug. ***

charlie is gone, whom should this fall too? Brade?

Composer triage team: need info from qa on status with regards to editor clients including mailnews.

You can indeed open a HTML frameset document in Composer. However, you can't actually modify it's source or any of it's child frames. 1) Open http://mozilla.org/quality/browser/standards/html/frame_frameborder_1.html in browser 2) Select Edit Page from File menu 3) Frameset is displayed in Composer 4) Place focus in the first frame and choose Select All from Edit menu. 5) Attempt to apply underline or Bold style. None is applied. In fact, you can't edit the frame content in any way. 6) Click on HTML source tab. No HTML code is displayed. This issue happens with any frameset (cols or rows) or iframe I attempt to edit: http://mozilla.org/quality/browser/standards/html/frame_scrolling_auto_cols.html http://mozilla.org/quality/browser/standards/html/frame_scrolling_auto_rows.html http://mozilla.org/quality/browser/standards/html/iframe_height_pixels.html Tested with Mach-0 2003-02-11-03 Trunk and Win32 2003-02-04-08 trunk.

Composer triage team: nsbeta1- (Chris to file a bug to alert the user about being unable to edit docs with framesets.)

*** Bug 41301 has been marked as a duplicate of this bug. ***

make editorbase+ and nominate for topembed

Discussed in edt bug triage. Plussing.

When editing a document containing an <iframe>, the frame's source may be a document that's not part of the current site, and probably is not available for editing, particularly if offline. Some means of suppressing the frame's content (as done for plugins with Bug 88956) and displaying a placeholder (as suggested in Bug 198468) is desired.

*** Bug 198974 has been marked as a duplicate of this bug. ***

The question is really: What should happen? I tried the example that Chris mentioned: http://mozilla.org/quality/browser/standards/html/frame_frameborder_1.html Here is what happens currently: When you load the frameset document and click any of it's frames first, the "edit page" command will open only that frame document into an editor window. That seems good. When you load the frameset document and do not click anywhere, but use the "edit page" command, the editor loads the complete frameset document into a composer window. However, the editor window showing the complete frameset document really misbehaves. As Chris said before, you can select content, but you can not modify anything. Actually, the composer looks completely broken. You can select any of the composer tabs, normal, tags, source or preview, but you always see the same view. I think the fact the "source view" does still show layout, but not the source, indicates that something is completely unhandled in composer. I see two possible fixes: Alternative A: - detect that we are trying to edit a frameset document - inform the user (message box) that we do not support editing a frameset document - do not open the composer window Alternative B: - implement a completely new mode for the composer window, where we allow the user to design the layout of the frameset - in this mode, none of the usual composer toolbars or control make sense, and they should be hidden/disabled, possibly it makes sense to create a new separate top level window mode for this - the "normal edit view" could display some vertical and horizontal lines, and allow the user to split each view horizontally or vertically, and specify the URLs of the document to be shown in that rectangle - the normal edit mode would not display any content - the source view would display the raw source of the frameset document - the preview view would display the complete frameset document and show the frame subdocuments - not sure if the "tags mode" would make sense Do we want to provide Alternative B? If we do, should this be done now or later? If we can not do B now, or if we decide to not do B at all, should we implement A?

*** Bug 204183 has been marked as a duplicate of this bug. ***

*** Bug 213728 has been marked as a duplicate of this bug. ***

*** Bug 274935 has been marked as a duplicate of this bug. ***

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614