1. load attachment to bug 39985 2. hit alt-d (disables form elements in the light gray area) 3. hit alt-e (enabled form elements in the dark gray area) result: all password box and textarea start flashing (also textarea if it had been activated previously), even though none of them have focus.

reassigning

assign to Kin for review

Accepting bug.

text fields work fine, textareas have the caret enabled

setting to nsbeta3+

setting priority in status whiteboard

PDT downgrading to [nsbeta3-]. Would not hold product for this bug.

setting to future and adding helpwanted

Updating QA contact.

Now only the last text field enabled gains a flashing insertion point, and it also gains focus. Is this desirable? Some inputs (type=file, others?) don't accept focus() but can be enabled and disabled.

Oops, the last form element enabled /doesn't/ gain focus even though it does gain a flashing insertion point.

See also bug 53579 and bug 58361.

Another place this happens is prefs->advanced->proxies.

I cant reproduce this bug at all. adding event genius saari to cc lis tin case this interests him. but again, i cant reproduce this on this test case: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8919 nor can I repro it on the prefs->advanced->proxies page either. (this is using a build fromt he 16th) Jesse, are there any other steps that need to be done to see this? anthonyd

I think that this bug needs the word "focus" in the summary.

*** Bug 70577 has been marked as a duplicate of this bug. ***

QA Contact Update

*** This bug has been marked as a duplicate of 74145 ***

verified on Mac mozilla optimized build from 4am today.

Acting on Duplicate resolution from bug 39999 comment 18: *Moving 'Blocks: bug 39985, bug 64451' from bug 39999 to bug 74145. (Take further action as needed.)