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

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: test case mentioned in original report

Comment 2

[Mats Palmgren (inactive)]

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

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

But it's still a bug.

Comment 5

[Eric Pollmann]

Grabbing this one, per today's meeting.

Comment 6

[Eric Pollmann]

Attachment: Summary table of other failing methods

Comment 7

[Eric Pollmann]

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

Comment 8

[Eric Pollmann]

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

Comment 9

[Eric Pollmann]

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.

Comment 10

[Eric Pollmann]

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.

Comment 11

[Eric Pollmann]

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

[rods (gone)]

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

Comment 13

[Kevin McCluskey (gone)]

Eric, since you have the fix. I'm reassigning back to you, so you can have the
pleasure of closing it out.

Comment 14

[Eric Pollmann]

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.

Comment 15

[Eric Pollmann]

Forked bug is bug 13652

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Verified fixed Linux viewer 1999-10-08-08-M11.