This is related to bug 40867, but it's clearly a future enhancement. I think it would be useful to have an additional feature related to "View Page Source", something like "View/Edit Live Page Source". I'm thinking that "View Live Page Source" could display the original page source AS MODIFIED (i.e. comments and whitespace would be preserved as much as possible) by subsequent changes to the DOM, form field information typed, etc. The "live" aspect is that continuing changes to the DOM in the original browser window would be immediately reflected in the "View Live Page Source" screen as well. There could be a "Save As" option in the source screen to save the modified source, allowing the normal browser's "Save As" to only save the original source from before any DOM changes were made. Similarly, the source screen could act as an editable text field, allowing the user (or web developer, more likely) to type changes into the source screen and have them be instantly reflected "live" in the associated browser window. Especially with (selectable) syntax/error highlighting, this could make it easier to cleanup the page source and instantly visualize the results, especially when the page is generated dynamically. I think a feature like this would probably be complex and might be difficult to implement well, but it could be REALLY useful to web developers out there...

I'm not sure if "Editor" is the best component for this, but I selected that since I'm suggesting that the source window be editable -- but editable as source rather than in the normal HTML composer. Maybe the WYSIWYG editing should be a separate mode, and these suggestions perhaps belong under another component entirely?

Parts of this bug are covered by bug 60426.

Adding RFE and marking NEW to get it off our unconfirmed radar.

Beppe: how hard would it be for the <stack/> or <deck/> that composer uses to be spanned across multiple windows, so that someone could type something in the source view and see it in the preview.

Should there be a meta bug for this and bug 60426 and any other bugs that seem on this theme?

it would actually take a lot of effort to get this to work, I will move this one over to future and keep it in the rfe list, just in case there is someone who really wants to take this on.

I also had the sense that it would take a lot of effort. I just wanted to throw it out there in case someone wanted to tackle it, or at least to keep it as a note for later. I think it would be cool to have, but it's not something I'd spend my own time on just yet...

Lots of us (and composer users on the outside) want this. We think it's probably hard to do, but we're going to be keeping it in mind as we work on other architectural changes, in the hope that it might turn out to be easier than everybody thinks or might fall out of other work that we needed to do anyway.

Please explain how a DOM change in the page should affect the edited source.

the same as if you manually toggled views?

I don't understand. Do changes in edited source take effect on the web page? If so, what happens if the source is being typed in, and is in an inconsistent state, and the web page changes? Do the typed in changes get deleted or what? If not, why have the feature?

live edit doesn't refer to live reloading of a remote page, but live updating of a page view while editing the source.

I know that, but web pages can modify themselves through the DOM while you're editing them.

Ack. you're right the rfe allows the dom to be continually modified by the live page. that's just a bunch of dangerous listeners, not a big deal in the grand scheme of things :-) So yes, if I add <p id="a" class="b">this</p> then it's immediately there, and if there's a script running in the live page that enumerates objects it will notice this thing the next time it does a dom query for it. if the live page makes a change to the dom, the source view would automatically update. Personally, i'd want a 'pause' button.

OK, so what happens when the page is not consistent? In other words, you've half typed in a tag, or half deleted it, or whatever? Does it get nuked by changes to the page? When? There's a whole kettle of fish as to what might happen if you're making changes while the page changes, because editing source can't be done with a single transaction. If this were "Edit Live DOM", that would be more practical I think. As for "View Live Page Source", that would certainly be doable. I believe Mozilla currently does display the live source, but I'd consider that a bug, plus I don't think it's updated.

If the source window has current focus, then we know that the user may be in the middle of typing something, and we shouldn't let dom changes override the source window without asking the user first. If the source window does not have focus, then the user isn't in the middle of typing there, and it's much safer to assume that we can use it as a source view that reflects the live document.

Or even worse, what happens if a script does theimg = getElementById("theimageid"); then you remove the image element now the script does: theimg.src = "blah"; an error occurs. I like the changes appearing in the source viewer every time the DOM is updated, but I don't like the idea of changes made in the source viewer happening in the page. There is only one real possibility I see: The source is constantly updated. You hit "pause" as timeless suggested on the source editor (which gives you some time so you don't have to race against the javascript). You then change the page and hit "continue". Any errors that occur will stop execution totally and ask you to fix whatever lines are causing the problem or fix the offending part of the DOM(or else start over). Variables could be changed using a section at the bottom of the window called immediate. You type the code in and click run immediate to change the vars (like in QBasic). A way to edit the DOM would be with a run-time debugging environment (bug 58413). Actually, the more I think about this, the more I think that this would be most successful, and would only be truly useful as part of a run-time environment where you could set breakpoints, single step, change code, etc. like in QBasic. When a change is thought to be too large to continue, then you would have to start over. BTW: QBasic is a dynamic Basic environment. As part of a dynamic run-time environment (as javascript should be), this View/Edit Live Source would work very well. One other thing bothers me. Are there security issues in this?

I think "view live dom as html code" and "edit in one pane, see results in another pane immediately" should be separate feature requests.

-->cmanske

spam composer change

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

I don't think that the source should update as the page changes. We have debuggers for that. Also, it would interfere with editing. Instead, there should just be an option to load the live page source in View Source (and refresh it) - Mathew Tuck comment #15 Does the DOM Viewer/javascript debugger allow you to edit the DOM? It would probably be a mess trying to merge changes back into a currently active web page, and might cause all kinds of nasty errors in the javascript and DOM. There is already a bug for editing source in view source (bug 143409). There should only be one issue per bug anyway. We can't allow for updating the live source (which would probably require merging) until we allow viewing of it and also editing of view source. (Unless you want to do this in composer which might cause dependencies). I propose removing the Edit portion of the summary, reassigning it to ViewSource, and forget about updating the live source after we edit the code (at least for this bug).

See also: Bug 134732 about moving the current CSS into the tags under style.

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

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420