Open Bug 267675 Opened 20 years ago Updated 2 years ago

javascript function for onblur and the next event that caused the onblur event occur simultaneously

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86
All
defect

Tracking

()

People

(Reporter: girish.sk, Unassigned)

Details

(Keywords: testcase)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

The javascript onblur does not work properly.Javascript written for on blur
event and the next event that caused onblur are executing simultaneously.....It
is not supposed to happen.It seems there is problem in handling events.... 

Example code:

<html>
<body>

<script language="javascript">
function test(){
      alert("ok");
}
</script>
<input type="text" name="test" onblur=javascript:test()>

 <a href="http://www.girishsk.co.nr">Test</a>
</body>
</html

Reproducible: Always
Steps to Reproduce:
1.save the code given above as html file 
2.open it with firefox browser let the focus be on the text box
3.click on the link

Actual Results:  
alert message is popped up .Before clicking ok the page opens the link.

Expected Results:  
when the alert message is popped up .It should not handle the event that caused
the onblur event.

This might have major problem if some on handles the checking of what is entered
in the text box onblur and if submit button has caused the onblur event,it might
cause wrong updation as it submits without checking
Might be ralated somehow with 263873 and 271421 , tested and confirmed on
Windows 2000 SP3 with Firefox 1.0 RC1.
Attached file Reporter's testcase
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050408
Firefox/1.0+

WFM on latest-trunk.  If I am following your report, it is supposed to goto the
URL in the href entitled 'test' /before/ you click okay on the alert.  When
testing, whether I clicked okay on the alert or not, it did not goto the URL in
the href. 

I am going to go ahead an attach the reporter's testcase to the bug.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050407
Firefox/1.0+

WFM (I guess) on latest trunk.

Click inside textbox.
Click outside textbox.
Popup, stating "ok".  I hit ok.  Nothing happens.
I click the word 'Test', I get taken to another webpage.
Disregard comment #2, I tested this wrong.

Steps to Reproduce:

1. Open testcase
2. Enter some text into the box
3. Click the 'test' link
4. Observe it going to the page linked, and presenting a popup
5. Click okay on the popup

Actual Results:

Firefox goes to the page in the href without waiting for the user to click okay
on the dialog

Expected Results:

User should have to click okay on the dialog before they are sent to the page.

Additionally, I encountered a crash after clicking okay on the dialog.  I have
the Talkback ID of TB4950501Z for this crash.  I am not sure if the crash is
relevant to this bug or not.

Contents of the Talkback:

Stack Signature	 kXULControllersCID 5b6d6dd5
Product ID	FirefoxTrunk
Build ID	2005040406
Trigger Time	2005-04-08 17:49:18.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (0055fcfb)
URL visited	
User Comments	
Since Last Crash	36540 sec
Total Uptime	109027 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
kXULControllersCID
nsTextEditRules::WillInsertText 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/editor/libeditor/text/nsTextEditRules.cpp,
line 497]
nsEventListenerManager::DispatchEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1957]
nsEventListenerManager::GetSystemEventGroupLM 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1901]
nsGenericElement::RangeAdd 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 2344]
nsHTMLInputElement::Reset 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 2089]
nsEventStateManager::DispatchNewEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 4350]
nsEventStateManager::SendFocusBlur 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 4062]
nsGenericHTMLElement::SetAttrAndNotify 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 1750]
nsHTMLSpanElement::QueryInterface
PresShell::PostReflowEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6542]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6315]
nsViewManager::CanScrollWithBitBlt 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 3067]
ApplyZOrderStableSort 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 1069]
nsDOMAttributeMap::SetNamedItem 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/base/src/nsDOMAttributeMap.cpp,
line 136]
nsWindow::DealWithPopups 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1320]
nsWindow::DispatchFocus 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 5958]
nsWindow::HandleTextEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 6174]
nsWindow::StandardWindowCreate 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1640]
USER32.dll + 0x86cb (0x77d486cb)
USER32.dll + 0x879f (0x77d4879f)
USER32.dll + 0x8a31 (0x77d48a31)
USER32.dll + 0x8ab4 (0x77d48ab4)
nsAutoCompleteController::GetCellProperties 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp,
line 627]
main 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/browser/app/nsBrowserApp.cpp,
line 60]
kernel32.dll + 0x2141a (0x77e8141a)



->confirming, adding testcase and clean-report keywords, changing version to Trunk

Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: crash?
Version: unspecified → Trunk
Summary: javascript function for onblur and the next event that caused the onblur event occur simultaneously → javascript function for onblur and the next event that caused the onblur event occur simultaneously [@ kXULControllersCID]
(In reply to comment #2)
> Created an attachment (id=180132) [edit]
> Reporter's testcase
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050408
> Firefox/1.0+
> 
> WFM on latest-trunk.  If I am following your report, it is supposed to goto the
> URL in the href entitled 'test' /before/ you click okay on the alert.  When
> testing, whether I clicked okay on the alert or not, it did not goto the URL in
> the href. 
> 
> I am going to go ahead an attach the reporter's testcase to the bug.  

(In reply to comment #4)
> Disregard comment #2, I tested this wrong.
> 
> Steps to Reproduce:
> 
> 1. Open testcase
> 2. Enter some text into the box
> 3. Click the 'test' link
> 4. Observe it going to the page linked, and presenting a popup
> 5. Click okay on the popup
> 
> Actual Results:
> 
> Firefox goes to the page in the href without waiting for the user to click okay
> on the dialog
> 
> Expected Results:
> 
> User should have to click okay on the dialog before they are sent to the page.
> 
> Additionally, I encountered a crash after clicking okay on the dialog.  I have
> the Talkback ID of TB4950501Z for this crash.  I am not sure if the crash is
> relevant to this bug or not.
> 
> Contents of the Talkback:
> 
> Stack Signature	 kXULControllersCID 5b6d6dd5
> Product ID	FirefoxTrunk
> Build ID	2005040406
> Trigger Time	2005-04-08 17:49:18.0
> Platform	Win32
> Operating System	Windows NT 5.1 build 2600
> Module	firefox.exe + (0055fcfb)
> URL visited	
> User Comments	
> Since Last Crash	36540 sec
> Total Uptime	109027 sec
> Trigger Reason	Access violation
> Source File, Line No.	N/A
> Stack Trace 	
> kXULControllersCID
> nsTextEditRules::WillInsertText 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/editor/libeditor/text/nsTextEditRules.cpp,
> line 497]
> nsEventListenerManager::DispatchEvent 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
> line 1957]
> nsEventListenerManager::GetSystemEventGroupLM 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
> line 1901]
> nsGenericElement::RangeAdd 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp,
> line 2344]
> nsHTMLInputElement::Reset 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
> line 2089]
> nsEventStateManager::DispatchNewEvent 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
> line 4350]
> nsEventStateManager::SendFocusBlur 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
> line 4062]
> nsGenericHTMLElement::SetAttrAndNotify 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
> line 1750]
> nsHTMLSpanElement::QueryInterface
> PresShell::PostReflowEvent 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
> line 6542]
> PresShell::HandleEventInternal 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsPresShell.cpp,
> line 6315]
> nsViewManager::CanScrollWithBitBlt 
> [c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
> line 3067]
> ApplyZOrderStableSort 
> [c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
> line 1069]
> nsDOMAttributeMap::SetNamedItem 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/content/base/src/nsDOMAttributeMap.cpp,
> line 136]
> nsWindow::DealWithPopups 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
> line 1320]
> nsWindow::DispatchFocus 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
> line 5958]
> nsWindow::HandleTextEvent 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
> line 6174]
> nsWindow::StandardWindowCreate 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
> line 1640]
> USER32.dll + 0x86cb (0x77d486cb)
> USER32.dll + 0x879f (0x77d4879f)
> USER32.dll + 0x8a31 (0x77d48a31)
> USER32.dll + 0x8ab4 (0x77d48ab4)
> nsAutoCompleteController::GetCellProperties 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp,
> line 627]
> main 
>
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/browser/app/nsBrowserApp.cpp,
> line 60]
> kernel32.dll + 0x2141a (0x77e8141a)
> 
> 
> 
> ->confirming, adding testcase and clean-report keywords, changing version to Trunk
> 
>
Clicking event should not be handled at all. Only onblur event has to be handled
. When user clicks on link .Event that has to be called is onblur not click
event. Eventhough the user press okay, clicking event should not be handled as i
am only returning back to the same html page.

Actual Result :
   1. enter some text in text box .
   2. click on test.
   3. Alert should pop up.
   4. On okay .Page should not go to the link that is hrefed in test link.
Status: NEW → ASSIGNED
Reporter, can you reproduce the crash with a recent nightly build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
The following builds does NOT crash on the testcase, lowering severity.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050623
Firefox/1.0+
Mozilla nightly trunk 2005-06-23-06 Windows XP
Mozilla nightly trunk 2005-06-15-02 Linux

We do trigger the link if the mouse-up occurs over it (as originally reported).
Moving the mouse away from the link before releasing the button does not trigger
it (a drag-n-drop is started instead though).
IE6 does neither of those - nothing happens on button up.
Severity: critical → normal
Summary: javascript function for onblur and the next event that caused the onblur event occur simultaneously [@ kXULControllersCID] → javascript function for onblur and the next event that caused the onblur event occur simultaneously
Whiteboard: crash?
Is it that the two event occur simultaneously ... By the logic Onblur event 
occurs first so it has to be given the first priority . Then is the click 
event .
One more test case can be done . If onblur event we href to another html 
page . And if click on the link has caused the onblur event it ll be difficult 
for us to tell to which page it ll go. 
So logically click event should not occur.Only onblur event should be called.
Assignee: firefox → events
Status: ASSIGNED → NEW
Component: General → Event Handling
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → ian
Is there any news on the status of this bug ? I'm using Firefox 1.5 at the moment and I'm experiencing problems using alerts and onblur together. onblur on a text edit control gets triggered when I click on another control in my form and calls some javascript validation which displays an alert if invalid data is entered. But the onclick event for the other form element also executes while the alert is still displayed.
Related to or equal to bug 339573
Mozilla/5.0 (Windows; U; Windows NT 5.1; nb-NO; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)

> Related to or equal to bug 339573

Don't think so. 339573 describes the fact that ff dos'nt respect the return value from onchange-handler and always selects next/previous/any control according to the action which triggered the onchange-event (tab, shift/tab, mouse-click)
Seems like bug 267675 (this) has been fixed according to reporters wish in current release

The effect is that any onblur-handler on a page will make all links on the same page useless (never executed)

Reporters original concern was related to forms posted before data-validation. This may be accomplished by using onchange and onsubmit events.
(ref. my comment on bug 339573)

It seems to me that this fix has introduced a bug and dos'nt seem like an appropriate way to handle the problem
Assignee: events → nobody
QA Contact: ian → events
Component: Event Handling → User events and focus handling
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: