14156 - Handle editing of frameset documents [and iframe's, too]

Status: NEW

(SeaMonkey :: Composer, enhancement)

Description

[buster]

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?

Comment 1

[Simon Fraser [no longer active]]

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

Comment 2

[Simon Fraser [no longer active]]

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

Comment 3

[Simon Fraser [no longer active]]

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

Comment 4

[Simon Fraser [no longer active]]

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

Comment 5

[rubydoo123]

moving to future milestone

Comment 6

[Charles Manske]

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

Comment 7

[rubydoo123]

moving back to previous owner

Comment 8

[rubydoo123]

adding help wanted keyword

Comment 9

[Kristi Fredrickson]

Including this bug in RTM release notes.

Comment 10

[rubydoo123]

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

Comment 11

[Kristi Fredrickson]

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

Comment 12

[Kathleen :Brade]

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

Comment 13

[Kathleen :Brade]

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

Comment 14

[Charles Manske]

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

Comment 15

[Simon Fraser [no longer active]]

It's all yours.

Comment 16

[R.K.Aa.]

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

Comment 17

[Kathleen :Brade]

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

Comment 18

[Kathleen :Brade]

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

Comment 19

[Brant Gurganus]

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

Comment 20

[Alfonso Martinez]

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

Comment 21

[saari (gone)]

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

Comment 22

[Samir Gehani]

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

Comment 23

[Chris Petersen]

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.

Comment 24

[Samir Gehani]

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

Comment 25

[Kathleen :Brade]

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

Comment 26

[Kathleen :Brade]

make editorbase+ and nominate for topembed

Comment 27

[Michael Buckland]

Discussed in edt bug triage.  Plussing.

Comment 28

[Mike Cowperthwaite]

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.

Comment 29

[Daniel Wang]

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

Comment 30

[Kai Engert (:KaiE:)]

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?

Comment 31

[Jo Hermans]

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

Comment 32

[Boris Zbarsky [:bzbarsky]]

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

Comment 33

[OstGote!]

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

Comment 34

[Robert Kaiser]

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

Comment 35

[Robert Kaiser]

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

Comment 36

[Robert Kaiser]

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

Comment 37

[Robert Kaiser]

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

Comment 38

[Robert Kaiser]

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

Comment 39

[Robert Kaiser]

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

Comment 40

[Robert Kaiser]

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