Closed Bug 172147 Opened 23 years ago Closed 23 years ago

URL in composition "decoration" continues on next line

Categories

(Core :: DOM: Editor, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: mtownsen, Assigned: mozeditor)

Details

(Whiteboard: editorbase+; fixinhand; need r=,sr=)

Attachments

(1 file)

While in the mail composition window after doing a 'Send Link...', if you move the cursor to the end of the message (the end of the line with the link in it), and hit return to go to the next line, the decoration for the link continues when you are typing new information. To get around this, if you go to the end of the line and hit the space bar before hitting return, then all is ok.
I can confirm the problem, this is very annoying. Accepting the bug unless Varada has some free cycle to work on it...
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla1.3alpha
Note: in trunk build 20021001, hitting space bar before enter doesn't release the decoration. I have to select the unwanted link and use the menu iteme to remove link. Not sure what build this was reported against, but is seems worse in the trunk.
This sounds like it may be a bug for jfrancis
Keywords: mailtrack
Whiteboard: editorbase
EDITORBASE+. -> Joe
Assignee: ducarroz → jfrancis
Status: ASSIGNED → NEW
Whiteboard: editorbase → editorbase+
This is actually the result of a selection bug fix (I forget the bug#) where mjudge (at my request) changed selection so that when you click after the end of a line, the selection end up inside the inline styles at teh end of that line, rather than after them. For anything but a link, this is what users seem to expect. Not sure what I can do about clickng at the end of the link and then typing text: I can't realy tell that you didn't mean to extend the link text. But I can fix it for typing return. People almost never want to make a link with a <br> in it, and if they really want to they can use shift-return, which skips any special return logic we have and just puts in a <br>.
Status: NEW → ASSIGNED
added link splitting to WillInsertBreak(). Also factored out a blob of code which may need other callers someday.
cc'ing kin for sr love
Whiteboard: editorbase+ → editorbase+; fixinhand; need r=,sr=
changing product
Component: Composition → Editor: Core
OS: Windows 2000 → All
Product: MailNews → Browser
Target Milestone: mozilla1.3alpha → M1
Comment on attachment 105753 [details] [diff] [review] patch to editor/libeditor/html/nsHTMLEditRules.{h,cpp} sr=kin@netscape.com ==== Fix indentation: + res = ReturnStandardImpl(node, offset, aSelection); + *aHandled = PR_TRUE; ==== Fix the indentation of everything in |ReturnStandardImpl()| and lose the tabs. ==== |ReturnStandardImpl()| sounds funny to me ... but maybe it's just me. I kind of like |StandardBreakImpl()|.
Attachment #105753 - Flags: superreview+
Comment on attachment 105753 [details] [diff] [review] patch to editor/libeditor/html/nsHTMLEditRules.{h,cpp} r=brade with above changes (I also prefer StandardBreakImpl if it matters).
Attachment #105753 - Flags: review+
fix landed on trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
tested using build from 20030407 on win2K, dropping in a link and hitting return to continue writing does indeed terminate the link.
Status: RESOLVED → VERIFIED
QA Contact: esther → beppe
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: