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.
losing focus and regaining focus issue
Priority: P3 → P2
Target Milestone: --- → M19
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]
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
moving to future adding helpwanted
Whiteboard: [nsbeta3+][p:2][pdtp4] → [nsbeta3-][p:2][pdtp4]
Target Milestone: M19 → Future
See also bug 38646: mousedown on something *draggable* (as opposed to selectable) *shouldn't* bring the mozilla window it to the front.
See also bug 66597, tab should start from insertion point or beginning of selection.
Removing adequated PDT grafitti.
I'm not able to reproduce the issue as described in comment 0 with 2004020909 windows SeaMonkey build
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.