Should focus page before selection

RESOLVED WORKSFORME

Status

()

Core
Selection
P4
normal
RESOLVED WORKSFORME
18 years ago
14 years ago

People

(Reporter: Blake Ross, Assigned: mjudge)

Tracking

(Blocks: 1 bug, {helpwanted})

Trunk
Future
helpwanted
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
Build ID: 2000082108

Note that when I say the selection is 'gray' I mean whatever your unfocused 
color is set to.

Right now there are still quite a few bugs that cause you to get into a state 
where you can only highlight text of a page in an unfocused selection.  For 
example, if you drag a link and then drop it (when the 'no-drop' cursor 
appears) into the same page, then start selecting text in that page, it will be 
unfocused.  I'm not sure if this is possible, but since selections can only 
become unfocused onblur, is there a way that you could force all user-made, 
manual selections to be focused?  If so, you wouldn't have to fix each 
individual case (like the one I just mentioned re: d&d links)

Maybe you could fire focus to the page itself each time the user begins to 
select page contents (although this admittedly would be redundant in most 
cases)?  Not sure.

Comment 1

17 years ago
losing focus and regaining focus issue
Keywords: correctness
Priority: P3 → P2
Whiteboard: [nsbeta3+][p:2]
Target Milestone: --- → M19

Comment 2

17 years ago
PDT believes this is a P4.  Per paw, changing QA contact to Sujay
Priority: P2 → P4
QA Contact: blakeross → sujay
Whiteboard: [nsbeta3+][p:2] → [nsbeta3+][p:2][pdtp4]
(Assignee)

Comment 3

17 years ago
basically this is a generic focus bug. saari is the real man to handle this. I 
will just let it sit here however.
Status: NEW → ASSIGNED

Comment 4

17 years ago
moving to future adding helpwanted
Keywords: helpwanted
Whiteboard: [nsbeta3+][p:2][pdtp4] → [nsbeta3-][p:2][pdtp4]
Target Milestone: M19 → Future

Comment 5

17 years ago
See also bug 38646: mousedown on something *draggable* (as opposed to 
selectable) *shouldn't* bring the mozilla window it to the front.

Updated

17 years ago
Blocks: 47796, 48412, 78845, 81396
OS: Windows 98 → All
Hardware: PC → All

Updated

17 years ago
No longer blocks: 47796

Comment 6

16 years ago
See also bug 66597, tab should start from insertion point or beginning of 
selection.

Comment 7

16 years ago
Removing adequated PDT grafitti.  
Whiteboard: [nsbeta3-][p:2][pdtp4]

Comment 8

16 years ago
WFM.

Comment 9

14 years ago
I'm not able to reproduce the issue as described in comment 0 with 2004020909
windows SeaMonkey build
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.