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

NEW
Unassigned

Status

--
enhancement
20 years ago
7 years ago

People

(Reporter: buster, Unassigned)

Tracking

(Depends on: 4 bugs, Blocks: 2 bugs, {topembed+})

Trunk
topembed+
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: editorbase+, edt_b3, URL)

(Reporter)

Description

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

Updated

20 years ago
Target Milestone: M13

Updated

20 years ago
Status: NEW → ASSIGNED
Target Milestone: M13 → M15

Comment 1

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

Comment 2

19 years ago
Make this an RFE bug. Bug 14599 exists in dealing gracefully with frameset docs 
now.
Priority: P3 → P4
Hardware: PC → All
Summary: cannot edit frameset document → [RFE] Handle editing of frameset documents
Target Milestone: M15 → M20

Comment 3

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

Comment 4

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

Comment 5

19 years ago
moving to future milestone
Assignee: sfraser → beppe
Status: ASSIGNED → NEW

Updated

19 years ago
Target Milestone: M20 → Future

Comment 6

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

Comment 7

19 years ago
moving back to previous owner
Assignee: beppe → sfraser

Comment 8

19 years ago
adding help wanted keyword
Keywords: helpwanted

Comment 9

19 years ago
Including this bug in RTM release notes.
Keywords: relnoteRTM

Comment 10

19 years ago
*** Bug 63515 has been marked as a duplicate of this bug. ***
Replacing kristif with robinf. Robin Foster-Clark is now the Composer doc 
contact.

Comment 12

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

Updated

18 years ago
Blocks: 77905

Updated

18 years ago
Blocks: 73799

Comment 13

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

Comment 14

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

Updated

17 years ago
Blocks: 152981

Comment 15

17 years ago
It's all yours.
Assignee: sfraser → cmanske
Component: Editor: Core → Editor: Composer

Comment 16

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

Updated

17 years ago
Depends on: 66296

Comment 17

17 years ago
reset milestone; nominate for nsbeta1; it affects mail so adding mailtrack keyword
Keywords: helpwanted, relnoteRTM → mailtrack, nsbeta1
Target Milestone: Future → mozilla1.3alpha

Comment 18

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

Comment 19

17 years ago
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement

Updated

17 years ago
Summary: [RFE] Handle editing of frameset documents → Handle editing of frameset documents

Updated

17 years ago
Depends on: 175822

Updated

17 years ago
Blocks: 157128

Updated

17 years ago
Blocks: 105556

Comment 20

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

Updated

16 years ago
Summary: Handle editing of frameset documents → Handle editing of frameset documents [and iframe's, too]

Comment 21

16 years ago
charlie is gone, whom should this fall too? Brade?
Assignee: cmanske → brade

Comment 22

16 years ago
Composer triage team: need info from qa on status with regards to editor clients
including mailnews.
QA Contact: sujay → petersen
Whiteboard: [need info]

Comment 23

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

16 years ago
Composer triage team: nsbeta1- (Chris to file a bug to alert the user about
being unable to edit docs with framesets.)
Keywords: nsbeta1 → nsbeta1-
Whiteboard: [need info]

Comment 25

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

Comment 26

16 years ago
make editorbase+ and nominate for topembed
Keywords: topembed
Whiteboard: editorbase+
Target Milestone: mozilla1.3alpha → mozilla1.4alpha

Updated

16 years ago
QA Contact: petersen → beppe

Updated

16 years ago
Depends on: 132700

Comment 27

16 years ago
Discussed in edt bug triage.  Plussing.
Keywords: topembed → topembed+

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: mozilla1.4alpha → mozilla1.4beta

Updated

16 years ago
Whiteboard: editorbase+ → editorbase+, edt_b3
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

16 years ago
*** 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?

Comment 31

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

Updated

16 years ago
Depends on: 157109
Target Milestone: mozilla1.4beta → mozilla1.5beta
*** Bug 213728 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey

Updated

14 years ago
OS: Windows NT → All
Target Milestone: mozilla1.5beta → Future

Comment 33

14 years ago
*** Bug 274935 has been marked as a duplicate of this bug. ***
Assignee: brade → nobody
Status: ASSIGNED → NEW
Priority: P4 → --
QA Contact: rubydoo123 → composer
Target Milestone: Future → ---

Comment 34

10 years ago
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
Status: NEW → UNCONFIRMED

Comment 35

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

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

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

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

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

10 years ago
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 41

9 years ago
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

7 years ago
Duplicate of this bug: 750187
You need to log in before you can comment on or make changes to this bug.