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

VERIFIED FIXED in M11

Status

()

P3
normal
VERIFIED FIXED
20 years ago
2 years ago

People

(Reporter: dbaron, Assigned: pollmann)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

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.

Updated

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

Comment 2

20 years ago
Verified bug with build 1999-07-14-17 (M8) on Windows 98.
WORKSFORME with build 1999-07-29-08 on Windows 98.
Status: RESOLVED → REOPENED
Summary: HTMLInputElement::click() stops JS execution → HTMLInputElement::click() doesn't call onclick handlers
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.
I did work around this: eval(input.getAttribute("onclick"));

But it's still a bug.
(Assignee)

Updated

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

Updated

20 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 5

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

Comment 6

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

Updated

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

Comment 7

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

Comment 8

20 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

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

Comment 9

20 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

20 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

20 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

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

Updated

20 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

20 years ago
Status: NEW → RESOLVED
Last Resolved: 20 years ago20 years ago
Resolution: --- → FIXED
(Assignee)

Comment 14

20 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

20 years ago
Forked bug is bug 13652
You need to log in before you can comment on or make changes to this bug.