Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #38492 > unrolled thread

on change trigger

Back to article view | Back to comp.lang.javascript

Contents

  on change trigger Andrew Poulos <ap_prog@hotmail.com> - 2020-07-10 12:57 +1000
    Re: on change trigger JJ <jj4public@vfemail.net> - 2020-07-10 16:03 +0700
    Re: on change trigger James Kirk <noneya.invalid@gmail.com> - 2020-07-10 11:14 -0400
    Re: on change trigger Julio Di Egidio <julio@diegidio.name> - 2020-07-10 23:33 -0700
    Re: on change trigger "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2020-07-11 17:52 -0700
      Re: on change trigger Andrew Poulos <ap_prog@hotmail.com> - 2020-07-12 13:44 +1000
    Re: on change trigger Arno Welzel <usenet@arnowelzel.de> - 2020-07-12 18:03 +0200
      Re: on change trigger James Kirk <noneya.invalid@gmail.com> - 2020-07-12 13:17 -0400
        Re: on change trigger Arno Welzel <usenet@arnowelzel.de> - 2020-07-13 17:24 +0200
          Re: on change trigger James Kirk <noneya.invalid@gmail.com> - 2020-07-13 13:35 -0400
            Re: on change trigger Arno Welzel <usenet@arnowelzel.de> - 2020-07-14 16:24 +0200

#38492 — on change trigger

It seems that dispatching an event to an input within a form doesn't 
trigger the onchange event for the form:

f.addEventListener('change', (e) => {
   console.log("f2", e); // zilch
});

inpt.dispatchEvent(new Event('change'));

Where inpt is an input within a form f.

Is that the expected behaviour?

Andrew Poulos

[toc] | [next] | [standalone]

#38493

On Fri, 10 Jul 2020 12:57:55 +1000, Andrew Poulos wrote:
> It seems that dispatching an event to an input within a form doesn't 
> trigger the onchange event for the form:
> 
> f.addEventListener('change', (e) => {
>    console.log("f2", e); // zilch
> });
> 
> inpt.dispatchEvent(new Event('change'));
> 
> Where inpt is an input within a form f.
> 
> Is that the expected behaviour?
> 
> Andrew Poulos

Simulated inputs are considered as security risk by the web standard. They
created the `isTrusted` property for this.

https://developer.mozilla.org/en-US/docs/Web/API/Event/isTrusted

Manually created events are never trusted, and the default event handler for
some important events will check that property.

[toc] | [prev] | [next] | [standalone]

#38494

In Message: <jOqdnV3ui7CoRJrCnZ2dnUU7-RHNnZ2d@westnet.com.au>
Andrew Poulos <ap_prog@hotmail.com> wrote:

> It seems that dispatching an event to an input within a form
> doesn't trigger the onchange event for the form:

Did you want it to 𝐛𝐮𝐛𝐛𝐥𝐞?

[snip]

> inpt.dispatchEvent(new Event('change'));

inpt.dispatchEvent(new Event('change',{bubbles: true}))

https://developer.mozilla.org/en-US/docs/Web/API/Event/Event#Example

> Where inpt is an input within a form f.

> Is that the expected behaviour?

Yes. bubbles default is false.

https://developer.mozilla.org/en-US/docs/Web/API/Event/Event#Values

-- 
James Kirk

[toc] | [prev] | [next] | [standalone]

#38495

On Friday, 10 July 2020 04:58:08 UTC+2, Andrew Poulos  wrote:

>    console.log("f2", e); // zilch

Not even that is going to do what you expect.  Do you ever look up the docs?
Reading the docs while coding is a *must*... (the only exception being stuff
that you use routinely and whose details you already know by heart; or, the
non-professional programmer).

Julio

[toc] | [prev] | [next] | [standalone]

#38496

On Thursday, July 9, 2020 at 9:58:08 PM UTC-5, Andrew Poulos wrote:
> It seems that dispatching an event to an input within a form doesn't 
> trigger the onchange event for the form:
> 
> f.addEventListener('change', (e) => {
>    console.log("f2", e); // zilch
> });
> 
> inpt.dispatchEvent(new Event('change'));
> 
> Where inpt is an input within a form f.
> 
> Is that the expected behavior?

What browser are you using? I'm not seeing a problem in current Brave (Chromium 83)

<https://codepen.io/mlhaufe/pen/vYLrwey>

[toc] | [prev] | [next] | [standalone]

#38499

On 12/07/2020 10:52 am, Michael Haufe (TNO) wrote:
> On Thursday, July 9, 2020 at 9:58:08 PM UTC-5, Andrew Poulos wrote:
>> It seems that dispatching an event to an input within a form doesn't
>> trigger the onchange event for the form:
>>
>> f.addEventListener('change', (e) => {
>>     console.log("f2", e); // zilch
>> });
>>
>> inpt.dispatchEvent(new Event('change'));
>>
>> Where inpt is an input within a form f.
>>
>> Is that the expected behavior?
> 
> What browser are you using? I'm not seeing a problem in current Brave (Chromium 83)
> 
> <https://codepen.io/mlhaufe/pen/vYLrwey>

As JK had pointed out I was missing bubbles:true.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#38501

Andrew Poulos:

> It seems that dispatching an event to an input within a form doesn't 
> trigger the onchange event for the form:
> 
> f.addEventListener('change', (e) => {
>    console.log("f2", e); // zilch
> });
> 
> inpt.dispatchEvent(new Event('change'));
> 
> Where inpt is an input within a form f.
> 
> Is that the expected behaviour?

The expected behaviour is, that the event is fired when you changed the
input *and* the input loses the focus. It will not fired while typing
something to the input.

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#38502

In Message: <hn0qjdFo95rU1@mid.individual.net>
Arno Welzel <usenet@arnowelzel.de> wrote:

> Andrew Poulos:

>> It seems that dispatching an event to an input within a form
>> doesn't trigger the onchange event for the form:

[snip]

>> Is that the expected behaviour?  

> The expected behaviour is, that the event is fired when you changed
> the input *and* the input loses the focus. It will not fired while
> typing something to the input.

d̲i̲s̲p̲a̲t̲c̲h̲i̲n̲g̲ ̲a̲n̲ ̲e̲v̲e̲n̲t̲?

𝐓𝐡𝐞 𝐜𝐡𝐚𝐧𝐠𝐞 𝐞v𝐞𝐧𝐭 𝐢𝐬 𝐟𝐢𝐫𝐞𝐝 …

https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/change_event#wikiArticle

   ¦ The change event is fired for <input>, <select>, and <textarea>
   ¦ elements when an alteration to the element's value is committed
   ¦ by the user.

   ¦ Depending on the kind of element being changed and the way the
   ¦ user interacts with the element, the change event fires at a
   ¦ different moment:

   ¦ • When the element is :checked (by clicking or using the
   ¦   keyboard) for <input type="radio"> and <input type="checkbox">;

   ¦ • When the user commits the change explicitly (e.g., by
   ¦   selecting a value from a <select>'s dropdown with a mouse
   ¦   click, by selecting a date from a date picker for <input
   ¦   type="date">, by selecting a file in the file picker for
   ¦   <input type="file">, etc.);

   ¦ • When the element loses focus after its value was changed, but
   ¦   not commited (e.g., after editing the value of <textarea> or
   ¦   <input type="text">).

   ¦ The HTML specification lists the <input> types that should fire
   ¦ the change event.

https://html.spec.whatwg.org/multipage/input.html#concept-input-apply

-- 
James Kirk

[toc] | [prev] | [next] | [standalone]

#38508

James Kirk:

> In Message: <hn0qjdFo95rU1@mid.individual.net>
> Arno Welzel <usenet@arnowelzel.de> wrote:
> 
>> Andrew Poulos:
> 
>>> It seems that dispatching an event to an input within a form
>>> doesn't trigger the onchange event for the form:
> 
> [snip]
> 
>>> Is that the expected behaviour?  
> 
>> The expected behaviour is, that the event is fired when you changed
>> the input *and* the input loses the focus. It will not fired while
>> typing something to the input.
> 
> d̲i̲s̲p̲a̲t̲c̲h̲i̲n̲g̲ ̲a̲n̲ ̲e̲v̲e̲n̲t̲?

Yes.

> 𝐓𝐡𝐞 𝐜𝐡𝐚𝐧𝐠𝐞 𝐞v𝐞𝐧𝐭 𝐢𝐬 𝐟𝐢𝐫𝐞𝐝 …
> 
> https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/change_event#wikiArticle

[...]
>    ¦ • When the element loses focus after its value was changed, but
>    ¦   not commited (e.g., after editing the value of <textarea> or
>    ¦   <input type="text">).

That is, what I was talking about. I head text inputs in my mind.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#38509

In Message: <hn3cltFa4l5U2@mid.individual.net>
Arno Welzel <usenet@arnowelzel.de> wrote:

> James Kirk:

>> In Message: <hn0qjdFo95rU1@mid.individual.net>
>> Arno Welzel <usenet@arnowelzel.de> wrote:

[snip]

>> d̲i̲s̲p̲a̲t̲c̲h̲i̲n̲g̲ ̲a̲n̲ ̲e̲v̲e̲n̲t̲?  

> Yes.

>> 𝐓𝐡𝐞 𝐜𝐡𝐚𝐧𝐠𝐞 𝐞v𝐞𝐧𝐭 𝐢𝐬 𝐟𝐢𝐫𝐞𝐝 …

>> https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/change_event#wikiArticle

>>  ¦ • When the element loses focus after its value was changed,
>>  ¦   but not commited (e.g., after editing the value of
>>  ¦   <textarea> or <input type="text">). 

> That is, what I was talking about. I head text inputs in my mind.

The event firing as a result of user interaction I̲S̲ ̲N̲O̲T̲ the
same as EventTarget.dispatchEvent()


-- 
James Kirk

[toc] | [prev] | [next] | [standalone]

#38510

James Kirk:

> In Message: <hn3cltFa4l5U2@mid.individual.net>
> Arno Welzel <usenet@arnowelzel.de> wrote:
> 
>> James Kirk:
> 
>>> In Message: <hn0qjdFo95rU1@mid.individual.net>
>>> Arno Welzel <usenet@arnowelzel.de> wrote:
> 
> [snip]
> 
>>> d̲i̲s̲p̲a̲t̲c̲h̲i̲n̲g̲ ̲a̲n̲ ̲e̲v̲e̲n̲t̲?  
> 
>> Yes.
> 
>>> 𝐓𝐡𝐞 𝐜𝐡𝐚𝐧𝐠𝐞 𝐞v𝐞𝐧𝐭 𝐢𝐬 𝐟𝐢𝐫𝐞𝐝 …
> 
>>> https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/change_event#wikiArticle
> 
>>>  ¦ • When the element loses focus after its value was changed,
>>>  ¦   but not commited (e.g., after editing the value of
>>>  ¦   <textarea> or <input type="text">). 
> 
>> That is, what I was talking about. I head text inputs in my mind.
> 
> The event firing as a result of user interaction I̲S̲ ̲N̲O̲T̲ the
> same as EventTarget.dispatchEvent()

Correct. I was talking about this:

f.addEventListener('change', (e) => {
   console.log("f2", e); // zilch
});



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web