85518 - ondblclick event does not behave as desired with element : a

Status: NEW

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

Description

[Madhur Bhatia]

OS: win2000 
Build ID : 2001-06-07-13-0.9.1

steps to reproduce:-
--------------------
see the attached testcase.

1st scenario
============
dblclick on the first url.(this should open the url on the same window)

actual:- 
www.aol.com is displayed directly on the same browser window. The dialog box is 
not displayed.

expected:- 
the dialog box with the message "ONDBLCLICK - Open the url in same browser 
window" should be displayed. After the user clicks OK on the dialog Box, the url 
(www.aol.com) should be displayed on the same browser window

2nd scenario
============
dblclick on the second url. (this should open the url in a new window)

actual:- 
the dialog box is displayed, plus, a new blank browser window is also opened and 
the focus is on the blank window now. (window 1)
Now, if I go back to the testcase window, I'll still see the dialog box 
displayed. When i click OK - another new browser window is displayed with the 
url -- www.netscape.com (window 2)

expected:-
the dialog box should be displayed with message "ONDBLCLICK - Open the url in 
new browser window"
on clicking OK, the netscape site should be opend in new browser window.

In the 2nd scenario I have given the attribute TARGET=_blank for element: a

Comment 1

[Madhur Bhatia]

Attachment: testcase

Comment 2

[Madhur Bhatia]

QA contact updated

Comment 3

[Madhur Bhatia]

adding keyword 0.9.2

Comment 4

[joki (gone)]

I haven't thought too much about this specific sequence before but why do you 
assume that the execution of the dblclick event should delay loading of the url? 
 I definitely agree with some of the other parts of the bug.  In case 1, we 
should be getting a dialog.  In case 2 we shouldn't get two windows.  

Comment 5

[Tim Powell]

Case 1 worksforme with 20010710 build on win2k, but the alert dialog does not
block the load of the page. It occurs whether or not you press OK.

Comment 6

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 7

[Peter Trudelle]

nsbeta1- per ADT triage team

Comment 8

[Christine Hoffman]

Tested with 02_28_23_0.9.4ec mfcembed build on Win98 using this testcase:
http://bubblegum/browser/standards/html-transitional/tests/a_ondblclick.html
Application crashes with the following details:

MFCEMBED caused an invalid page fault in
module <unknown> at 0000:0124cbc0.
Registers:
EAX=0124cbf0 CS=0167 EIP=0124cbc0 EFLGS=00010287
EBX=00000020 SS=016f ESP=0064a8e5 EBP=bde8602f
ECX=01336e01 DS=016f ESI=00000000 FS=125f
EDX=817e2e09 ES=016f EDI=006715d0 GS=0000
Bytes at CS:EIP:
d8 bd 2f 60 03 00 00 00 00 00 00 00 d0 36 91 01 
Stack dump:
006715d0 00000000 bde8602f 0064a905 00000020 817e2e09 01336e01 0124cbf0 006715d0
00000000 0064d8e4 0064a925 00000020 817e2e09 01336e01 0124cb50 

Unable to reproduce on current trunk. Adding 'topembed' keyword.
NOTE: Cannot reproduce this crash when there is no 'href' attribute.

Comment 9

[Jennifer Kobayashi]

I can repro this on the following builds: 
mfcembed trunk 03/26
mfcembed 099 03/18
mfcembed 099 3/28
proprietary embed client (see bugscape bug 10843)

I'm concerned about this crash affecting the proprietary embed client. 

Chris Saari - why was kw:topembed minused on this one? 

Comment 10

[Pham]

.

Comment 11

[Vedran Miletic]

retargeting