Closed Bug 98619 Opened 23 years ago Closed 18 years ago

caret appears chipped off and at the wrong place

Categories

(Core :: DOM: Selection, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME
mozilla1.4alpha

People

(Reporter: sujay, Assigned: mjudge)

References

()

Details

(Whiteboard: [QAHP] EDITORBASE+ verify 90171 also when verifying this one)

windows trunk 0620 saw this while verifying 80880 -copy-paste steps from 80880----- Steps: 1 Open Composer 2 Add a few items to a bulleted list 3 Keep the last item blank (do not enter any text and just leave the bullet there) 4 Save the File and Reopen in Composer Now, observe that the caret blinks outside the list and on top and appears a bit short and sticking to the top border on 4.x, the caret appears in front of the first list item(after the bullet) when I open the same saved file. ------- Additional Comments From beppe@netscape.com 2001-06-20 13:24 ------- easily reproducible -- however, there cannot be any leading bodytext for the caret to jump to the upper left. Adding an image for clarification ------- Additional Comments From beppe@netscape.com 2001-06-20 13:25 ------- Created an attachment (id=39377) screen grab of composer window ------- Additional Comments From beppe@netscape.com 2001-06-20 15:58 ------- assigning to joe based on the talk we had about where to put the caret after flipping back from source mode. ------- Additional Comments From sujay@netscape.com 2001-06-25 15:43 ------- Also see attachment in 69320...same problem...cursor is chipped off and blinking in upper left hand corner... we gotta fix this.. adding QAHP ------- Additional Comments From brade@netscape.com 2001-07-11 14:11 ------- *** Bug 90171 has been marked as a duplicate of this bug. *** ------- Additional Comments From brade@netscape.com 2001-08-27 06:47 ------- *** Bug 96901 has been marked as a duplicate of this bug. *** ------- Additional Comments From brade@netscape.com 2001-08-29 10:31 ------- *** Bug 96715 has been marked as a duplicate of this bug. *** ------- Additional Comments From jfrancis@netscape.com 2001-09-06 04:21 ------- ps: ignore comments about going to source view and back - use the original testcase to see the problem. ------- Additional Comments From jfrancis@netscape.com 2001-09-06 05:03 ------- *** Bug 86933 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
Whiteboard: [QAHP] verify 90171 also when verifying this one
Target Milestone: --- → mozilla1.0
*** Bug 86927 has been marked as a duplicate of this bug. ***
Priority: -- → P3
Blocks: 104166
Whiteboard: [QAHP] verify 90171 also when verifying this one → [QAHP] EDITORBASE verify 90171 also when verifying this one
Marking nsbeta1+ per syd. Need to fix for composer usability.
Keywords: nsbeta1+
issue still present in mac os x build 2001121805
Build 2001121803 It seems when the first line of text is anything other then body text aligned to the left (aligned to the center, right, justified, blockquote, indent, or lists) Composer wants to add a new line at the top, but the line only takes up half the space until you click any key (spacebar or enter some text). If you hit the spacebar once and save the file again when you reopen it you will see the whole caret in the upper left corner, but you will also have an extra line at the top of the page.
minusing, no data loss, user can click into the list and keep going. No evidence of incorrect behaviour after that point.
Keywords: nsbeta1+nsbeta1-
Whiteboard: [QAHP] EDITORBASE verify 90171 also when verifying this one → [QAHP] EDITORBASE- verify 90171 also when verifying this one
Target Milestone: mozilla1.0 → mozilla1.1
seek retriage on this since many users seem to run into this problem (some on a very regular basis) users with a list as the first thing in their document will notice this issue every time they open their file (or when they switch from html source to another tab)
Whiteboard: [QAHP] EDITORBASE- verify 90171 also when verifying this one → [QAHP] EDITORBASE verify 90171 also when verifying this one
this is not a bug in my opinion. this is the best solution to the problem of "how do I insert stuff in front of this list!?". When we start out we insert character before the list content. this is the only real way to insert stuff before this list. I dont see how this could be that serious of a problem for people. they hit right arrow or down or type stuff they get what they expect. The only thing odd here is that it is not of normal size. (this is because it is trying to draw on a frame that has 0 size) If we force the caret to go to the first list item people will complain that they cant get in front of it. In 4.x we automatically inserted lines before the document in this case to make sure people could click there. the problem is that modified their document with just opening and saving. people were real mad about that remember? Please let this bug go.
Status: NEW → ASSIGNED
note to self: think about letting backspacing thru first list item get us out.
EDITORBASE+ per EDITORBASE triage, expected behaviour is the caret should be placed inside the list.
Whiteboard: [QAHP] EDITORBASE verify 90171 also when verifying this one → [QAHP] EDITORBASE+ verify 90171 also when verifying this one
I made backspacing thru first li give u blank line in bug 161723. so this bug is about the funky caret again.
using a current trunk build, I am unable to reproduce the behavior as described in the initial entry. If I follow Sujays steps, the caret does not flip to the upper-left. However, I can get the 1/2 caret to appear, just not consistently.
QA Contact: tpreston → beppe
Target Milestone: mozilla1.1alpha → mozilla1.4alpha
I cant reproduce this at all. now the caret shows up inside the first element every time. If I dont get some more info on how to reproduce this i am going to mark this works for me or fixed or somethin.
Ok, I can reproduce this one, try this: 1. open a browser window, select to display the Netscpae home page 2. select to edit the page 3. there is an empty table on the top of the page, used as a spacer. 4. set focus in the table, right-mouse and select to delete the table. The caret will be pushed up to the top left and will be partially hidden. I will try to reduce the test case.
Depends on: 196951
WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060714 SeaMonkey/1.5a
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.