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)
Tracking
()
NEW
People
(Reporter: girish.sk, Unassigned)
Details
(Keywords: testcase)
Attachments
(1 file)
224 bytes,
text/html
|
Details |
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
Comment 1•20 years ago
|
||
Might be ralated somehow with 263873 and 271421 , tested and confirmed on Windows 2000 SP3 with Firefox 1.0 RC1.
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.
Comment 3•19 years ago
|
||
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
Keywords: clean-report,
testcase
Whiteboard: crash?
Version: unspecified → Trunk
Updated•19 years ago
|
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
Comment 6•19 years ago
|
||
Reporter, can you reproduce the crash with a recent nightly build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Comment 7•19 years ago
|
||
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.
Updated•19 years ago
|
Assignee: firefox → events
Status: ASSIGNED → NEW
Component: General → Event Handling
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → ian
Comment 9•18 years ago
|
||
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.
Comment 10•18 years ago
|
||
Related to or equal to bug 339573
Comment 11•15 years ago
|
||
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
Updated•15 years ago
|
Assignee: events → nobody
QA Contact: ian → events
Assignee | ||
Updated•5 years ago
|
Component: Event Handling → User events and focus handling
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•