If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Selection collapses in Editor when cursor exits table from left or right border

NEW
Unassigned

Status

()

Core
Editor
P3
normal
17 years ago
11 years ago

People

(Reporter: Blake Ross, Unassigned)

Tracking

Trunk
Future
x86
Windows ME
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [selection][tables], URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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

17 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.

Comment 2

17 years ago
Actually, I've been able to do it by just going out of the table.
I'll attach a testcase.

Comment 3

17 years ago
Created attachment 23661 [details]
Simple table with some text
(Reporter)

Comment 4

17 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

17 years ago
I don't see this with a 1/26 Linux build.  Is it perhaps new on the 27th, or Win
ME specific?

Comment 6

17 years ago
It does this in Win98SE too build 2001.01.27.08
Mozilla 0.7 exhibits the same behavior.

Comment 7

17 years ago
assigning to anthony, moving to moz0.9.1
Assignee: beppe → anthonyd
Severity: major → normal
Priority: -- → P3
Target Milestone: --- → mozilla0.9.1

Comment 8

17 years ago
moving to 0.9.2
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 9

17 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

17 years ago
I still see this in 200152104, Windows 2000.

Comment 11

17 years ago
moving this out to 1.0
Whiteboard: [select]
Target Milestone: mozilla0.9.2 → mozilla1.0

Updated

17 years ago
Whiteboard: [select] → [selection][tables]

Comment 12

17 years ago
this is also a wierd one.

anthonyd

Comment 13

16 years ago
selection
-->mjudge
Assignee: anthonyd → mjudge
Status: ASSIGNED → NEW

Comment 14

16 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

Comment 15

14 years ago
retargeting
Target Milestone: mozilla1.0.1 → Future
QA Contact: sujay → editor
Assignee: mjudge → nobody
You need to log in before you can comment on or make changes to this bug.