Closed Bug 193902 Opened 23 years ago Closed 23 years ago

Composer can open frameset or iframe documents but not edit them

Categories

(SeaMonkey :: Composer, defect)

Product:
SeaMonkey
Component:
Composer
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: pg133, Assigned: Brade)

References

(
URL
)

Details

Attachments

(2 files, 2 obsolete files)

update commands on document creation after focus is set
2.31 KB, patch
Details | Diff | Splinter Review
corrected patch to handle order properly
10.62 KB, patch
cmanske
: review+
sfraser_bugs
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 Can not edit the page: The Tabs: Normal, HTML Tags,<HTML> Source Do not appear to function However, The page can be opened by MS Frontpage. Reproducible: Always Steps to Reproduce: 1.open web location (or use edit page from the browser)
Chris--you can dupe this bug to another bug or make this the bug to cover the issue of telling users that Composer doesn't support iframe/frame editing.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
QA Contact: sujay → petersen
Hardware: PC → All
Summary: Can not edit the page → Can not edit the page containing iframe
*** Bug 193288 has been marked as a duplicate of this bug. ***
Summary: Can not edit the page containing iframe → Composer can open frameset or iframe documents but not edit them
-->brade
Assignee: composer → brade
Index: nsEditingSession.h ... + nsWeakPtr mWindowToBeEdited; This can only be temporary. We have to allow people to call MakeWindowEditable on different subframes of a frameset whenever they want. +#if 0 + // Shouldn't we do this when we want to edit sub-frames? + return MakeWindowEditable(domWindow, "html", PR_FALSE); +#else Perhaps, if some 'all subframes' flag is set. I think by changing NotifyingCurrentDocument() you're subverting the document load/page load notifications. Document load notifications happen for each subframe, and page load notifications happen (before the patch) for the top-level document. With your changes, page load notifications happen for the subframe that was made editable, which might not be the top-level frame. I agree with the spirit of your patch (keep the document editable with an iframe), but I'd prefer not messing with NotifyingCurrentDocument().
Attachment #115008 - Attachment is obsolete: true
Attachment #115031 - Flags: superreview+
Comment on attachment 115031 [details] [diff] [review] cleanup of previous patch based on discussion with smfr I don't think we need the "(void)" on line: + (void)StartDocumentLoad
Comment on attachment 115031 [details] [diff] [review] cleanup of previous patch based on discussion with smfr r=glazman modulo the very minor modifs discussed on IRC
Attachment #115031 - Flags: review+
Attachment #115503 - Flags: review?(neil)
> I don't think we need the "(void)" on line: > + (void)StartDocumentLoad Yeah, leave it in. It indicates that the return value is being explicitly ignored. + // commands won't update properly on creation until focus is properly set + window.updateCommands("create"); Is there an ordering problem here between the 'doc was created' callback, and setting focus? I thought that "create" commands were supposed to be updated from the obs_documentCreated callback in editor.js?
Charley, Neil, Simon are right about the order being wrong. We can't get rid of mCanCreateEditor flag as easily as I wanted. This patch does some extra stuff that strictly speaking isn't part of this bug but perhaps is part of the long term (where we want to go). Preferences for bigger or smaller patch?
Attachment #115031 - Attachment is obsolete: true
Attachment #115552 - Flags: review+
Comment on attachment 115552 [details] [diff] [review] corrected patch to handle order properly Simon--do you want this as a step forward or do you want a more minimal patch?
Attachment #115552 - Flags: superreview?(sfraser)
Comment on attachment 115552 [details] [diff] [review] corrected patch to handle order properly mCanCreateEditor needs a better name, but sr=sfraser
Attachment #115552 - Flags: superreview?(sfraser) → superreview+
Attachment #115503 - Flags: review?(neil)
fix checked in; the JS cleanup work can go in another bug...
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Yes, framesets can no longer be opened directly in Composer. If you attend to open a frameset via edit page, Composer creates a new untitled document. If you open a document containing a iframe, you can only change the iframe attributes in the HTML source mode. Tested under 2003-02-27-09 Mach-O and 2003-02-27-09 Linux trunk builds.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: