HTML Source mode doesn't put caret where it was in wysiwyg. I expect that when I toggle between the wysiwyg and edit source modes that my caret won't be moved on me. Instead, even if I don't make any changes, the caret always goes to the top of the document.

nominate for nsbeta3

Sorry, must wait for multiple editor support for one docshell so we can use the full text editor for HTML Source editing. This isn't possible with current implementation.

setting keyword to helpwanted

See also bug 28809, an rfe for "view source at selection" in the browser.

I don't think showing source for selection in browser (28809) has much to do with this request. The HTML Source editor is a separate text editor and will use the new embedable text editor to be develeped during current 6.5 work.

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

spam composer change

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

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

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

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

Please note that switching out of HTML Source view to any other view exhibits the problem, not just wysiwyg mode

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

nsbeta1- per buffy triage

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

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

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

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

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

adding "cursor" to the summary to make this one easier to find.

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

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

I agree with comment 12, the summary of this bug needs to be rephrased - it isn't related to wysiwyg mode, but to switching out of the source pane. The summaries of most of dupes would be just fine. Prog.

Selection state should be preserved too, similar to as currently Frontpage does.

Updating summary

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

(In reply to comment #26) > *** Bug 231077 has been marked as a duplicate of this bug. *** When going out of source and into normal, the cursor disappears entirely. It can only be brought back by clicking on the page or with down arrow (cursor goes to bottom of page) or with up arrow (cursor goes to top of page).

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

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

I'm on it :-)

This patch switches from a b&w source view to a colored source view (this is bmo bug 58730) and preserves the selection when switching from Normal/AllTags/Preview to Source view. Since this patch applies viewsource.css to the view, it also fixes bmo bug 100913. Not fixed by this patch: 1. the source view is not scrolled to show selection in the viewport. I don't know why but scrollSelectionIntoView() just does not work on gSourceTextEditor's selection controller 2. the selection is not preserved switching back from Source View to another one; this is considerably harder than the other way, given our architecture I suggest to deal with the two issues above in separate bugs. Reviews welcome.

Warning: I forgot to mention the colors are dynamic. If you change the source, the colors won't adapt to your changes. I wanted it to stand in a different bug.

Urgh... Please read "I forgot to mention the colors are **NOT** dynamic" in the previous comment. Sorry for spam.

Daniel: I think you may have to "formally" request a review of your patch. :-\

Comment on attachment 158416 [details] [diff] [review] fix #1 Neil, can you s[r] please ?

Apart from suggested theme tweaks to make the doctype blend in I found a couple of niggles: the selection nodes are left in the document and confuses cursor movement past them, and the regexp contains a lone ' which confuses vim. Presumably some other bug is preventing the caret from appearing in all modes.

Comment on attachment 158416 [details] [diff] [review] fix #1 a few comments: * is it possible to use xptr instead of storing the span tags? (I suspect not but want to bring up the issue.) * mozSanitizingHTMLSerializer::PreserveSelection has comment with typo: nothin --> nothing * Are the <span id=*> tags removed before editing in html source mode? Is the selection maintained from source view --> wysiwyg view? (I'd guess that is much harder and probably should be a different bug.) * I'd like to see more use of constants / named literals such as "&amp;" * I assume the removal of "mFlags" from nsHTMLContentSerializer.h is because it is in the parent class. Great work Daniel!

The selection code doesn't work when the start range is just after a tag, either a close or an open tag. Example: This is bold, but this is not Select "This is bold", press ^B, no bug in source mode Select the ",", bug appears in source mode Select the "This", bug appears in source mode Click on the <b>/<span> in the struct toolbar, no bug in source mode

Neil's comment indicates the patch is incomplete. Patch addresses problem in bug 58730 according to daniel.

It would be great if the cursor position was preserved when clicking from Normal to HTML Tags, to Source to Preview. Often I'm working in the editor, and need to make a HTML level tweak.

I think this thread of bug comments oscillates between two conceptually different issues: a) Whether the cursor is visible in the Source tab, and b) Whether the focus stays in the same place when moving from tab to tab. From a coding standpoint, a) and b) may be closely related, but I think they nevertheless are different issues. To me, both are important, but b) is more important.

Daniel, Neil, Are you still working on this ?

Seems, that they not...

Ten-year old patches usually no longer apply, nobody's working on this, and comment 36 and comment 38 suggest that this patch has problems. Cancelling review request.