Open Bug 47040 Opened 24 years ago Updated 2 years ago

HTML Source mode doesn't put caret (cursor) and selection where it was in WYSIWYG

Categories

(SeaMonkey :: Composer, defect)

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

Tracking

(Not tracked)

People

(Reporter: Brade, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted)

Attachments

(2 files)

fix #1
28.92 KB, patch
Details | Diff | Splinter Review
Theme tweaks
1.31 KB, patch
Details | Diff | Splinter Review 
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
Keywords: nsbeta3
OS: Windows 3.1 → All
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.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
setting keyword to helpwanted
Keywords: nsbeta3 → 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
Component: Editor: Core → Editor: Composer
*** 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. ***
Keywords: nsbeta1
nsbeta1- per buffy triage
Keywords: nsbeta1 → nsbeta1-
*** 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. ***
Depends on: 69329
adding "cursor" to the summary to make this one easier to find.
Summary: HTML Source mode doesn't put caret where it was in wysiwyg → HTML Source mode doesn't put caret (cursor) where it was in wysiwyg
*** 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
Summary: HTML Source mode doesn't put caret (cursor) where it was in wysiwyg → HTML Source mode doesn't put caret (cursor) and selection where it was in WYSIWYG
Blocks: 225010
*** 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 :-)
Assignee: cmanske → daniel
Status: ASSIGNED → NEW
Attached patch fix #1 — — Splinter Review 
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.
Status: NEW → ASSIGNED
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 ?
Attachment #158416 - Flags: review?(neil.parkwaycc.co.uk)
Attached patch Theme tweaks — — Splinter Review 
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
Product: Browser → Seamonkey
Neil's comment indicates the patch is incomplete.
Patch addresses problem in bug 58730 according to daniel.
Blocks: 58730
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 ?
Priority: P3 → --
QA Contact: sujay → composer
Target Milestone: Future → ---
Seems, that they not...
Assignee: daniel → nobody
Status: ASSIGNED → NEW
Attachment #158416 - Flags: review?(neil)
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: