Button onclick event doesn't appear to be being disabled.

Add-ons for Pale Moon and other applications
General discussion, compatibility, contributed extensions, themes, plugins, and more.

Moderators: FranklinDM, Lootyhoof

thosrtanner
Lunatic
Lunatic
Posts: 395
Joined: 2014-05-10, 18:19
Location: UK

Button onclick event doesn't appear to be being disabled.

Unread post by thosrtanner » 2019-12-08, 09:10

I have this button definition in my xul

Code: Select all

    <vbox>
      <spacer flex="1"/>
      <button id="inforss.make.current"
              label="&inforss.make.current;"/>
      <spacer flex="1"/>
    </vbox>
and I set up an onclick handler with document.getElementById("inforss.make.current").addEventListener and all works fine.

However, when I do:

Code: Select all

    document.getElementById("inforss.make.current").disabled = true;
my event handler still gets called when I click the button and looking at the eventTarget, the disabled attribute is set to true. Clearly there's a trivial workaround but I thought disabling a button would stop events being generated.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35630
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Button onclick event doesn't appear to be being disabled.

Unread post by Moonchild » 2019-12-08, 09:55

thosrtanner wrote:
2019-12-08, 09:10
I thought disabling a button would stop events being generated.
You thought wrong :)
If you add a click event listener, then whatever element it's on will generate that event when clicked no matter what state the element happens to be in. You shouldn't be using manually-assigned event listeners for normal control use; you want to use the standard methods of the element instead, e.g. define an oncommand= in your button definition or create a <command> handler. disabling the handler will also disable the control. See e.g.: https://developer.mozilla.org/en-US/doc ... l/Commands

I suggest you make more use of the XUL reference documentation instead of posting questions here. Most of your questions are already answered there.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

thosrtanner
Lunatic
Lunatic
Posts: 395
Joined: 2014-05-10, 18:19
Location: UK

Re: Button onclick event doesn't appear to be being disabled.

Unread post by thosrtanner » 2019-12-08, 12:35

Well, I don't want to use the standard onxxxx="javascript code" handlers because they are almost impossible to use with object methods. And many of the references that I have come across suggest you should try to avoid them anywhere.

I was vaguely aware of the command handler system, but there is absolutely nothing in the XUL documentation that I can find that suggests that events added by addEventListener behave differently in that way. Indeed the W3C documentation goes as far as suggesting there is pretty much a one to one relationship between onxxxxx in the html and adding an eventListener for xxxxxx

If you could show me the relevant part in the XUL documentation that indicates that addEventHandler handlers will be called no matter what the state of the disable flag, I'd be extremely grateful, as it may help me find other relevant bits or interpret the vagaries better.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35630
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Button onclick event doesn't appear to be being disabled.

Unread post by Moonchild » 2019-12-08, 13:57

The difference is that you are adding an event handler to an element unconditionally. Clicking on a disabled element is still clicking on it. There's a hierarchy involved here; if the handler is added outside of the normal hierarchy inherent to the element, then it will not adhere to the state of the element.

I also don't see the problem using normal handlers on elements that are subject to different element states (i.e. not unconditionally). Whether you call a JS function from a command handler or whether you call it from an added event handler doesn't make a difference; one is not more difficult than the other. I don't see why one should want to avoid them. Keep in mind XUL != HTML, too. We're not talking page content here.
Really though, if you want to use a button as a button, you should use its inherent properties to process interaction with it.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

thosrtanner
Lunatic
Lunatic
Posts: 395
Joined: 2014-05-10, 18:19
Location: UK

Re: Button onclick event doesn't appear to be being disabled.

Unread post by thosrtanner » 2019-12-08, 16:21

Well (a) it is difficult because the object doesn't necessarily exist at the time the window is loaded and so referring to it from the xul is difficult. it's much easier to do it from the javascript.
(b) i thought 'being disabled' was one of the properties of the button. reading on html stuff (yes, i know HTML isn't XUL but there's a lot more documentation on the former and it doesn't come with a red background and 'obsolete' warning on the page) indicates that 'if an element is disabled, it does not accept clicks.

In fact, even this page: https://developer.mozilla.org/en-US/doc ... e/disabled says - "If the element is disabled, it does not respond to user actions, it cannot be focused, and the command event will not fire."

Which to me reads - it shouldn't respond to clicks. I'll try seeing if command works any better

Addendum: Which it does, hurrah

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35630
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Button onclick event doesn't appear to be being disabled.

Unread post by Moonchild » 2019-12-08, 18:31

thosrtanner wrote:
2019-12-08, 16:21
"If the element is disabled, it does not respond to user actions, it cannot be focused, and the command event will not fire."
And it won't. but you're still not understanding that that applies to the events inherent to the control, NOT to something you attached to it yourself.
If you still don't get it I'm sorry. I've already spent too much time on this and have release binaries to build.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

Locked