Closed
Bug 66816
Opened 24 years ago
Closed 2 years ago
Selection collapses in Editor when cursor exits table from left or right border
Categories
(Core :: DOM: Editor, defect, P5)
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: bugzilla, Unassigned)
References
()
Details
(Whiteboard: [selection][tables])
Attachments
(1 file)
(deleted),
text/html
|
Details |
Build ID: new trunk (tip)
Stay with me here...
(1) Go to http://www.mozilla.org/
(2) File | Edit Page (Ctrl+E)
(3) If the Composer window is maximized, restore it so it's just a square in
the middle of the screen (not necessary to reproduce, but makes the bug easier
to see/understand)
(4) Select some text.
(5) While drag-selecting, move the cursor outside the window by going to the
left or right.
(6) Move the cursor back inside the window.
Result: the old selection disappears. A new one is started from the left or
right side of the window.
I don't see this when I just paste a large block of text, so it might be
specific to tables or something else...
Reporter | ||
Comment 1•24 years ago
|
||
It's worth noting that it's not when the cursor exits the window, but rather
when it exits the editor; the selection disappears the second you mouseover the
scrollbar.
Actually, I've been able to do it by just going out of the table.
I'll attach a testcase.
Reporter | ||
Comment 4•24 years ago
|
||
Ah, you're right--the selection becomes discontiguous when you leave the table
(left or right, still). Thanks!
Summary: Selection collapses in Editor when cursor exits window to left or right → Selection collapses in Editor when cursor exits table from left or right border
Comment 5•24 years ago
|
||
I don't see this with a 1/26 Linux build. Is it perhaps new on the 27th, or Win
ME specific?
It does this in Win98SE too build 2001.01.27.08
Mozilla 0.7 exhibits the same behavior.
Comment 7•24 years ago
|
||
assigning to anthony, moving to moz0.9.1
Assignee: beppe → anthonyd
Severity: major → normal
Priority: -- → P3
Target Milestone: --- → mozilla0.9.1
moving to 0.9.2
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Comment 9•23 years ago
|
||
using a current build -- 2001052020, I do not see this happening anymore, Blake
can you try this again and see if you can dup this?
Reporter | ||
Comment 10•23 years ago
|
||
I still see this in 200152104, Windows 2000.
Comment 11•23 years ago
|
||
moving this out to 1.0
Whiteboard: [select]
Target Milestone: mozilla0.9.2 → mozilla1.0
Comment 12•23 years ago
|
||
this is also a wierd one.
anthonyd
Comment 14•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1
(you can query for this string to delete spam or retrieve the list of bugs I've
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Updated•18 years ago
|
QA Contact: sujay → editor
Updated•18 years ago
|
Assignee: mjudge → nobody
Comment 16•4 years ago
|
||
Bulk-downgrade of unassigned, untouched DOM/Storage bug's priority.
If you have reason to believe, this is wrong, please write a comment and ni :jstutte.
Severity: normal → S4
Priority: P3 → P5
Comment 17•2 years ago
|
||
Can no longer be reproduced
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•