53669 - html4 button won't accept click when it has focus

Status: VERIFIED FIXED

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

Comment 1

[Jesse Ruderman]

Attachment: test case

Comment 2

[Jesse Ruderman]

Click the html4 button twice, or drag out the first time and then try to click 
it again.  In both cases, you won't be able to click the second time.

Recent regression.  I'm using 2000 092111 on Windows 98, which is a generally 
horked (crash-on-exit) build, so this might just go away.

Comment 3

[Nisheeth Ranjan]

Re-assigning six bugs from Clayton's list to Harish for further triage...

Comment 4

[harishd]

Triaging Clayton's list:
------------------------
Changing component to Event Handling and assigning bug to joki. CCing saari.

Comment 5

[Loco]

Confirmed (was going to write this up actually).  Also horked in Linux 2000-09-
27-10 and Mac OS 9.0.4 2000-09-26-04.  Very, very bad bug.  Sit!  Good bug...

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Verified regression. Nominating for RTM. Inconsistency between buttons is 
bad, and most user's would probably not realize what is going on and what is 
the workaround. 

This would probably be easy to fix since HTML3 button does work, and because it 
is a regression it should be quite easy (if tedious) to find what checkin(s) 
broke it and fix it. 

Comment 7

[Nisheeth Ranjan]

I agree that this is a bad regression with high user visibility.  Marking rtm
need info.

Comment 8

[Nisheeth Ranjan]

By the way, is this problem specific to <BUTTON> or does this include <INPUT
type="BUTTON"> as well?

Comment 9

[Loco]

This only happens in <button>-input type = button seems to work fine:
http://slip/projects/marvin/html/input_type_button.html

Comment 10

[joki (gone)]

Okay, I think I have a fix for this but I need to run it by saari.  Attaching to 
bug report.

Comment 11

[joki (gone)]

Attachment: Proposed fix

Comment 12

[saari (gone)]

The change looks OK to me. I'm pretty sure that was only set to null to avoid
focus renotification/looping.

Comment 13

[vidur (gone)]

sr=vidur. Seems like a safe fix, confirmed by rigorous regression testing of
focus management.

Comment 14

[Nisheeth Ranjan]

Tom, this again can be checked into the trunk.

I spoke to jar about this and he doesn't feel this will be allowed into the rtm 
branch.

Marking rtm-.

Comment 15

[rods (gone)]

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

Comment 16

[rods (gone)]

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

Comment 17

[rods (gone)]

I did a some comment to 54469 that might be somewhat useful

Comment 18

[Loco]

Changing Plat/OS to ALL.

Said comments from rods:

This is a style issue. 

The HTML4 button has these rules:

button {
 ...
  padding: 1px 1px 1px 1px;
}

button:active:hover {
 ...
  padding: 2px 0 0 2px;
}

So when you press it (active) it shifts things down and to the left. It does it 
fine the first time. The first time you can set a break point in 
nsHTMLButtonControlFrame:Reflow and it hits it, if you click a second time you 
never hit the break point. 

It looks like the event state manager is somehow figuring the state hasn't 
changed. This used to work.

Comment 19

[djoham]

cc'ing self. Sorry for the spam

Comment 20

[joki (gone)]

Fix didn't make it in for 6.  I'll put it in now.

Comment 21

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 22

[saari (gone)]

r=saari

Comment 23

[Johnny Stenback (:jst)]

sr=jst, check this in!

Comment 24

[joki (gone)]

Fix checked in.

Comment 25

[Madhur Bhatia]

QA contact updated

Comment 26

[jerone]

verified on build 2001-07-24-06-trunk