HTMLInputElement::click() doesn't call onclick handlers

VERIFIED FIXED in M11

Status

()

Core
DOM
P3
normal
VERIFIED FIXED
19 years ago
a year ago

People

(Reporter: dbaron, Assigned: Eric Pollmann)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
HTMLInputElement::click() stops JS execution (is there a better word for
this?).  See the attached test case (and watch the browser's text screen).  Load
the page, and 'Calling click()', nothing happens.  If you click the button with
the mouse, you see 'click succeeded'.

Could you give an estimate of when this could be fixed?  It's useful for test
automation.  Working around it isn't that hard but isn't very "clean," and I
would prefer to use it if possible.
(Reporter)

Comment 1

19 years ago
Created attachment 911 [details]
test case mentioned in original report

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME

Comment 2

19 years ago
Verified bug with build 1999-07-14-17 (M8) on Windows 98.
WORKSFORME with build 1999-07-29-08 on Windows 98.
(Reporter)

Updated

19 years ago
Status: RESOLVED → REOPENED
Summary: HTMLInputElement::click() stops JS execution → HTMLInputElement::click() doesn't call onclick handlers
(Reporter)

Updated

19 years ago
Resolution: WORKSFORME → ---
(Reporter)

Comment 3

19 years ago
Reopening bug.  It's not stopping execution anymore, but it still isn't
completely working.  (Retitling bug.)  When the page loads, you should see:

Calling click().
Click succeeded.
click() finished

Right now, the middle line isn't happening.  (Before, only the first line was.)
It does happen, though, when you physically click on the button.

I'm using linux 1999-08-13-08-M9.
(Reporter)

Comment 4

19 years ago
I did work around this: eval(input.getAttribute("onclick"));

But it's still a bug.
(Assignee)

Updated

19 years ago
Assignee: vidur → pollmann
Status: REOPENED → NEW
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 5

19 years ago
Grabbing this one, per today's meeting.
(Assignee)

Comment 6

19 years ago
Created attachment 1597 [details]
Summary table of other failing methods
(Assignee)

Updated

19 years ago
Assignee: pollmann → kmcclusk
Status: ASSIGNED → NEW
OS: Linux → All
Hardware: PC → All
(Assignee)

Comment 7

19 years ago
Kevin, I'm passing this one to you, as discussed.  If you need a hand, let me
know.  :)
(Assignee)

Comment 8

19 years ago
Just noticed this in nsHTMLInputElement::Click()

#if 0
  case NS_FORM_INPUT_BUTTON:
  case NS_FORM_INPUT_RESET:
  case NS_FORM_INPUT_SUBMIT:
    {
      nsIFormControlFrame* formControlFrame = nsnull;
      if (NS_OK == nsGenericHTMLElement::GetPrimaryFrame(this,formControlFrame))
{
        if (formControlFrame) {
          formControlFrame->MouseClicked(XXXpresContextXXX);
        }
      }
    }
    break;
#endif

I was thinking a solution would be to generate a DOM event, but this also
requires a pres context.  :S

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M11
(Assignee)

Comment 9

19 years ago
Kevin, I changed nsHTMLInputElement::Click() to this and it fixed the original
bug:

NS_IMETHODIMP
nsHTMLInputElement::Click()
{
  nsIDocument* doc = nsnull;
  GetDocument(doc);
  if (doc) {
    PRInt32 numShells = doc->GetNumberOfShells();
    nsIPresShell* shell = nsnull;
    nsIPresContext* context = nsnull;
    nsresult res = NS_OK;
    for (PRInt32 i=0; i<numShells; i++) {
      shell = doc->GetShellAt(i);
      if (shell) {
        res = shell->GetPresContext(&context);
        if (NS_SUCCEEDED(res) && context) {
	  nsEventStatus status = nsEventStatus_eIgnore;
	  nsGUIEvent event;
	  event.eventStructType = NS_GUI_EVENT;
	  event.message = NS_MOUSE_LEFT_CLICK;
          HandleDOMEvent(*context, &event, nsnull, NS_EVENT_FLAG_INIT, status);
        }
      }
    }
  }
  return NS_OK;
}

It seems we might be able to consolidate nsHTMLInputElement::HandleDOMEvent and
nsButton/Checkbox/RadioControlFrame::HandleEvent as well.
(Assignee)

Comment 10

19 years ago
Kevin, I changed nsHTMLInputElement::Click() to this and it fixed the original
bug:

NS_IMETHODIMP
nsHTMLInputElement::Click()
{
  nsIDocument* doc = nsnull;
  GetDocument(doc);
  if (doc) {
    PRInt32 numShells = doc->GetNumberOfShells();
    nsIPresShell* shell = nsnull;
    nsIPresContext* context = nsnull;
    nsresult res = NS_OK;
    for (PRInt32 i=0; i<numShells; i++) {
      shell = doc->GetShellAt(i);
      if (shell) {
        res = shell->GetPresContext(&context);
        if (NS_SUCCEEDED(res) && context) {
	  nsEventStatus status = nsEventStatus_eIgnore;
	  nsGUIEvent event;
	  event.eventStructType = NS_GUI_EVENT;
	  event.message = NS_MOUSE_LEFT_CLICK;
          HandleDOMEvent(*context, &event, nsnull, NS_EVENT_FLAG_INIT, status);
        }
      }
    }
  }
  return NS_OK;
}

It seems we might be able to consolidate nsHTMLInputElement::HandleDOMEvent and
nsButton/Checkbox/RadioControlFrame::HandleEvent as well.
(Assignee)

Comment 11

19 years ago
Also, of course, I moved the logic (GetChecked/SetChecked) from the Click()
routine down into HandleDOMEvent where Click() used to be called.  Moving all of
this event handling logic into the frames might be good as well?

Comment 12

19 years ago
No, leave it in the content. We want to do as little event processing as
possible in the frames.

Updated

19 years ago
Assignee: kmcclusk → pollmann
Status: ASSIGNED → NEW
Eric, since you have the fix. I'm reassigning back to you, so you can have the
pleasure of closing it out.
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 14

19 years ago
Just checked in a fix for the first part of the bug.  I filed a separate report
for the remainder of this bug, so I'm closing this one out.
(Assignee)

Comment 15

19 years ago
Forked bug is bug 13652
(Reporter)

Updated

19 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 16

19 years ago
Verified fixed Linux viewer 1999-10-08-08-M11.
You need to log in before you can comment on or make changes to this bug.