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

Using alert() in conjunction with onblur and/or onfocus are causing problems

RESOLVED INVALID

Status

()

Core
DOM: Events
RESOLVED INVALID
9 years ago
9 years ago

People

(Reporter: Terje Rosenlund, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

Having an onfocus event-handler attached to a input-object makes it inaccessible
Same result whether its hardcoded in tag or installed by script

Reproducible: Always

Steps to Reproduce:
1.Run test-case (instructions on page)
(Reporter)

Comment 1

9 years ago
Created attachment 323563 [details]
Demonstrates onfocus event-handler making input inaccessible
(Reporter)

Comment 2

9 years ago
Comment on attachment 323563 [details]
Demonstrates onfocus event-handler making input inaccessible

Bug in example (:
Attachment #323563 - Attachment is obsolete: true
(Reporter)

Comment 3

9 years ago
Created attachment 323564 [details]
Demonstrates onfocus event-handler on input masks cursor

I was fooled to believe input was inaccessible because cursor becomes invisible after installing event-handler onfocus (changed subject)
(Reporter)

Updated

9 years ago
Summary: onfocus on input makes input inaccessible → onfocus eventhandler on input masks cursor
(Reporter)

Comment 4

9 years ago
Created attachment 323605 [details]
Demonstrates onfocus/onblur event-handler combination making input inaccessible

Combining onblur and onfocus on same control seems to give some explanation to the unwanted effect in my previous testcase (+ more unwanted effects)

I presume that cursor disappearing and input not selectable must be bugs

Firing blur-event on the selected element seems illogical to me but may be needed for reasons I dont know (?) and not a bug(?)

Same applies to calling handlers more than once
It's interesting although probably not entirely incorrect, the onfocus handler calls alert which unfocuses the input and in turn fires the onblur element, so thats why the oblur pops up, then the onfocus, afterwards alert sends focus back to the original element (here the behavior is weird, in that the caret is missing and selecting wont work), I guess some of this is good in that it doesn't make the script endless (i.e. onfocus-->alert(loses focus)-->(regains focus)onfocus...)
(Reporter)

Updated

9 years ago
Version: unspecified → 2.0 Branch
(Reporter)

Comment 6

9 years ago
Created attachment 323691 [details]
No alert on onfocus and onblur shows that alert is the problem

Natch is right, alert in handler fires 2 or 4 events if onblur and onfocus is attached

Removing alert and reporting directly to screen shows that calls to onblur and onfocus occur when they should 

The bug demonstrated in my previous testcase shows that the bug is related to using alert() in conjunction with onblur and/or onfocus

Changed subject accordingly
(Reporter)

Updated

9 years ago
Summary: onfocus eventhandler on input masks cursor → Using alert() in conjunction with onblur and/or onfocus are causing problems
Component: General → DOM: Events
Product: Firefox → Core
QA Contact: general → events
Whiteboard: [invalid?]
Version: 2.0 Branch → unspecified
The alert steals focus and calls onblur so, as filed, this bug is invalid. Please file a new bug for any other problems/suggestions other than that.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
Whiteboard: [invalid?]
You need to log in before you can comment on or make changes to this bug.