Closed Bug 25258 Opened 25 years ago Closed 24 years ago

Selected FORM fields and links do not redraw when losing focus

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: joey, Assigned: hyatt)

References

Details

(Keywords: helpwanted) 

When I select a field inside any form, whether it be with the mouse or via TAB,
the field becomes "highlighted", but it remains highlighted even after I've
moved on to another field.

Note that this is trivial. I'm not trying to be nitpicky, just thought I'd
mention it! :)
Reassigning to Rod.
Assignee: karnaze → rods
yes, this is a known bug, and it is NOT trivial or nitpicky. It is rather 
annoying. Chris you are focus man....
Assignee: rods → saari
This isn't actually a focus issue (you can put handlers on things and see for 
yourself), I believe it is actually a CSS issue, and there is another bug on it 
somewhere.... which I can't seem to find at the moment.
Pierre, I think this is a CSS issue, sound familiar? I'm pretty sure there is another but on this somewhere.
Assignee: saari → pierre
I haven't heard of CSS issues related to focus in text fields and, sorry Chris, 
I'm one of the Most Doomed Persons, I can't take this bug in its current state. 
Someone else more familiar with text fields, controls, event handling or focus 
has to look into it. It means you, buster, joki or rods (although I'd spare joki 
too). Rod seemed to know what he was talking about. Anyhow, back to you... with 
my apologies.

I looked for bugs with "focus" in the summary and a quick search through the list 
for those that might be relevant to this problem returned the following: bug 
26513 (trudelle), bug 10779 (saari), bug 20322 (pollmann), bug 21363 (saari), bug 
21624 (saari). Some may be dups.
Assignee: pierre → saari
*** Bug 26513 has been marked as a duplicate of this bug. ***
*** Bug 26019 has been marked as a duplicate of this bug. ***
*** Bug 20322 has been marked as a duplicate of this bug. ***
*** Bug 21624 has been marked as a duplicate of this bug. ***
We need help to write a testcase that shows whether the problem is in CSS or in 
HTML form controls.

Added 'helpwanted' keyword, changed summary to "Selected FORM fields do not 
redraw when losing focus" and CCd myself.
Keywords: helpwanted
Summary: Selected FORM fields do not redraw → Selected FORM fields do not redraw when losing focus
I don't quite follow the possible CSS issue. If someone can give me more
info on what it is about CSS that could cause this, email me and I will
set it up on one of my machines...just a desc of what CSS element could
be affecting this and how.
as for a simple test case:

using this form, select Stauts: New by clicking on it and moving the mouse while
clicking. Now, tab.  Notice that the little dotted line around the links are
kept after you tab away.

On m13 - if you move your mouse over them, the line disapears.  If you scrolled
down so that you don't see the selected elements, and scrolled up, the lines
also are gone

On m14 (2000012520) - Moving mouse over will "refresh" them. However, sometimes
the dotted line does not dissapear completely - the lines on the left and on the
bottom remain, and you need to scroll enough to hide the elements so that the
entire dotten-line goes away.

note - scrolling down and up again does not remove the dotted-line unless you
moved the mouse over it before.

Sounds like a focus bug, not CSS. Hope this helps

Adding myself as cc, changing severity to normal.  Since 21624 was marked as a 
dup of this bug, and that bug was preventing us from having a UI that shows 
which widget and which pane in a window have focus, this is much more 
significant to our UI than it may sound on the surface.  Changed platform to 
all.
Severity: trivial → normal
OS: Windows 98 → All
Hardware: PC → All
*** Bug 21363 has been marked as a duplicate of this bug. ***
*** Bug 10780 has been marked as a duplicate of this bug. ***
*** Bug 10779 has been marked as a duplicate of this bug. ***
Retitling to reflect bug marked as a duplicate of this one.
Summary: Selected FORM fields do not redraw when losing focus → Selected FORM fields and links do not redraw when losing focus
*** Bug 27455 has been marked as a duplicate of this bug. ***
*** Bug 27883 has been marked as a duplicate of this bug. ***
*** Bug 28343 has been marked as a duplicate of this bug. ***
*** Bug 28731 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: M15
Just trying to understand where this bug really lies...
There is one comment saying it is a CSS issue, not a focus
issue, and another saying the exact opposite...is there any
consensus?
I think it's a general CSS issue since it affects both links and form controls,
not just form controls.  It's related to the :focus pseudo-class.
It might be that the focus code isn't sending the correct notification based on 
some input I got from rods. I havn't had a chance to verify that yet.

So is there anything I can do to help? Test cases to find exactly where
the bug is and isn't, perhaps? I know some C, no C++, so I don't know
think I'd be of any use actually CODING, but it sounds like this may
turn out to be an important issue, and I really do want to help...
Hey Joey, 
Yeah man, testcases are *always* a good thing.  Feel free to add 'em!
-ckritzer
OK, anyone have pointers on what a good test case would be?
Something using the :focus psuedo-class? Or what?
Hi Joey, the first thing you can do to help is to find all the duplicates of that 

bug. The dups usually have the word "outline" in the summary line (sometimes 

"focus" or "border"), you can find them in rods's list or mine (I'm sure other 

people have them too).



It can be tricky sometimes to make the difference between focus problems (often 

on saari's list) and the CSS 'outline' property that doesn't erase correctly (on 

rods's list or mine) so instead of marking the bugs as dups, it would be better 

to open a meta bug (with the 'meta' keyword) described as "Outline doesn't draw 

or erase" and mark the other bugs as dependent. Then assign it to rods, CC me and 

saari and we'll take care of marking them as dups. It the dependent bugs have 

testcases, you may move them to the meta bug or report them there.



I can't tell you how much this will be appreciated. Thanks!


*** Bug 30220 has been marked as a duplicate of this bug. ***
*** Bug 30327 has been marked as a duplicate of this bug. ***
Depends on: 30671

*** This bug has been marked as a duplicate of 18579 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
I'm reopening this bug because bug 18579 deals only with outlines.  This bug
does not.  They are two separate issues in the code - this bug is a regression
(that repaints are not triggered when an object loses :focus), whereas bug 18579
is an architectural issue with the way outlines work.

If bug 18579 now covers both problems, then that should be much clearer on bug
18579.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Part of my last comment was wrong - it's not repaints that are no longer
triggered, it's recomputation of style.

Perhaps bug 21363 should be reopened instead of this one.  I just added some new
comments to that bug.  The regression probably occurred because of Hyatt's
checkin on 1999-12-07.

*** Bug 31084 has been marked as a duplicate of this bug. ***
*** Bug 33439 has been marked as a duplicate of this bug. ***
This seems related to part of my bug 33070, but the other part is not a dup.

*** Bug 33070 has been marked as a duplicate of this bug. ***
I have a fix for this.
Assignee: saari → hyatt
Status: REOPENED → NEW
fixed
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Verifying on
 -Windows 98 build 2000-09-22-08-M18
 -Linux RedHat6.2 build 2000-09-19-21-M18
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.