302027 - input element doesn't dispatch DOMActivate event

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect)

Description

[Stephen Pride]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050725 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050725 Firefox/1.0+

Implementing the example in the spec (9.2.1: The switch Element) fails.

Reproducible: Always

Comment 1

[Stephen Pride]

Attachment: testcase

Comment 2

[jhp (no longer active)]

Actually, the problem here is that the <xforms:input> doesn't fire a DOMActivate
event.  Changing summary accordingly.

Comment 3

[jhp (no longer active)]

Attachment: patch

The <xforms:input> element sits on top of the <html:input> element.  But it
seems that the <html:input> element won't fire a DOMActivate event on the
'Enter' keypress unless it is inside of <html:form> element.  This patch adds
code to xforms.xml in order to dispatch the event.  I also made it so
"xformswidget-input-boolean" ignores the 'Enter' keypress.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 190479 [details] [diff] [review]
patch

>+                  onkeypress="if (event.keyCode == 13) this.parentNode.dispatchDOMActivate();"

I'd prefer "if (event.keyCode == event.DOM_VK_RETURN) .... "

Comment 5

[jhp (no longer active)]

Comment on attachment 190479 [details] [diff] [review]
patch

Quite right, smaug.  Since you already took a look, do you mind giving me an
'official' review?

Comment 6

[aaronr]

Comment on attachment 190479 [details] [diff] [review]
patch

like smaug mentioned, replace that hard coded 13 with the appropriate define. 
Otherwise looks good.  r=me

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 190479 [details] [diff] [review]
patch

change the '13' and r=me

Comment 8

[jhp (no longer active)]

Checked in to trunk. ->FIXED

Comment 9

[Allan Beaufour]

Huh. Now we have two identical dispatchDOMActivate() functions in xforms.xml,
one for xforms-trigger-base and xforms-input. Couldn't this be a function on
xformswidget-base?

Comment 10

[jhp (no longer active)]

Attachment: use common method

Quite right.  Don't know how I missed it.  So this patch just moves the
|dispatchDOMActivate| method to xformswidget-base, and removes the other
references.

Comment 11

[Allan Beaufour]

Comment on attachment 190765 [details] [diff] [review]
use common method

kill trigger-base too, it's not needed anymore

Comment 12

[jhp (no longer active)]

Attachment: use common method v2

Cool, I didn't know what to do with |xformswidget-trigger-base|, if it was
needed for another reason or if it could just be removed.  So this patch
removes it entirely, and make |xformswidget-trigger-minimal| extend
|xformswidget-base| instead.

Comment 13

[Allan Beaufour]

Comment on attachment 190957 [details] [diff] [review]
use common method v2

(In reply to comment #12)
> Cool, I didn't know what to do with |xformswidget-trigger-base|, if it was
> needed for another reason or if it could just be removed.  So this patch
> removes it entirely, and make |xformswidget-trigger-minimal| extend
> |xformswidget-base| instead.

That's the trick. r=me

Comment 14

[Stephen Pride]

Actually, the original problem still exists (i.e., doesn't switch case when
focus out of input box - see testcase).  Should this bug be reopened, or a new
bug be opened?

Comment 15

[jhp (no longer active)]

Stephen, that behavior relies on the DOMFocusOut event, which is discussed in
bug 299379.