Closed Bug 113613 Opened 23 years ago Closed 22 years ago

"end of line" key resets inline style settings

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: glazou, Assigned: mjudge)

References

Details

(Keywords: embed, regression, topembed-, Whiteboard: EDITORBASE+ [adt2 rtm] [06/24][fixed in trunk])

Attachments

(1 file, 1 obsolete file)

tweaks for comments and order of code
2.19 KB, patch
blythe
: review+
kinmoz
: superreview+
jud
: approval+
Details | Diff | Splinter Review 
tested on Win2k with 096, ns62 and nightly

1. lauch composer
2. type some chars
3. click on the B button
4. type more chars
5. hit the "beginning of line" key
6. hit the "end of line" key
7. type more chars

result : the last typed chars are not bold but roman

expected result : the last typed chars should be bold
correction :

1. lauch composer
2. select "Paragraph" style from dropdown menu
3. type some chars
4. click on the B button
5. type more chars
6. hit the "beginning of line" key
7. hit the "end of line" key
8. type more chars


I can't even find the "select end of line" code.  I beleive Akkana may know
where it lives.  Whereever it is, it needs to stick to text nodes when possible.
Assignee: jfrancis → akkana
The command is IntraLineMove, implemented in nsSelection.cpp.  We call it in
various places in the editor, but I believe the key bindings call it directly
via the selection controller.
Joe, were you implying selection should do this automatically?  If so, it's a
selection bug and should go to Mike.  I thought the editor usually just found
the "nearest point" and didn't insist on the selection being smart ...
Assignee: akkana → kin
nominate for editorbase consideration
I think this is a regression (though not 100% sure)

cc jfrancis since Akkana addressed above questions to him.

kin--should this bug be reassigned to joe?
Keywords: regression
OS: Windows 2000 → All
Hardware: PC → All
Whiteboard: EDITORBASE
I guess the question I would ask is why is the selection navigation code 
inconsistent when moving to end of line in body text ending with a bold, and end 
of line in a block?

In the case of the body text, the end of line code puts the caret inside the 
bold, whereas in the block (<p>) case, it's putting it outside.

I'd probably give it to mjudge to figure out what's different in those 2 cases.
Assignee: kin → mjudge
Keywords: nsbeta1+
Whiteboard: EDITORBASE → EDITORBASE+
Keywords: topembed
it all depends on what layout does.  With <P> they probably surround it with 
something that the end of line code jumps past. I will keep looking at this
Status: NEW → ASSIGNED
editorbase+ set milestone to 1.0
Target Milestone: --- → mozilla1.0
Keywords: topembed → embed, topembed-
Whiteboard: EDITORBASE+ → EDITORBASE+ [adt2]
Whiteboard: EDITORBASE+ [adt2] → EDITORBASE+ [adt2 rtm]
Sujay, can you see if this still is a problem in the trunk?
This is still a problem on 5/8 trunk build.

I used Daniel's second set of steps...
Attached patch fix for nsFrame.cpp only (obsolete) — — Splinter Review 
Fix that will check when drilling to end of line. if we hit a BR node then stop
and back up a frame and use previous.
Blocks: 143047
what are the chances this one can be fixed by 06.14.2002? pls provide an eta.
thanks!
Whiteboard: EDITORBASE+ [adt2 rtm] → EDITORBASE+ [adt2 rtm] [Needs Reviews] [eta needed]
eta on checking in is as soon as i can get r,sr,a.  The bug is fixed currently 
in my tree
Comment on attachment 84703 [details] [diff] [review]
fix for nsFrame.cpp only

r=blythe
Attachment #84703 - Flags: review+
better patch to spell out what i had changed in my tree.  Small modification to
move the code check for next frame to after the null check.  also fix comment.
Attachment #84703 - Attachment is obsolete: true
Comment on attachment 87410 [details] [diff] [review]
tweaks for comments and order of code

sr=kin@netscape.com
Attachment #87410 - Flags: superreview+
Comment on attachment 87410 [details] [diff] [review]
tweaks for comments and order of code

r=blythe
Attachment #87410 - Flags: review+
Add adt nomination since this has review and super review
Keywords: adt1.0.1
its checked into trunk. i am asking for driver approval for branch. this 
correct?
sujay - can you pls verify this one on the trunk, tomorrow? thank!
Keywords: approval, mozilla1.0.1
Whiteboard: EDITORBASE+ [adt2 rtm] [Needs Reviews] [eta needed] → EDITORBASE+ [adt2 rtm] [06/14]
erm, verification pleeze?
Shrir, can you take a look at this fix and verify it on the trunk.  thx.
QA Contact: sujay → shrir
Whiteboard: EDITORBASE+ [adt2 rtm] [06/14] → EDITORBASE+ [adt2 rtm] [06/24]
By,
5. hit the "beginning of line" key
6. hit the "end of line" key


do u mean 'HOME" and "END" ? Pls explain. Thx !
on most systems home and end yes.  not sure what all platforms have mapped for 
this. on unix it may be a combination of keys not sure.
tested on 0620 trunk NT...this does not work. can someone chek ? 
I still see this bug using win 2k trunk build 2002062008
ok i am going to scream here. the patch is NOT in the tree.  I just confirmed it 
on new pull.  I will reapply the patch and check it in when tree opens again.  
This is very frustrating. I wish someone took a look at this earlier.  now I 
will try to check it into trunk, get a verification, and adt approval by the end 
of the day tomorrow to try to get this on branch.
I checked this into trunk for Mike.
Am I allowed to verify? I've applied the patch and tested it.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Whiteboard: EDITORBASE+ [adt2 rtm] [06/24] → EDITORBASE+ [adt2 rtm] [06/21][fixed in trunk]
Okay, I'm confused. I thought it was on the trunk based on comment 19 "its
checked into trunk." so I thought we were just waiting on verification. 
On Linux, today's trunk build, following both scenarios at the beginning of this
bug (both normal and paragraph mode): after going to end of line the characters
typed are still bold.  So it looks like the fix is working on linux.

shri, keys to do this:
Windows: HOME/END
Linux: HOME/END, or ctl-A/ctl-E (I used the latter pair)
Mac: something else (HOME/END go to beginning/end of the document, not line).
Verified on Windows (2000).
Whiteboard: EDITORBASE+ [adt2 rtm] [06/21][fixed in trunk] → EDITORBASE+ [adt2 rtm] [06/24][fixed in trunk]
Target Milestone: mozilla1.0 → mozilla1.0.1
Verified fixed on Mac OSX and OS9 using the 06-21 trunk build(s).

Also, for future reference, the keyboard shortcuts on Mac are (Apple - Right
arrow and Apple - Left arrow)
Status: RESOLVED → VERIFIED
and I verified on 98,NT and linux 7.1. 
Okay Mike, get permission from drivers and land this on the branch please
Adding adt1.0.1+ on behalf of the adt for checkin to the 1.0 branch.  Please get
drivers approval before checking in. When you check this into the branch, please
change the mozilla1.0.1+ keyword to fixed1.0.1
Keywords: adt1.0.1 → adt1.0.1+
reopening since i wanted this checked into branch. maybe drivers arent lookin 
at it because it looks fixed.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
my bad, talked to dbaron. he says leave it as verified fixed and drivers will 
look at it.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
back to verified
Status: RESOLVED → VERIFIED
Attachment #87410 - Flags: approval+
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+
changing keywords to reflect checkin to branch
Keywords: mozilla1.0.1+ → fixed1.0.1
QA Contact: shrir → sujay
verified in 7/24 branch build.
Keywords: fixed1.0.1 → verified1.0.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: