Closed Bug 63892 Opened 24 years ago Closed 14 years ago

"View/Edit Live Page Source" mode.

Categories

(SeaMonkey :: Composer, enhancement)

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

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: deven, Unassigned)

References

Details

(Keywords: helpwanted) 

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Suggesting "View/Edit Live Page Source" mode. → [RFE] "View/Edit Live Page Source" mode.
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.
Target Milestone: --- → Future
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.
Keywords: helpwanted
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
Assignee: beppe → cmanske
spam composer change
Component: Editor: Core → Editor: Composer
*** 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.
Blocks: 134732
Summary: [RFE] "View/Edit Live Page Source" mode. → "View/Edit Live Page Source" mode.
Product: Browser → Seamonkey
Assignee: cmanske → nobody
QA Contact: sujay → composer
Target Milestone: Future → ---
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
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
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.